vadius

в ядре все по умолчанию, вот sysctl-ы kern.maxuser: 384 vm.kmem_size_scale: 1 vm.kmem_size: 8206544896 vm.kmem_size_max: 329853485875

что то я сомневаюсь на счет базового значения kern.ipc.nmbclusters, оно равно 25600. я сохранял netstat -m, когда у меня было kern.ipc.nmbclusters=262144 26540/10074/36614/262144 mbuf clusters in use (current/cache/total/max) получается не хватит mbuf кластеров?

Фигня какая то, на разных ядрах загрузка dummynet кардинально отличается. Прибиваю dummynet к 0 ядру: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU1 1 41:16 100.00% {idle: cpu1} 11 root 171 ki31 0K 128K CPU3 3 41:14 100.00% {idle: cpu3} 11 root 171 ki31 0K 128K CPU4 4 40:57 100.00% {idle: cpu4} 11 root 171 ki31 0K 128K CPU2 2 38:04 100.00% {idle: cpu2} 11 root 171 ki31 0K 128K CPU0 0 37:31 100.00% {idle: cpu0} 11 root 171 ki31 0K 128K CPU7 7 40:37 98.19% {idle: cpu7} 11 root 171 ki31 0K 128K CPU6 6 41:07 96.39% {idle: cpu6} 11 root 171 ki31 0K 128K RUN 5 40:20 91.46% {idle: cpu5} 0 root -68 0 0K 336K - 7 2:06 8.69% {em3 taskq} 0 root -68 0 0K 336K - 5 3:13 7.76% {em1 taskq} 0 root -68 0 0K 336K - 6 1:00 5.86% {em2 taskq} 0 root -68 0 0K 336K - 4 0:51 4.05% {em0 taskq} 12 root -68 - 0K 512K WAIT 0 0:08 0.20% {irq256: igb0:que} 0 root 44 0 0K 336K sched 2 3:02 0.00% {swapper} 0 root -68 0 0K 336K - 0 1:47 0.00% {dummynet} к 1 ядру: 0 root -68 0 0K 336K - 1 1:50 0.00% {dummynet} ко 2: 0 root -68 0 0K 336K - 2 1:55 0.00% {dummynet} к 3: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU1 1 44:34 100.00% {idle: cpu1} 11 root 171 ki31 0K 128K CPU4 4 44:12 100.00% {idle: cpu4} 11 root 171 ki31 0K 128K CPU7 7 43:46 100.00% {idle: cpu7} 11 root 171 ki31 0K 128K CPU2 2 41:24 100.00% {idle: cpu2} 0 root -68 0 0K 336K - 3 2:00 100.00% {dummynet} 11 root 171 ki31 0K 128K RUN 5 43:24 99.66% {idle: cpu5} 11 root 171 ki31 0K 128K RUN 0 40:50 98.97% {idle: cpu0} 11 root 171 ki31 0K 128K CPU6 6 44:22 96.09% {idle: cpu6} к 4 ядру: 0 root -68 0 0K 336K - 4 2:07 96.29% {dummynet} к 5: 0 root -68 0 0K 336K - 5 2:11 0.00% {dummynet} к 6: 0 root -68 0 0K 336K - 6 2:12 0.00% {dummynet} к 7: 0 root -68 0 0K 336K - 7 2:15 0.00% {dummynet}

st_re благодарю за помощь, а то я что-то не смог найти как отдельный процесс прибить к нужному ядру (видимо плохо искал :) ), буду экспериментировать. options KDB_UNATTENDED попробую поставить.

Giga-Byte спасибо за совет, срочным образом меняю на out :)

в ядре: makeoptions DEBUG=-g options KDB options KDB_TRACE а вот options KDB_UNATTENDED нет пробовал ставить разные ядра (0,2,4),(0,2,4,6), но не понятно почему, процесс dummynet начинает грузить некоторые ядра (4 или 6) до 80-90% меняешь на 0,2 загрузка падает ниже 10%, поэтому временно оставил так

вот с коркой проблема, никак ее нет Сейчас прибито: cpuset -l 0,2 -p 0 в top-е видно это вот можно попробовать

net.inet.ip.fastforwarding=1 был отключен до недавнего времени, сейчас включили для тестирования. Сервер умирает и так и так :( net.isr.maxthreads=4 с net.isr.direct=1 смысла конечно нет, я оставил для того чтобы пробовать с net.isr.direct=0, но тогда загрузка проца растет и один черт виснет. т.е убрать их из rc.conf? 00011 pipe 1 ip from any to 111.222.80.0/21 in via eth1 00011 pipe 2 ip from 111.222.80.0/21 to any out via eth1 00012 pipe 3 ip from any to 111.222.88.0/22 in via eth1 00012 pipe 4 ip from 111.222.88.0/22 to any out via eth1 00012 pipe 3 ip from any to 111.222.92.0/24 in via eth1 00012 pipe 4 ip from 111.222.92.0/24 to any out via eth1 00013 pipe 5 ip from any to 111.222.93.0/24 in via eth1 00013 pipe 6 ip from 111.222.93.0/24 to any out via eth1 00013 pipe 5 ip from any to 111.222.94.0/23 in via eth1 00013 pipe 6 ip from 111.222.94.0/23 to any out via eth1 00014 pipe 7 ip from any to 111.333.16.0/24 in via eth1 00014 pipe 8 ip from 111.333.16.0/24 to any out via eth1 00021 pipe 9 ip from any to 111.333.23.0/27 in via eth1 00021 pipe 10 ip from 111.333.23.0/27 to any out via eth1 00022 pipe 11 ip from any to 111.333.23.32/27 in via eth1 00022 pipe 12 ip from 111.333.23.32/27 to any out via eth1 00023 pipe 13 ip from any to 111.333.23.64/27 in via eth1 00023 pipe 14 ip from 111.333.23.64/27 to any out via eth1 00024 pipe 15 ip from any to 111.333.23.96/27 in via eth1 00024 pipe 16 ip from 111.333.23.96/27 to any out via eth1 00031 pipe 13 ip from any to 111.333.23.192/27 in via eth1 00031 pipe 14 ip from 111.333.23.192/27 to any out via eth1 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01300 deny ip from any to 172.16.0.0/12 via eth1 01400 deny ip from 172.16.0.0/12 to any via eth1 01500 deny ip from any to 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 01600 deny ip from 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any 01700 skipto 10000 ip from any to 111.333.23.192/27 01800 fwd 192.168.251.12 ip from any to any out recv eth1 xmit eth3 01900 fwd 192.168.252.12 ip from any to any out recv eth1 xmit eth2 10000 allow icmp from any to any 10100 allow tcp from any to any established 10200 allow ip from any to any frag 10300 allow ip from 172.10.0.0/20,172.10.128.0/22 to any { via vlan1 or via eth4 or via vlan2 or via vlan4 or via eth5 } 10400 allow ip from any to 172.10.0.0/20,172.10.128.0/22 { via vlan1 or via eth4 or via vlan2 or via vlan4 or via eth5 } 10500 allow ip from any to 111.222.80.0/20,111.333.16.0/21 10600 allow ip from 111.222.80.0/20,111.333.16.0/21 to any ... далее идут правила доступа к локальным сервисам и серверам внутри сети ... 65535 deny ip from any to any eth0 - входящий город поделен на вланы eth1 - входящий интернет eth2,eth3 - исходящий к Nas-ам eth4,eth5 - исходящий еще к 2 сетям 11-31 - пайпы шейпера, скорости доступа поделили по подсетям 1800,1900 - заворачиваем интернет трафик в вланы к Nas-ам, для дальнейшего обсчета в биллинге. 10300,10400 серые адреса по городу

Запарились уже. Спасайте. В связи с увеличением канала (интернет,город) в январе был установлен новый сервер на граничный маршрутизатор с FreeBSD 8.1 (AMD64), потом обновлен до 8.2-Release (AMD64). Железо такое: Мать Intel S5520UR, два CPU Xeon E5620, памяти 8 Гб две двухголовые (em) HP NC360T PCIe DP Gigabit Server Adapter (n1e5132) две встроенные (igb) 82575EB Gigabit Network Connection На нем крутится bgp, ospf, dummynet, ssh, ipfw, dns. NATа - нет. Firewall 90 правил, включая 22 pipe для шейпера. Входящий трафик в пике: Интернет около 300Мбит(~50К пакетов), город 600-700Мбит (~90К пакетов). Город и интернет на разных каналах. Исходящий раза в полтора поменьше. Ошибок на интерфейсах нет. Шейпер висит на входящем из интернета. Проблема в следующем: Раз в неделю получаем kernel panic fatal trap 12 (current process = 12 (irq258:igb0:que 2) или (current process = 0 (em2 taskq)) и завис, пару раз была перезагрузка. Самое интересное, часто падает днем в то время когда нагрузка ниже средней. Пробовали драйвера от яндекса один черт. Убираешь тюнинг падает дня через 2-3. Из тюнинга: sysctl.conf kern.ipc.nmbclusters=524288 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=204800 kern.maxfilesperproc=200000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=0 net.inet.tcp.drop_synfin=1 net.inet.tcp.syncookies=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=65536 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=1000 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.pipe_slot_limit=2048 net.inet.ip.fastforwarding=1 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.ip.intr_queue_maxlen=1000 kern.ipc.shm_use_phys=1 net.isr.direct=1 net.isr.direct_force=1 net.link.ether.inet.log_arp_movements=0 dev.igb.0.flow_control=0 dev.igb.1.flow_control=0 dev.em.X.rx_int_delay=1000 dev.em.X.tx_int_delay=1000 dev.em.X.rx_abs_int_delay=2000 dev.em.X.tx_abs_int_delay=2000 dev.em.X.rx_processing_limit=2000 dev.em.X.flow_control=0 loader.conf net.isr.maxthreads=4 Из ядра все лишнее выброшено. Flowtable, polling отключен. Вот top днем, когда нагрузка невысокая. В пике загрузки сервера CPU idle ~85% top -SH last pid: 39098; load averages: 0.44, 0.61, 0.56 up 0+23:34:55 15:01:39 163 processes: 9 running, 122 sleeping, 32 waiting CPU: 0.0% user, 0.0% nice, 5.9% system, 1.1% interrupt, 93.0% idle Mem: 370M Active, 510M Inact, 700M Wired, 272K Cache, 822M Buf, 6245M Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU6 6 23.5H 100.00% {idle: cpu6} 11 root 171 ki31 0K 128K CPU5 5 23.4H 100.00% {idle: cpu5} 11 root 171 ki31 0K 128K RUN 4 23.4H 100.00% {idle: cpu4} 11 root 171 ki31 0K 128K CPU3 3 23.2H 100.00% {idle: cpu3} 11 root 171 ki31 0K 128K CPU1 1 23.1H 100.00% {idle: cpu1} 11 root 171 ki31 0K 128K CPU7 7 23.5H 99.66% {idle: cpu7} 11 root 171 ki31 0K 128K CPU2 2 17.6H 75.59% {idle: cpu2} 11 root 171 ki31 0K 128K CPU0 0 16.8H 71.88% {idle: cpu0} 0 root -68 0 0K 336K - 2 153:07 15.48% {em0 taskq} 0 root -68 0 0K 336K - 2 166:42 14.89% {em1 taskq} 0 root -68 0 0K 336K - 0 94:47 10.79% {em2 taskq} 0 root -68 0 0K 336K - 2 133:54 9.38% {em3 taskq} 12 root -68 - 0K 512K WAIT 1 18:30 3.56% {irq257: igb0:que} 0 root -68 0 0K 336K - 0 155:54 2.59% {dummynet} 0 root -68 0 0K 336K - 2 26:09 1.95% {igb0 que} 12 root -68 - 0K 512K WAIT 0 16:22 0.59% {irq256: igb0:que} 12 root -68 - 0K 512K WAIT 3 15:21 0.39% {irq259: igb0:que} 12 root -68 - 0K 512K WAIT 2 15:52 0.10% {irq258: igb0:que} 2173 root 44 0 144M 137M select 1 10:35 0.00% bgpd 12 root -32 - 0K 512K WAIT 4 6:54 0.00% {swi4: clock} 0 root 44 0 0K 336K sched 0 3:02 0.00% {swapper} 13 root -16 - 0K 16K - 4 2:28 0.00% yarrow 12 root -68 - 0K 512K WAIT 0 1:23 0.00% {irq261: igb1:que} 12 root -68 - 0K 512K WAIT 1 1:05 0.00% {irq262: igb1:que} 12 root -68 - 0K 512K WAIT 3 0:59 0.00% {irq264: igb1:que} 2196 root 44 0 24896K 6420K select 1 0:59 0.00% snmpd 12 root -68 - 0K 512K WAIT 2 0:54 0.00% {irq263: igb1:que} 0 root -68 0 0K 336K - 0 0:39 0.00% {igb1 que} Если нужна какая информация пишите.

на самом деле это сделано чтоб банить клиентов в сетке с отрицательным балансом, ведь кроме инета есть и другие ресурсы, а управляемых свитчей увы пока немного ... а корректным отсоединением клиентов от инета занимается радиус сервер через соответствующий скрипт.

Напишу небольшой отчет может кому и поможет, а то я в свое время потратил кучу времени и нервов, как своих, так и клиентов. Выкладываю так, для информации. Что имеем: Сервер m/b S5000VSA, 8Gb Ram, 2 x Xeon E5420, 2 встроенные Intel PRO/1000 EB. Входящий канал 1Gbit/s, по нему идет интернет + городские ресурсы, так что нагрузка не хилая. Количество онлайн клиентов pptp 800-900. История: Пока по входящему каналу шёл только интернет со скоростью около 50Мбит/с, pptp сервер прекрасно работал и на poptop под FreeBSD 6.3 AMD64. Но когда подключили городские ресурсы на весь гигабит, машина стала медленно умирать, все 8 процов были загружены на 100%. Решили переходить на mpd. Сделал тюнинг системы и поставил mpd версии 5.3. Отлично, загрузка процов нравится. Idle их 75-80%. Радуемся не долго, часа через 2 сервер уходит в ребут. Почитал на форумах, оказалось я не одинок, проблема известная. Куча разных советов как с этим бороться, в основном говорят о проблеме из-за шейперов на dummynet, хреновых интеловских сетевых дровах, кривом netgraph-е и железе и т.п. Что не делал, один черт, то сервер ребутнется, то зависнет насмерть. Попробовал версии mpd 5.2, 5.1 проблема та же. Может проработать 2 часа, а может и 8. Прочитал что с 4 версией проблем меньше. Ставлю mpd 4.4.1, и быть не может, наконец то система работает 1 день без перезагрузки. Но... рано радоваться через некоторое время опять зависает. Перегружаем, работаем еще день и т.д. Выношу радиус сервер и шейпер(dummynet) на другой сервер, этот пытаюсь максимально разгрузить, остается только mpd, ipcad. Ставлю драйвера на сетевухи от yandex, кручу тюнинг системы. Один черт, НЕ помогает. Рано утром иду обновлять систему до 7.2 Amd64 релиз, ставлю mpd 5.3, сетевые драйвера 6.9.12 от интела и довольный иду спать, в надежде что в 7 версии было много изменений в сетевой подсистеме, и это должно помочь. Поспал... но не долго, через 3 часа ребут. В логах ничего интересного, одно только заметил, что перезагрузка произошла ровно в 10:30:00. И здесь появляется мысль: у меня по крону раз в 15 минут, скриптом идет обновление arp таблицы, и у тех клиентов кто ушел в минус маки забиваются нулями. Ну что делать, и этот скрипт выношу на другой сервер... И ВОТ ОНО ЧУДО!!! сервер работает, без перегрузов и зависонов день, два, три... Пытаюсь разобраться, что происходило: Клиент подключен к впн серверу и баланс уходит в минус, а радиус еще не успел его отключить от впн сервера. В это время проходит отработка скрипта по замене маков клиентов с минусовым балансом, и у netgrph-а похоже сносит от этого голову, а он соответственно тянет за собой всю систему. Ну это чисто мои предположения... Главное получили Vpn сервер на mpd5.3 под FreeBSD 7.2 AMD64 который работает стабильно. Idle процессоров в пиковое время 75-90%. То что надо... Выкладываю свои конфиги, которые получились после многократных тюнингов (сразу оговорюсь что они не претендуют на идеальность) /boot/loader.conf: if_em_load="YES" vm.kmem_size=1G vm.kmem_size_max=1G kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 net.inet.tcp.tcbhashsize=4096 kern.ipc.nsfbufs=10240 hw.em.rxd=1024 hw.em.txd=1024 net.graph.maxalloc=2048 kern.ipc.maxpipekva=200000000 /etc/sysctl.conf: kern.ipc.shmall=65536 kern.ipc.shmmax=268435456 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.nmbclusters=262144 kern.ipc.somaxconn=4096 kern.ipc.maxsockets=204800 kern.ipc.semmap=512 kern.maxfiles=204800 kern.maxfilesperproc=200000 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.randomized=0 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=65536 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=30000 net.inet.tcp.syncookies=1 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.fast_finwait2_recycle=1 kern.ipc.shm_use_phys=1 net.inet.icmp.icmplim=1000 net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.fastforwarding=1 net.graph.maxdgram=128000 net.graph.recvspace=128000 net.isr.direct=1 Конфиг kernel: за основу взят GENERIC, выкинуты все ненужные дрова, и добавлено: options IPFIREWALL options IPDIVERT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD options NETGRAPH Mpd.conf: startup: set user admin mypass admin set console self 192.168.1.1 5055 set console open default: load pptp_standart pptp_standart: create bundle template B set iface disable proxy-arp set iface idle 0 set iface enable tcpmssfix set ipcp no vjcomp set ipcp ranges 10.0.0.1/32 0.0.0.0/0 set ipcp dns 192.168.1.1 set bundle disable compression set bundle disable encryption set ccp no mppc set mppc no e40 set mppc no e128 set mppc no stateless create link template L pptp set link action bundle B set link disable multilink set link no acfcomp protocomp set link no pap chap set link enable chap-msv2 set link keep-alive 30 90 set link mtu 1460 set link enable incoming set link enable peer-as-calling set pptp self 192.168.1.1 load radius radius: set radius config /usr/local/etc/mpd5/radius.conf set radius server 192.168.1.2 mysecurity 1812 1813 set radius retries 3 set radius timeout 20 set radius me 192.168.1.1 set auth acct-update 300 set auth enable radius-auth set auth enable radius-acct set auth disable internal