Jump to content
Калькуляторы

Рост пинга при > 300k pps Как бы сделать идеальный пинг :)

Добрый вечер.

 

Есть роутер -

задачи

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мс.

Интересно у кого какие методы :)

Edited by utcon

Share this post


Link to post
Share on other sites

пинг растет из-за этого:

ng_queue

 

дальше будут потери... Мало информации что-бы что-нибудь советовать...

Edited by _longhorn_

Share this post


Link to post
Share on other sites

21 root 44 - 0K 16K flowcl 7 35:57 0.93% flowcleaner

 

 

оно рабатает?

Share this post


Link to post
Share on other sites

По поводу 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 и ниже ?

Share this post


Link to post
Share on other sites

21 root 44 - 0K 16K flowcl 7 35:57 0.93% flowcleaner

 

 

оно рабатает?

 

Сейчас стоит net.inet.flowtable.enable=1

 

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

Share this post


Link to post
Share on other sites

пиг растет когда канал ~100%, когда лоад 100% расти не должен

 

сколько на нем роут? если "бодер", FW? Странно, что он вообще работает, наверное проц ооочень большой...

там в стейбле его(flowtable) чинили, чинили и в результате выпилили из ядра совсем...

одним словом net.inet.flowtable.enable=0 не все решает, хотя мне пересобирать было лень, более менее и так работает, хотя Ваших 300кппс на одном интерфейсе нету.

при 300кппс на игб могут быть нюансы настроек самой карты, посмотрите кстати sysctl dev.igb

Share this post


Link to post
Share on other sites

Может кто то подсказать, будет ощутимый эффект, если раскидать трафик по нодам для експорта.

И возможно это в принципе,

 

попробовал сделать следующим образом, распределил нарезку трафика правилами

До ната:

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

 

 

Зараза не работает, трафик в ноду попадает, но дальше не идет.

 

Так вообще можно делать ? В нетграфе не силен :(

Share this post


Link to post
Share on other sites

Не выходит каменный цветок :(.

Не експортит статистику на указанный ИП коллектора.

Кто может сказать, будет работать конструкция вида:

 

 /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 молчит.

Share this post


Link to post
Share on other sites
там в стейбле его(flowtable) чинили, чинили и в результате выпилили из ядра совсем... одним словом net.inet.flowtable.enable=0 не все решает, хотя мне пересобирать было лень, более менее и так работает, хотя Ваших 300кппс на одном интерфейсе нету.

 

Он остался, но для специфичных применений, и по дефолту отключён.

 

 

Share this post


Link to post
Share on other sites

В общем, вроде бы экспорт пошел,

Таким образом - получил кучу нод для экспорта, через каждую из которых проходит часть трафика бордера.

Помогло ли это избежать переполнения загрузки по ядру процессом ng_queue расскажу посжее :)) Дам нагрузку и отпишусь.

Хотя если чесно надежд мало .... нутром чую.

Share this post


Link to post
Share on other sites

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

Edited by savago

Share this post


Link to post
Share on other sites

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" не делал, потому что не понимаю зачем.

Share this post


Link to post
Share on other sites

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

В итоге все равно столкнулся когда 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 может присутствовать только в единственном экземпляре ....

Edited by utcon

Share this post


Link to post
Share on other sites

Ставьте второй тазик.

 

У вас слишком много нетфлова и натов, в итоге это всё в кеш проца не влезает и при переключении задач слишком много с оперативы тянется.

 

 

Share this post


Link to post
Share on other sites

Поставить пару ipcad для netflow не судьба ? Хотя, если абориген не способен даже sysctl показать, чего еще ожидать...

Share this post


Link to post
Share on other sites

Поставить пару 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

 

 

эти переменные уже такие надругательства выдержали .... так что сильно не ругайте. Хотя критику конечно услышать хочется.

Share this post


Link to post
Share on other sites

Убери kern.hz="4000"

 

vmstat -z|egrep 'ITEM|mbuf'

systat -vmstat 1

netstat -m

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this