utcon Опубликовано 26 июня, 2011 (изменено) · Жалоба Добрый вечер. Есть роутер - задачи 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мс. Интересно у кого какие методы :) Изменено 28 июня, 2011 пользователем utcon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 29 июня, 2011 (изменено) · Жалоба пинг растет из-за этого: ng_queue дальше будут потери... Мало информации что-бы что-нибудь советовать... Изменено 29 июня, 2011 пользователем _longhorn_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 29 июня, 2011 · Жалоба 21 root 44 - 0K 16K flowcl 7 35:57 0.93% flowcleaner оно рабатает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 29 июня, 2011 · Жалоба По поводу 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 и ниже ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 29 июня, 2011 · Жалоба 21 root 44 - 0K 16K flowcl 7 35:57 0.93% flowcleaner оно рабатает? Сейчас стоит net.inet.flowtable.enable=1 Думаете если сделаю net.inet.flowtable.enable=0 это поможет ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 30 июня, 2011 · Жалоба пиг растет когда канал ~100%, когда лоад 100% расти не должен сколько на нем роут? если "бодер", FW? Странно, что он вообще работает, наверное проц ооочень большой... там в стейбле его(flowtable) чинили, чинили и в результате выпилили из ядра совсем... одним словом net.inet.flowtable.enable=0 не все решает, хотя мне пересобирать было лень, более менее и так работает, хотя Ваших 300кппс на одном интерфейсе нету. при 300кппс на игб могут быть нюансы настроек самой карты, посмотрите кстати sysctl dev.igb Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 30 июня, 2011 · Жалоба Может кто то подсказать, будет ощутимый эффект, если раскидать трафик по нодам для експорта. И возможно это в принципе, попробовал сделать следующим образом, распределил нарезку трафика правилами До ната: 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 Зараза не работает, трафик в ноду попадает, но дальше не идет. Так вообще можно делать ? В нетграфе не силен :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 30 июня, 2011 · Жалоба Не выходит каменный цветок :(. Не експортит статистику на указанный ИП коллектора. Кто может сказать, будет работать конструкция вида: /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 молчит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 30 июня, 2011 · Жалоба там в стейбле его(flowtable) чинили, чинили и в результате выпилили из ядра совсем... одним словом net.inet.flowtable.enable=0 не все решает, хотя мне пересобирать было лень, более менее и так работает, хотя Ваших 300кппс на одном интерфейсе нету. Он остался, но для специфичных применений, и по дефолту отключён. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 30 июня, 2011 · Жалоба В общем, вроде бы экспорт пошел, Таким образом - получил кучу нод для экспорта, через каждую из которых проходит часть трафика бордера. Помогло ли это избежать переполнения загрузки по ядру процессом ng_queue расскажу посжее :)) Дам нагрузку и отпишусь. Хотя если чесно надежд мало .... нутром чую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
savago Опубликовано 30 июня, 2011 (изменено) · Жалоба Disable hyperthreading. devd_enable="NO" in /etc/rc.conf and in /etc/syctl.conf kern.random.sys.harvest.ethernet=0 давай увидем sysctl.conf,loader.conf,kernconf п.с попробаи так с ядро #options INET6 # IPv6 communications protocols #options SCTP # Stream Control Transmission Protocol #options FLOWTABLE # per-cpu routing cache Изменено 30 июня, 2011 пользователем savago Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 1 июля, 2011 · Жалоба devd_enable="NO" чем девд не угодил? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 1 июля, 2011 · Жалоба Disable hyperthreading. devd_enable="NO" in /etc/rc.conf and in /etc/syctl.conf kern.random.sys.harvest.ethernet=0 давай увидем sysctl.conf,loader.conf,kernconf п.с попробаи так с ядро #options INET6 # IPv6 communications protocols #options SCTP # Stream Control Transmission Protocol #options FLOWTABLE # per-cpu routing cache Добавил в переменные kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 Посмотрим :). Пока что роутер не нагружен по настоящему, поэтому говорить о чем то рано. Но посмотрим :). Ядро пока что не трогал. devd_enable="NO" не делал, потому что не понимаю зачем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 3 июля, 2011 (изменено) · Жалоба В общем не могу сказать, что добился каких то выдающихся результатов. В итоге все равно столкнулся когда 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 может присутствовать только в единственном экземпляре .... Изменено 4 июля, 2011 пользователем utcon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 4 июля, 2011 · Жалоба Ставьте второй тазик. У вас слишком много нетфлова и натов, в итоге это всё в кеш проца не влезает и при переключении задач слишком много с оперативы тянется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 4 июля, 2011 · Жалоба Поставить пару ipcad для netflow не судьба ? Хотя, если абориген не способен даже sysctl показать, чего еще ожидать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
utcon Опубликовано 4 июля, 2011 · Жалоба Поставить пару ipcad для netflow не судьба ? Хотя, если абориген не способен даже sysctl показать, чего еще ожидать... по той инфе которая известна "аборигену" 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 эти переменные уже такие надругательства выдержали .... так что сильно не ругайте. Хотя критику конечно услышать хочется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 5 июля, 2011 · Жалоба net.inet.ip.fastforwarding=0 и убрать дубли Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
savago Опубликовано 6 июля, 2011 · Жалоба Убери kern.hz="4000" vmstat -z|egrep 'ITEM|mbuf' systat -vmstat 1 netstat -m Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
