utcon

Огромное спасибо, 3.0 отключим. А чего только по двум ядрам разбросаны эти прерывания ? Есть вариант как то на это влиять ? (смущает что ядре 8-мь а разброс виден только на 2 ядра),

Вот top -aSCHIP last pid: 6748; load averages: 1.59, 1.65, 1.64 up 2+20:27:09 12:11:33 167 processes: 10 running, 118 sleeping, 39 waiting CPU 0: 0.0% user, 0.0% nice, 5.9% system, 20.1% interrupt, 74.0% idle CPU 1: 0.0% user, 0.0% nice, 2.0% system, 58.7% interrupt, 39.4% idle CPU 2: 0.0% user, 0.0% nice, 8.3% system, 0.0% interrupt, 91.7% idle CPU 3: 0.0% user, 0.0% nice, 9.4% system, 0.0% interrupt, 90.6% idle CPU 4: 0.0% user, 0.0% nice, 8.3% system, 0.0% interrupt, 91.7% idle CPU 5: 0.0% user, 0.0% nice, 7.1% system, 0.0% interrupt, 92.9% idle CPU 6: 0.0% user, 0.0% nice, 7.5% system, 0.0% interrupt, 92.5% idle CPU 7: 0.0% user, 0.0% nice, 3.1% system, 0.0% interrupt, 96.9% idle Mem: 41M Active, 324M Inact, 656M Wired, 256K Cache, 206M Buf, 824M Free Swap: 5243M Total, 5243M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 155 ki31 0K 128K CPU7 7 59.5H 100.00% [idle{idle: cpu7}] 11 root 155 ki31 0K 128K CPU6 6 58.6H 98.49% [idle{idle: cpu6}] 11 root 155 ki31 0K 128K CPU2 2 55.3H 95.56% [idle{idle: cpu2}] 11 root 155 ki31 0K 128K CPU5 5 58.6H 95.36% [idle{idle: cpu5}] 11 root 155 ki31 0K 128K CPU3 3 58.1H 93.70% [idle{idle: cpu3}] 11 root 155 ki31 0K 128K RUN 4 57.1H 92.14% [idle{idle: cpu4}] 11 root 155 ki31 0K 128K CPU0 0 39.9H 79.79% [idle{idle: cpu0}] 12 root -88 - 0K 640K WAIT 1 21.9H 54.69% [intr{irq16: xhci1}] 11 root 155 ki31 0K 128K RUN 1 23.7H 33.54% [idle{idle: cpu1}] 0 root -92 0 0K 400K - 6 319:54 10.35% [kernel{igb3 que}] 0 root -92 0 0K 400K - 7 367:32 7.96% [kernel{igb1 que}] 12 root -92 - 0K 640K WAIT 0 311:56 6.01% [intr{irq266: igb3:que}] 12 root -92 - 0K 640K WAIT 0 260:54 5.96% [intr{irq260: igb1:que}] 0 root -92 0 0K 400K - 2 413:38 5.57% [kernel{igb2 que}] 0 root -92 0 0K 400K - 3 343:58 5.22% [kernel{igb3 que}] 0 root -92 0 0K 400K - 5 352:00 4.88% [kernel{igb1 que}] 0 root -92 0 0K 400K - 4 321:48 3.66% [kernel{igb0 que}] 12 root -92 - 0K 640K WAIT 1 200:37 3.66% [intr{irq258: igb0:que}] 12 root -92 - 0K 640K WAIT 1 236:08 3.42% [intr{irq267: igb3:que}] 12 root -92 - 0K 640K WAIT 1 192:13 3.27% [intr{irq261: igb1:que}] 0 root -92 0 0K 400K - 0 279:18 2.69% [kernel{em0 taskq}] 0 root -92 0 0K 400K - 1 295:56 2.39% [kernel{em3 taskq}] 12 root -92 - 0K 640K WAIT 1 190:55 2.29% [intr{irq264: igb2:que}] 12 root -92 - 0K 640K WAIT 0 227:42 1.07% [intr{irq257: igb0:que}] 12 root -92 - 0K 640K WAIT 0 243:57 0.88% [intr{irq263: igb2:que}] 0 root -92 0 0K 400K - 4 342:12 0.63% [kernel{igb2 que}] 0 root -92 0 0K 400K - 4 305:45 0.49% [kernel{igb0 que}] Что касается netisr [root@gw]# sysctl net.isr net.isr.numthreads: 8 net.isr.maxprot: 16 net.isr.defaultqlimit: 4096 net.isr.maxqlimit: 10240 net.isr.bindthreads: 1 net.isr.maxthreads: 8 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct

Добрый день. Есть шлюз (шейп, нат) (dummynet + ipfw) top -SPH last pid: 74548; load averages: 1.07, 1.02, 1.00 up 39+03:03:26 19:04:04 119 processes: 10 running, 88 sleeping, 1 zombie, 20 waiting CPU 0: 0.0% user, 0.0% nice, 16.7% system, 0.0% interrupt, 83.3% idle CPU 1: 0.0% user, 0.0% nice, 18.8% system, 0.0% interrupt, 81.3% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 64.6% interrupt, 35.4% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 75.0% interrupt, 25.0% idle CPU 4: 0.0% user, 0.0% nice, 40.4% system, 0.0% interrupt, 59.6% idle CPU 5: 0.0% user, 0.0% nice, 40.4% system, 0.0% interrupt, 59.6% idle CPU 6: 0.0% user, 0.0% nice, 6.3% system, 0.0% interrupt, 93.8% idle CPU 7: 0.0% user, 0.0% nice, 6.3% system, 0.0% interrupt, 93.8% idle Mem: 41M Active, 769M Inact, 1066M Wired, 55M Cache, 213M Buf, 37M Free Swap: 5243M Total, 5243M Free при этом [gw-151-20 ~]$ netstat -w1 input (Total) output packets errs idrops bytes packets errs bytes colls 355257 0 0 318256981 341995 0 293776057 0 Об]ясните пожалуйста, что за колонка interrupt напротив каждого ядра.(прерывания, но что за прерывания) И самое интересное - почему нагрузка в процентах только напротив 2-х из 8-ми ядер. В системе две pci-e сетевухи (одна 4-х головая, вторая 6-ти головая) [root@gw-151-7 /usr/home/kris]# vmstat -i interrupt total rate irq16: xhci1 19607884415 82363 irq18: em0 em1 em2+ 877008021 3683 irq19: em4 em5+ 478109820 2008 irq23: ehci0 ehci1 637712 2 cpu0:timer 981277648 4121 irq256: em6 883228 3 irq257: igb0:que 0 684588450 2875 irq258: igb0:que 1 757659213 3182 irq259: igb0:link 2 0 irq260: igb1:que 0 814657056 3422 irq261: igb1:que 1 831513082 3492 irq262: igb1:link 2 0 irq263: igb2:que 0 685350380 2878 irq264: igb2:que 1 763601256 3207 irq265: igb2:link 2 0 irq266: igb3:que 0 825591792 3467 irq267: igb3:que 1 838246720 3521 irq268: igb3:link 2 0 irq270: ahci1 991257 4 cpu1:timer 973962408 4091 cpu7:timer 579147261 2432 cpu2:timer 859086109 3608 cpu4:timer 705039272 2961 cpu3:timer 792264171 3327 cpu5:timer 806728568 3388 cpu6:timer 605893850 2545 Total 33470121697 140592

по той инфе которая известна "аборигену" ipcad работает на user-level и поэтому все вокруг вопят ng_netflow - наше все Есть удачный опыт ? Огласите статистику - НАТ + ng_netflow + shape в одном флаконе - количество pps проходящих через него loader.conf hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.num_queues=0 hw.igb.enable_aim=1 hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=6000 hw.igb.rx_process_limit=200 hw.igb.fc_setting=0 hw.igb.lro=0 hw.igb.max_interrupt_rate=32000 net.link.ifqmaxlen=1024 net.isr.defaultqlimit=4096 kern.ipc.nmbclusters="524288" kern.ipc.maxsockets="524288" net.graph.maxalloc="65536" net.graph.maxdata="65536" net.isr.numthreads=4 net.isr.maxthreads=4 kern.hz="4000" sysctl.conf kern.ipc.somaxconn=65535 net.inet.ip.portrange.first=6192 net.inet.ip.portrange.hifirst=6192 net.inet.ip.maxfragsperpacket=44 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.delayed_ack=0 net.inet.ip.fw.one_pass=0 net.graph.maxdgram=128000 net.graph.recvspace=128000 net.inet.ip.fw.dyn_buckets=49152 net.inet.ip.fw.dyn_max=49152 ### net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=2000 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 #dev.igb.1.rx_kthreads=4 #dev.igb.0.rx_kthreads=4 net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.dummynet.hash_size=16384 net.inet.ip.dummynet.expire=0 ###NEW kern.ipc.maxsockbuf=2097152 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=65535 net.inet.ip.dummynet.pipe_slot_limit=2048 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.udp.maxdgram=57344 net.inet.tcp.sendspace=65535 net.inet.udp.recvspace=65535 net.inet.ip.intr_queue_maxlen=5000 kern.ipc.shmmax=67108864 dev.igb.0.flow_control=0 dev.igb.1.flow_control=0 dev.igb.2.flow_control=0 dev.igb.3.flow_control=0 net.isr.direct=1 net.isr.direct_force=0 #### NEW net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 net.route.netisr_maxqlen=4096 net.isr.defaultqlimit=4096 net.link.ifqmaxlen=1024 dev.igb.0.rx_processing_limit=4096 dev.igb.1.rx_processing_limit=4096 dev.igb.2.rx_processing_limit=4096 dev.igb.3.rx_processing_limit=4096 эти переменные уже такие надругательства выдержали .... так что сильно не ругайте. Хотя критику конечно услышать хочется.

В общем не могу сказать, что добился каких то выдающихся результатов. В итоге все равно столкнулся когда ng_queue0 сделал на одном ядре WCPU 100% и все.... Нашел в сети, что можно (http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024740.html) Тобишь 16 ng_nat nodes connected to ng_ipfw. Sometimes one ng_queue eats 100% of one core while other 3 ng_queues sit idle. I'm going to set queueing on all ng_nat's hooks to see if it will help. На сколько я понял, ситуация очень похожа с моей. Только вот как to set queueing on all ng_nat's hooks ума не приложу. Выходит мало просто создать хуки, их надо еще как то set queueing .... Кто то может просветить, что имеется ввиду ? У меня сейчас : # ngctl list There are 61 total nodes: Name: <unnamed> Type: ksocket ID: 0000010d Num hooks: 1 Name: <unnamed> Type: ksocket ID: 00000103 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000f9 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000ef Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000e5 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000db Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000d1 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000c7 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000bd Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000b3 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 000000a9 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 0000009f Num hooks: 1 Name: <unnamed> Type: ksocket ID: 00000095 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 0000008b Num hooks: 1 Name: <unnamed> Type: ksocket ID: 00000081 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 00000077 Num hooks: 1 Name: <unnamed> Type: ksocket ID: 0000006d Num hooks: 1 Name: <unnamed> Type: ksocket ID: 00000063 Num hooks: 1 Name: re0 Type: ether ID: 00000006 Num hooks: 0 Name: ngctl24219 Type: socket ID: 00000112 Num hooks: 0 Name: nat10 Type: nat ID: 0000001d Num hooks: 2 Name: nat11 Type: nat ID: 0000001f Num hooks: 2 Name: nat12 Type: nat ID: 00000021 Num hooks: 2 Name: nat13 Type: nat ID: 00000023 Num hooks: 2 Name: nat14 Type: nat ID: 00000025 Num hooks: 2 Name: nat15 Type: nat ID: 00000027 Num hooks: 2 Name: nat16 Type: nat ID: 00000029 Num hooks: 2 Name: netflow1 Type: netflow ID: 0000005e Num hooks: 3 Name: netflow2 Type: netflow ID: 00000068 Num hooks: 3 Name: netflow3 Type: netflow ID: 00000072 Num hooks: 3 Name: netflow4 Type: netflow ID: 0000007c Num hooks: 3 Name: netflow5 Type: netflow ID: 00000086 Num hooks: 3 Name: netflow6 Type: netflow ID: 00000090 Num hooks: 3 Name: netflow7 Type: netflow ID: 0000009a Num hooks: 3 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 70 Name: netflow8 Type: netflow ID: 000000a4 Num hooks: 3 Name: netflow9 Type: netflow ID: 000000ae Num hooks: 3 Name: nat Type: nat ID: 00000009 Num hooks: 2 Name: vlan123 Type: ether ID: 00000007 Num hooks: 0 Name: netflow10 Type: netflow ID: 000000b8 Num hooks: 3 Name: netflow11 Type: netflow ID: 000000c2 Num hooks: 3 Name: netflow12 Type: netflow ID: 000000cc Num hooks: 3 Name: igb0 Type: ether ID: 00000002 Num hooks: 0 Name: netflow13 Type: netflow ID: 000000d6 Num hooks: 3 Name: igb1 Type: ether ID: 00000003 Num hooks: 0 Name: netflow14 Type: netflow ID: 000000e0 Num hooks: 3 Name: igb2 Type: ether ID: 00000004 Num hooks: 0 Name: netflow15 Type: netflow ID: 000000ea Num hooks: 3 Name: igb3 Type: ether ID: 00000005 Num hooks: 0 Name: netflow16 Type: netflow ID: 000000f4 Num hooks: 3 Name: netflow17 Type: netflow ID: 000000fe Num hooks: 3 Name: netflow18 Type: netflow ID: 00000108 Num hooks: 3 Name: nat1 Type: nat ID: 0000000b Num hooks: 2 Name: nat2 Type: nat ID: 0000000d Num hooks: 2 Name: nat3 Type: nat ID: 0000000f Num hooks: 2 Name: nat4 Type: nat ID: 00000011 Num hooks: 2 Name: nat5 Type: nat ID: 00000013 Num hooks: 2 Name: nat6 Type: nat ID: 00000015 Num hooks: 2 Name: nat7 Type: nat ID: 00000017 Num hooks: 2 Name: nat8 Type: nat ID: 00000019 Num hooks: 2 Name: nat9 Type: nat ID: 0000001b Num hooks: 2 Смущает вот эта строчка Name: ipfw Type: ipfw ID: 00000001 Num hooks: 70 Но неужели можно сделать как то иначе ? Создать обьект ipfw1 с типом ipfw и завязать на него часть хуков .... Каша в голове .... Ведь узел ipfw может присутствовать только в единственном экземпляре ....

Добавил в переменные kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 Посмотрим :). Пока что роутер не нагружен по настоящему, поэтому говорить о чем то рано. Но посмотрим :). Ядро пока что не трогал. devd_enable="NO" не делал, потому что не понимаю зачем.

В общем, вроде бы экспорт пошел, Таким образом - получил кучу нод для экспорта, через каждую из которых проходит часть трафика бордера. Помогло ли это избежать переполнения загрузки по ядру процессом ng_queue расскажу посжее :)) Дам нагрузку и отпишусь. Хотя если чесно надежд мало .... нутром чую.

Не выходит каменный цветок :(. Не експортит статистику на указанный ИП коллектора. Кто может сказать, будет работать конструкция вида: /usr/sbin/ngctl mkpeer ipfw: netflow 216 iface0 /usr/sbin/ngctl name ipfw:216 netflow16 /usr/sbin/ngctl connect ipfw: netflow16: 316 out0 /usr/sbin/ngctl msg netflow16: settimeouts '{' inactive=30 active=600 '}' /usr/sbin/ngctl mkpeer netflow16: ksocket export inet/dgram/udp /usr/sbin/ngctl msg netflow16:export connect inet/IP_OF_COLLECTOR:9996 /usr/sbin/ngctl msg netflow16: setdlt '{' iface=0 dlt=12 '}' /usr/sbin/ngctl msg netflow16: setifindex '{' iface=0 index=5 '}' /usr/sbin/ngctl mkpeer ipfw: netflow 217 iface0 /usr/sbin/ngctl name ipfw:217 netflow17 /usr/sbin/ngctl connect ipfw: netflow17: 317 out0 /usr/sbin/ngctl msg netflow17: settimeouts '{' inactive=30 active=600 '}' /usr/sbin/ngctl mkpeer netflow17: ksocket export inet/dgram/udp /usr/sbin/ngctl msg netflow17:export connect inet/P_OF_COLLECTOR:9996 /usr/sbin/ngctl msg netflow17: setdlt '{' iface=0 dlt=12 '}' /usr/sbin/ngctl msg netflow17: setifindex '{' iface=0 index=5 '}' Когда несколько нод експортят на один коллектор. Коллектор - один и тот же ИП. (не путать с дублированием статистики на несколько хостов) Если съема рабочая - подскажите в чем ошибка. Всю голову уже сломал. Трафик нормально проходит через правила и отсчитывается в счетчике ipfw, но не експортит саму статистику на удаленный хост, хоть ты тресни. tcpdump молчит.

Может кто то подсказать, будет ощутимый эффект, если раскидать трафик по нодам для експорта. И возможно это в принципе, попробовал сделать следующим образом, распределил нарезку трафика правилами До ната: 02200 0 0 netgraph 181 ip from table(71) to any out 02300 0 0 netgraph 182 ip from table(72) to any out 02400 0 0 netgraph 183 ip from table(73) to any out 02500 0 0 netgraph 184 ip from table(74) to any out 02600 0 0 netgraph 185 ip from table(75) to any out 02700 0 0 netgraph 186 ip from table(76) to any out 02800 0 0 netgraph 187 ip from table(77) to any out 02900 0 0 netgraph 188 ip from table(78) to any out 03000 0 0 netgraph 189 ip from table(79) to any out 03100 0 0 netgraph 190 ip from table(80) to any out 03200 0 0 netgraph 191 ip from table(81) to any out 03300 0 0 netgraph 192 ip from table(82) to any out 03400 0 0 netgraph 193 ip from table(83) to any out 03500 0 0 netgraph 194 ip from table(84) to any out 03600 0 0 netgraph 195 ip from table(85) to any out 03700 0 0 netgraph 196 ip from table(86) to any out 03800 0 0 netgraph 197 ip from table(87) to any out 03900 0 0 netgraph 198 ip from table(88) to any out После ната 06100 0 0 netgraph 181 ip from any to table(71) in 06200 0 0 netgraph 182 ip from any to table(72) in 06300 0 0 netgraph 183 ip from any to table(73) in 06400 0 0 netgraph 184 ip from any to table(74) in 06500 0 0 netgraph 185 ip from any to table(75) in 06600 0 0 netgraph 186 ip from any to table(76) in 06700 0 0 netgraph 187 ip from any to table(77) in 06800 0 0 netgraph 188 ip from any to table(78) in 06900 0 0 netgraph 189 ip from any to table(79) in 07000 0 0 netgraph 190 ip from any to table(80) in 07100 0 0 netgraph 191 ip from any to table(81) in 07200 0 0 netgraph 192 ip from any to table(82) in 07300 0 0 netgraph 193 ip from any to table(83) in 07400 0 0 netgraph 194 ip from any to table(84) in 07500 0 0 netgraph 195 ip from any to table(85) in 07600 0 0 netgraph 196 ip from any to table(86) in 07700 0 0 netgraph 197 ip from any to table(87) in 07800 0 0 netgraph 198 ip from any to table(88) in А потом #!/usr/local/bin/bash -x ipfw='/sbin/ipfw -q' z=0 for ((i=0; i<=60; i=i+4)); do z=$((z+1)) n=$(($z+70)) k=$(($z+200)) ${ipfw} table $n add 10.0.$i.0/22 /usr/sbin/ngctl mkpeer ipfw: netflow $n iface0 /usr/sbin/ngctl name ipfw:$n netflow$z /usr/sbin/ngctl connect ipfw: netflow$z: $k out0 /usr/sbin/ngctl msg netflow$z: settimeouts { inactive=30 active=600 } /usr/sbin/ngctl mkpeer netflow$z: ksocket export inet/dgram/udp /usr/sbin/ngctl msg netflow$z:export connect inet/А.А.А.А:9996 /usr/sbin/ngctl msg netflow$z: setdlt { iface=0 dlt=12 } /usr/sbin/ngctl msg netflow$z: setifindex { iface=0 index=5 } done Зараза не работает, трафик в ноду попадает, но дальше не идет. Так вообще можно делать ? В нетграфе не силен :(

Сейчас стоит net.inet.flowtable.enable=1 Думаете если сделаю net.inet.flowtable.enable=0 это поможет ?

По поводу ng_queue - я в курсе, это НАТ + статистика по нетграфу. И когда трафик растет - один из процессов начинает кушать ядро. НАТ у меня реализован через 10 потоков нетграфа, а учет статистики - через одно, конструкция типа $cmd netgraph 11 ipv4 from not table\(100\) to $NatIP in via $oif $cmd netgraph 21 ipv4 from not table\(100\) to $NatIP1 in via $oif $cmd netgraph 31 ipv4 from not table\(100\) to $NatIP2 in via $oif $cmd netgraph 41 ipv4 from not table\(100\) to $NatIP3 in via $oif $cmd netgraph 51 ipv4 from not table\(100\) to $NatIP4 in via $oif $cmd netgraph 61 ipv4 from not table\(100\) to $NatIP5 in via $oif $cmd netgraph 71 ipv4 from not table\(100\) to $NatIP6 in via $oif $cmd netgraph 81 ipv4 from not table\(100\) to $NatIP7 in via $oif $cmd netgraph 91 ipv4 from not table\(100\) to $NatIP8 in via $oif $cmd netgraph 101 ipv4 from not table\(100\) to $NatIP9 in via $oif $cmd netgraph 111 ipv4 from not table\(100\) to $NatIP10 in via $oif $cmd netgraph 121 ipv4 from not table\(100\) to $NatIP11 in via $oif $cmd netgraph 131 ipv4 from not table\(100\) to $NatIP12 in via $oif $cmd netgraph 141 ipv4 from not table\(100\) to $NatIP13 in via $oif $cmd netgraph 151 ipv4 from not table\(100\) to $NatIP14 in via $oif $cmd netgraph 161 ipv4 from not table\(100\) to $NatIP15 in via $oif $cmd netgraph 171 ipv4 from not table\(100\) to $NatIP16 in via $oif $cmd netgraph 181 ip from any to any in /usr/sbin/ngctl mkpeer ipfw: netflow 181 iface0 /usr/sbin/ngctl name ipfw:181 netflow /usr/sbin/ngctl connect ipfw: netflow: 180 out0 /usr/sbin/ngctl msg netflow: settimeouts { inactive=30 active=600 } /usr/sbin/ngctl mkpeer netflow: ksocket export inet/dgram/udp /usr/sbin/ngctl msg netflow:export connect inet/Х.Х.Х.Х:9996 /usr/sbin/ngctl msg netflow: setdlt { iface=0 dlt=12 } /usr/sbin/ngctl msg netflow: setifindex { iface=0 index=5 } 181-й поток - как раз нетфлов статистика. Боюсь придется создавать несколько потоков и делить по ним учитываемый трафик, что бы размазать по ядрам.... Просто у меня подозрение, что торренты выжрут и ту дельту по производительности, которую выиграю таким образом. неужели ни у кого нет хитростей по приоритезации icmp через бордеры ? У всех что ли растет пинг, когда бордер работает с 40% idle и ниже ?

Добрый вечер. Есть роутер - задачи NAT (ng_nat) + SHAPE (dummynet) + netflow (netgraph) FreeBsd 8.2 Lagg интерфейсы Сетевая - igb (Intel ET какая то там) Имеем [root@gw-151-12 # ipfw list|wc -l 67 [root@gw-151-12 # netstat -hw1 -i lagg1 input (Total) output packets errs idrops bytes packets errs bytes colls 298K 0 0 284M 274K 0 233M 0 267K 0 0 250M 247K 0 205M 0 286K 0 0 269M 263K 0 220M 0 [root@gw-151-12]# top -SPHI last pid: 86747; load averages: 0.99, 1.02, 1.00 up 4+23:13:45 22:46:08 196 processes: 10 running, 128 sleeping, 1 zombie, 57 waiting CPU 0: 0.0% user, 0.0% nice, 12.7% system, 9.2% interrupt, 78.1% idle CPU 1: 0.0% user, 0.0% nice, 12.6% system, 7.7% interrupt, 79.7% idle CPU 2: 0.0% user, 0.0% nice, 16.5% system, 5.4% interrupt, 78.2% idle CPU 3: 0.0% user, 0.0% nice, 15.7% system, 6.9% interrupt, 77.4% idle CPU 4: 0.0% user, 0.0% nice, 9.6% system, 12.7% interrupt, 77.7% idle CPU 5: 0.0% user, 0.0% nice, 10.4% system, 5.0% interrupt, 84.6% idle CPU 6: 0.0% user, 0.0% nice, 1.5% system, 6.2% interrupt, 92.3% idle CPU 7: 0.0% user, 0.0% nice, 1.2% system, 22.3% interrupt, 76.5% idle Mem: 29M Active, 362M Inact, 909M Wired, 12K Cache, 212M Buf, 665M Free Swap: 5243M Total, 5243M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU6 6 109.7H 96.48% {idle: cpu6} 11 root 171 ki31 0K 128K RUN 4 106.4H 91.70% {idle: cpu4} 11 root 171 ki31 0K 128K RUN 5 107.0H 90.04% {idle: cpu5} 11 root 171 ki31 0K 128K CPU2 2 100.9H 84.28% {idle: cpu2} 11 root 171 ki31 0K 128K CPU3 3 101.8H 80.52% {idle: cpu3} 11 root 171 ki31 0K 128K CPU7 7 101.4H 79.69% {idle: cpu7} 11 root 171 ki31 0K 128K CPU1 1 101.3H 78.32% {idle: cpu1} 11 root 171 ki31 0K 128K CPU0 0 100.7H 78.22% {idle: cpu0} 13 root 71 - 0K 128K sleep 3 326:39 30.96% {ng_queue5} 13 root 70 - 0K 128K CPU4 4 427:15 26.42% {ng_queue0} 13 root 76 - 0K 128K sleep 4 501:14 10.99% {ng_queue7} 12 root -44 - 0K 912K WAIT 7 283:55 5.42% {swi1: netisr 7} 12 root -44 - 0K 912K WAIT 7 282:13 5.13% {swi1: netisr 5} 12 root -44 - 0K 912K WAIT 7 166:45 5.08% {swi1: netisr 6} 12 root -68 - 0K 912K WAIT 7 109:21 3.52% {irq263: igb0:que} 12 root -68 - 0K 912K WAIT 6 92:31 2.88% {irq289: igb3:que} 13 root 76 - 0K 128K sleep 4 455:24 2.20% {ng_queue6} 12 root -44 - 0K 912K WAIT 1 182:49 2.15% {swi1: netisr 0} 0 root -68 0 0K 624K - 2 226:01 2.00% {dummynet} 12 root -68 - 0K 912K WAIT 6 83:45 2.00% {irq271: igb1:que} 12 root -32 - 0K 912K WAIT 1 65:20 1.76% {swi4: clock} 12 root -68 - 0K 912K WAIT 0 92:08 1.66% {irq265: igb1:que} 12 root -68 - 0K 912K WAIT 2 110:35 1.51% {irq258: igb0:que} 12 root -68 - 0K 912K WAIT 6 168:00 1.37% {irq262: igb0:que} 12 root -68 - 0K 912K WAIT 0 108:51 1.27% {irq274: igb2:que} 12 root -68 - 0K 912K WAIT 0 86:50 1.27% {irq283: igb3:que} 12 root -68 - 0K 912K WAIT 0 79:31 1.27% {irq256: igb0:que} 12 root -68 - 0K 912K WAIT 4 82:03 1.17% {irq269: igb1:que} 12 root -68 - 0K 912K WAIT 3 94:07 1.07% {irq259: igb0:que} 12 root -68 - 0K 912K WAIT 5 36:30 1.03% {irq279: igb2:que} 12 root -68 - 0K 912K WAIT 1 95:39 0.98% {irq257: igb0:que} 12 root -68 - 0K 912K WAIT 2 87:11 0.93% {irq267: igb1:que} 12 root -68 - 0K 912K WAIT 4 44:43 0.93% {irq278: igb2:que} 21 root 44 - 0K 16K flowcl 7 35:57 0.93% flowcleaner 12 root -68 - 0K 912K WAIT 2 48:46 0.88% {irq276: igb2:que} 12 root -68 - 0K 912K WAIT 7 44:50 0.88% {irq290: igb3:que} 12 root -68 - 0K 912K WAIT 6 96:47 0.83% {irq280: igb2:que} 12 root -68 - 0K 912K WAIT 3 48:16 0.83% {irq286: igb3:que} 12 root -68 - 0K 912K WAIT 3 81:10 0.78% {irq268: igb1:que} 12 root -68 - 0K 912K WAIT 4 75:23 0.78% {irq260: igb0:que} 12 root -68 - 0K 912K WAIT 5 85:09 0.73% {irq261: igb0:que} 12 root -68 - 0K 912K WAIT 1 78:14 0.73% {irq266: igb1:que} 12 root -68 - 0K 912K WAIT 1 57:05 0.63% {irq284: igb3:que} 12 root -68 - 0K 912K WAIT 1 36:54 0.63% {irq275: igb2:que} 12 root -68 - 0K 912K WAIT 4 34:25 0.54% {irq287: igb3:que} 12 root -32 - 0K 912K WAIT 2 6:17 0.54% {swi4: clock} 12 root -68 - 0K 912K WAIT 7 72:28 0.49% {irq272: igb1:que} 12 root -68 - 0K 912K WAIT 5 46:16 0.49% {irq288: igb3:que} Во общем все отлично, пока трафик не начинает превышать 300k pps Как только он превышает - растет пинг до 20-30 мс. И скачет, от 10 мс, то 25 и т.д. Вопрос - как я этим бороться ? Как боретесь вы ? Даете приоритет icmp трафику, что бы он был на уровне 1мс ? Еще одно - сейчас трубы в ipfw работают без очередей. Нужны они в принципе, или при больших нагрузках от них больше вреда чем пользы ? В общем задача - сделать пинг идеальным на уровне 1мс. Интересно у кого какие методы :)

Копался кропался и смутил меня вывод команды vmstat -z NetGraph items: 72, 4118, 0, 203, 531, 0 NetGraph data items: 72, 522, 6, 516, 7926717054, 37233172 Добавил в /boot/loader.conf hw.em.rxd=4096 hw.em.txd=4096 kern.ipc.nmbclusters="524288" kern.ipc.maxsockets="524288" net.graph.maxalloc="65536" net.graph.maxdata="4096" Буду смотреть дальше. Но у меня есть предчуствие, что основная проблема в том, что и НАТ и шепинг и netflow export находяться на одном и том же сервере. Может кто нибуть посоветует, как грамотно разносить эти вещи, что бы выжать передачу данных близкую к гигабиту в дублексе и без потерь ? Может ng_nat + ipfw pipes + ng_netflow - на одном сервере плохая идея ? Или сама связка - плохая идея ? Или прокладка плохая .....

Добрый вечер. Имеем: 8.2-RC2 FreeBSD 8.2-RC2 #0 cat /boot/loader.conf geom_mirror_load=YES [root@gw-151-243 /etc]# cat sysctl.conf kern.ipc.somaxconn=65535 net.inet.ip.portrange.first=6192 net.inet.ip.portrange.hifirst=6192 net.inet.ip.maxfragsperpacket=44 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.delayed_ack=0 net.inet.ip.fw.one_pass=0 net.graph.maxdgram=256000 net.graph.recvspace=256000 net.inet.ip.fw.dyn_buckets=49152 net.inet.ip.fw.dyn_max=49152 ### net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=2000 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 dev.em.0.rx_int_delay=600 dev.em.1.rx_int_delay=600 dev.em.0.tx_int_delay=600 dev.em.1.tx_int_delay=600 dev.em.0.rx_abs_int_delay=1000 dev.em.1.rx_abs_int_delay=1000 dev.em.0.tx_abs_int_delay=1000 dev.em.1.tx_abs_int_delay=1000 dev.em.0.rx_processing_limit=3000 dev.em.1.rx_processing_limit=3000 net.inet.ip.intr_queue_maxlen=1000 kern.ipc.nmbclusters=262144 net.inet.ip.dummynet.hash_size=16384 net.inet.ip.dummynet.expire=0 net.isr.direct=0 em0@pci0:10:0:0: class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet em1@pci0:10:0:1: class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet Задачи которые на нем крутятся: Шейпер IPFW DUMMYNET клиенты разбросаны в таблицы и с помощью pipe tablearg загоняются в трубы NAT с помощью netgraph Опять таки таблицы и netgraph tablearg ipv4 from ..... Netflow статистика - тот же нетграф сбрасывает експорт. Ведется статистика пинга с самого сервера. При возростании нагрузки наблюдаю небольшие потери. Проблемы с каналом уже исключил. Нагрузка небольшая [root@gw-151-243 /etc/ipfw]# netstat -w1 -I em1 input (em1) output packets errs idrops bytes packets errs bytes colls 32922 0 0 34538921 27698 0 20385935 0 37058 0 0 39821583 30838 0 21882675 0 37036 0 0 38833974 31588 0 23593679 0 37104 0 0 39352120 31032 0 22333503 0 36235 0 0 38189419 30560 0 22402593 0 36483 0 0 39037205 30131 0 21606306 0 36420 0 0 37921393 31485 0 23956993 0 34324 0 0 33656154 32379 0 26870038 0 36538 0 0 38430446 31394 0 23343891 0 37556 0 0 40794607 29682 0 21966534 0 top -SPHI last pid: 81003; load averages: 1.51, 1.38, 1.29 up 2+13:59:18 22:52:10 98 processes: 6 running, 73 sleeping, 1 zombie, 18 waiting CPU 0: 0.0% user, 0.0% nice, 29.3% system, 12.8% interrupt, 57.9% idle CPU 1: 0.0% user, 0.0% nice, 23.7% system, 14.7% interrupt, 61.7% idle CPU 2: 0.0% user, 0.0% nice, 29.3% system, 4.5% interrupt, 66.2% idle CPU 3: 0.0% user, 0.0% nice, 26.7% system, 1.5% interrupt, 71.8% idle Mem: 22M Active, 282M Inact, 372M Wired, 176K Cache, 213M Buf, 1301M Free Swap: 5243M Total, 5243M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K RUN 3 52.8H 71.58% {idle: cpu3} 11 root 171 ki31 0K 64K RUN 1 47.2H 69.58% {idle: cpu1} 11 root 171 ki31 0K 64K CPU2 2 51.9H 65.77% {idle: cpu2} 11 root 171 ki31 0K 64K CPU0 0 45.9H 63.09% {idle: cpu0} 12 root -44 - 0K 288K WAIT 0 431:00 32.18% {swi1: netisr 0} 13 root 76 - 0K 64K sleep 2 425:27 25.20% {ng_queue3} 13 root 76 - 0K 64K sleep 3 307:27 24.66% {ng_queue2} 13 root 61 - 0K 64K CPU1 0 414:07 20.26% {ng_queue1} 0 root -68 0 0K 144K - 2 430:12 19.78% {em0 taskq} 13 root 76 - 0K 64K sleep 3 405:49 10.99% {ng_queue0} 0 root -68 0 0K 144K - 3 304:45 5.57% {em1 taskq} 12 root -32 - 0K 288K WAIT 3 47:54 1.95% {swi4: clock} 0 root -68 0 0K 144K - 1 206:36 0.10% {dummynet} Что может провоцировать потери при пинге с сервера ? Куда копать ? думминет цпусетом поприбивал к ядрам. Паараметры сетевой после загрузки из sysctl.conf переприменил. Статистика потерь во вложении.

Добрый день. Имеется [root@gw-151-143 /var/log]# uname -a FreeBSD gw-151-143.cnm.local 8.2-RC3 FreeBSD 8.2-RC3 #1: Mon Feb 14 20:20:52 EET 2011 root@gw-151-20.cnm.local:/usr/src/sys/amd64/compile/GENERIC amd64 Хочу собрать свое ядро. Сделал в /usr/src/ make buildkernel KERNCONF=AMD64_IPFW make installkernel KERNCONF=AMD64_IPFW перезагрузился. [root@gw-151-143 /usr/home/kris]# uname -a FreeBSD gw-151-143.cnm.local 8.2-RC3 FreeBSD 8.2-RC3 #1: Mon Feb 14 20:20:52 EET 2011 root@gw-151-20.cnm.local:/usr/src/sys/amd64/compile/GENERIC amd64 /usr/obj чистил Почему в системе может отображаться ядро GENERIC ? При том что сборка и установка ядра - без задоринки, а ident AMD64_IPFW