Dyr Опубликовано 11 января, 2012 · Жалоба Ну я так и понял. SMT лишнее, ИМХО, хотя до того, как вы начнёте испытывать с этим проблемы, ещё далеко. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 11 января, 2012 · Жалоба Ну я так и понял. SMT лишнее, ИМХО, хотя до того, как вы начнёте испытывать с этим проблемы, ещё далеко. :) Какого плана проблемы? Для распихивания прерываний по ядрам SMT подходит очень даже неплохо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 11 января, 2012 · Жалоба Сетевая обработка пакетов и SMT (HTT) плохо сочетаются друг с другом. Источник - документация Intel на сетевые карты и, собственно, данный форум. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 января, 2012 · Жалоба Узким местом всё же был не PF, а слабая сетевая и процессор. Стоило обновить сервер, как гигабит стал проходить просто прекрасно. Проблемы с GRE удалось решить блоком правил: Возьму на заметку, только гре уже почти нигде у меня нет :) А почему не написали одним правилом? inet тоже можно выкинуть, тогда и ipv6 будет работать. pass quick on $ext_if inet proto gre all no state Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 11 января, 2012 · Жалоба Ну да, логично. Поправлю, спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 11 января, 2012 · Жалоба Сетевая обработка пакетов и SMT (HTT) плохо сочетаются друг с другом. Источник - документация Intel на сетевые карты и, собственно, данный форум. Что такое сетевая обработка пакетов? Может быть обработка сетевых пакетов? Пруфлинк-то будет? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 21 января, 2012 (изменено) · Жалоба pf nat: [#gw:/]# pfctl -si Status: Enabled for 42 days 08:24:47 Debug: Urgent State Table Total Rate current entries 198624 searches 516907969205 141266.9/s inserts 10844834275 2963.8/s removals 10844635651 2963.8/s Counters match 22404854572 6123.1/s bad-offset 0 0.0/s fragment 60212 0.0/s short 38507 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 245766 0.1/s proto-cksum 1649317 0.5/s state-mismatch 8756473 2.4/s state-insert 25891 0.0/s state-limit 0 0.0/s src-limit 40 0.0/s synproxy 0 0.0/s [#gw:/]# top -SPH last pid: 81900; load averages: 0.05, 0.06, 0.07 up 42+08:31:22 20:48:43 139 processes: 13 running, 96 sleeping, 30 waiting CPU 0: 1.3% user, 0.0% nice, 1.3% system, 7.6% interrupt, 89.9% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 70.9% interrupt, 29.1% idle CPU 2: 0.0% user, 0.0% nice, 28.2% system, 0.0% interrupt, 71.8% idle CPU 3: 1.3% user, 0.0% nice, 0.0% system, 0.0% interrupt, 98.7% idle CPU 4: 3.8% user, 0.0% nice, 1.3% system, 0.0% interrupt, 94.9% idle CPU 5: 0.0% user, 0.0% nice, 1.3% system, 0.0% interrupt, 98.7% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 30.4% interrupt, 69.6% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 32.9% interrupt, 67.1% idle Mem: 403M Active, 2250M Inact, 689M Wired, 16K Cache, 414M Buf, 537M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 128K RUN 4 918.6H 100.00% {idle: cpu4} 10 root 171 ki31 0K 128K CPU5 5 910.7H 100.00% {idle: cpu5} 10 root 171 ki31 0K 128K CPU3 3 954.3H 98.83% {idle: cpu3} 10 root 171 ki31 0K 128K CPU0 0 938.2H 96.53% {idle: cpu0} 10 root 171 ki31 0K 128K RUN 2 954.3H 82.47% {idle: cpu2} 10 root 171 ki31 0K 128K CPU6 6 911.7H 76.37% {idle: cpu6} 11 root -44 - 0K 528K CPU7 7 359.0H 71.09% {swi1: netisr 0} 10 root 171 ki31 0K 128K RUN 7 903.9H 69.14% {idle: cpu7} 11 root -44 - 0K 528K CPU1 1 381.3H 63.67% {swi1: netisr 7} 10 root 171 ki31 0K 128K RUN 1 576.7H 33.35% {idle: cpu1} 0 root -68 0 0K 224K CPU2 2 114.3H 24.27% {dummynet} 11 root -68 - 0K 528K WAIT 0 35.1H 5.18% {irq256: igb0:que} 11 root -68 - 0K 528K WAIT 0 34.2H 5.13% {irq259: igb1:que} 11 root -68 - 0K 528K WAIT 1 29.9H 4.25% {irq257: igb0:que} 11 root -68 - 0K 528K WAIT 1 27.5H 3.17% {irq260: igb1:que} 0 root -68 0 0K 224K - 3 641:02 1.95% {igb0 que} 11 root -32 - 0K 528K CPU6 6 588:00 1.66% {swi4: clock} 0 root -68 0 0K 224K - 5 587:38 0.68% {igb0 que} 6 root 44 - 0K 16K pftm 2 326:22 0.34% pfpurge 12728 bind 44 0 240M 209M ucond 4 71:31 0.15% {named} 0 root -68 0 0K 224K - 3 130:31 0.10% {igb1 que} 12728 bind 44 0 240M 209M kqread 5 73:48 0.10% {named} 12728 bind 44 0 240M 209M ucond 0 71:33 0.10% {named} 12728 bind 44 0 240M 209M ucond 0 71:27 0.10% {named} 12728 bind 44 0 240M 209M ucond 0 71:31 0.05% {named} 12728 bind 44 0 240M 209M ucond 3 71:29 0.05% {named} 12728 bind 44 0 240M 209M ucond 4 71:27 0.05% {named} 82723 root 44 0 211M 190M select 2 143:38 0.00% snmpd 13 root 44 - 0K 16K - 5 101:55 0.00% yarrow [#gw:/]# netstat -hW -w 1 input (Total) output packets errs idrops bytes packets errs bytes colls 172K 0 0 110M 186K 0 160M 0 166K 0 0 107M 178K 0 152M 0 168K 0 0 108M 180K 0 154M 0 165K 0 0 104M 177K 0 150M 0 [#gw:/]# cat /var/run/dmesg.boot | grep -i cpu CPU: Intel® Xeon® CPU X3450 @ 2.67GHz (2666.65-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs igb0@pci0:1:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb1@pci0:1:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet Стоит ли переходить на ipfw nat? Изменено 21 января, 2012 пользователем mlevel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 22 января, 2012 · Жалоба Стоит ли переходить на ipfw nat? Я удивился вашим показателям. Явно не стоит. MPD5 используете? я так понял шейпер dummynet. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 22 января, 2012 (изменено) · Жалоба А чему удивляетесь-то? Я вот удивляюсь, почему у автора всего две очереди net.isr, и обе по 70 процентов процессора тратят. У меня PF с dummynet, и такого поведения на таких же обьёмах нет: # atop -1 2 ATOP - Stella 2012/01/22 17:35:38 ---1-- 2s elapsed PRC | sys 0.00s | user 0.01s | | #proc 35 | #trun 1 | #tslpi 34 | #tslpu 0 | #zombie 1 | clones 0/s | | #exit 0/s | CPU | sys 80% | user 0% | irq 140% | | idle 180% | wait 0% | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 20% | user 0% | irq 56% | | idle 24% | cpu000 w 0% | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 60% | user 0% | irq 1% | | idle 39% | cpu001 w 0% | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 0% | user 0% | irq 48% | | idle 52% | cpu002 w 0% | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 0% | user 0% | irq 35% | | idle 65% | cpu003 w 0% | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | CPL | avg1 0.35 | avg5 0.27 | | avg15 0.20 | | | csw 101605/s | intr 54408/s | | | numcpu 4 | MEM | tot 8.0G | free 2.9G | cache 0.2M | inact 3.4G | wired 1.4G | | activ 29.4M | | | | | SWP | tot 1.0G | free 1.0G | | | | | | | | vmcom 0.0M | vmlim 0.0M | NET | transport | tcpi 1/s | tcpo 1/s | udpi 0/s | udpo 182/s | tcpao 0/s | tcppo 0/s | tcprs 0/s | tcpie 1/s | tcpor 0/s | udpip 3/s | NET | network | ipi 155172/s | ipo 182/s | ipfrw 66e3/s | deliv 3/s | | | | | icmpi 1/s | icmpo 0/s | NET | igb0 57% | pcki 86042/s | pcko 68151/s | si 575 Mbps | so 349 Mbps | coll 0/s | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | igb1 56% | pcki 68613/s | pcko 71566/s | si 352 Mbps | so 565 Mbps | coll 0/s | mlti 354/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | vlan305 55% | pcki 68879/s | pcko 71467/s | si 353 Mbps | so 551 Mbps | coll 0/s | mlti 354/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | vlan400 0% | pcki 0/s | pcko 182/s | si 0 Kbps | so 2181 Kbps | coll 0/s | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | PID RUID EUID THR SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPUNR CPU CMD 1/1 65912 root root 1 0.00s 0.00s 0K 0K 0K 0K -- - S 2 0% atop 83551 dyr dyr 1 0.00s 0.00s 0K 32K 0K 0K -- - R 2 0% atop 896 root quagga 1 0.00s 0.00s 0K 0K 0K 0K -- - S 0 0% ospfd 865 _pflogd _pflogd 1 0.00s 0.00s 0K 0K 0K 0K -- - S 0 0% pflogd [dyr@Stella ~]$ netstat -hW -w 1 input (Total) output packets errs idrops bytes packets errs bytes colls 214K 0 0 149M 203K 0 173M 0 211K 0 0 146M 200K 0 170M 0 218K 0 0 154M 207K 0 176M 0 ^C [dyr@Stella ~]$ Изменено 22 января, 2012 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 22 января, 2012 · Жалоба а скажите пожалуйста, кто-нибудь больше 600к сессий на pf делал? а то в свое время так и не смог победить рубеж в 550к-600к сессий, начиналась деградация. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 22 января, 2012 (изменено) · Жалоба Стоит ли переходить на ipfw nat? Я удивился вашим показателям. Явно не стоит. MPD5 используете? я так понял шейпер dummynet. Нет, у меня IPoE. А чему удивляетесь-то? Я вот удивляюсь, почему у автора всего две очереди net.isr, и обе по 70 процентов процессора тратят. [#gw:/]# sysctl -a net.isr net.isr.numthreads: 5 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 5 net.isr.direct: 0 net.isr.direct_force: 1 Dyr, покажите пожалуйста секцию опций set из Вашего pf.conf? P.S. Включение net.isr.direct=1 приводит к idle CPU0 <= 20%, при net.isr.direct=0, idle CPU0 >= 80%. Изменено 22 января, 2012 пользователем mlevel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 23 января, 2012 · Жалоба # sysctl -a net.isr net.isr.numthreads: 4 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 4 net.isr.direct: 0 net.isr.direct_force: 0 # cat /etc/pf.conf |grep -v ^# | grep -v ^$ ext_if="igb0" int_if="vlan3050" dst_nat1="93.92.199.224/28" dst_nat2="93.92.199.252/29" table <allow-nat> persist file "/etc/pf.allow-nat" table <our-nets> const { 80.249.176.0/20, 93.92.192.0/21, 109.71.176.0/21, 217.119.16.0/20 } table <allowed-spammers> { 10.54.249.24 } table <always_allowed_dst> { www.moby-money.ru } set limit { states 600000, frags 100000, src-nodes 60000 } set state-policy if-bound set optimization aggressive set ruleset-optimization profile set timeout { frag 10, tcp.established 3600, src.track 30 } set block-policy drop set fingerprints "/etc/pf.os" set skip on lo0 set skip on sk0 scrub in all max-mss 1440 binat-anchor "binat" load anchor "binat" from "/etc/pf.anchor.binat" nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" rdr pass on $int_if proto tcp from <allow-nat> to any port 21 -> 127.0.0.1 port 8021 nat on $ext_if from <allow-nat> to any -> $dst_nat1 static-port sticky-address round-robin nat on $ext_if from any to <always_allowed_dst> -> $dst_nat1 static-port sticky-address round-robin binat on $ext_if from 10.78.78.2 to any -> 93.92.199.252 nat on $ext_if from 10.78.78.0/24 to any -> $dst_nat2 static-port source-hash pass quick on $ext_if proto gre all no state pass in all pass out all anchor "ftp-proxy/*" pass out proto tcp from any to any port 21 table <spamers> persist pass in quick on $int_if proto tcp from <allowed-spammers> to any port smtp flags S/SAFR keep state pass in on $int_if proto tcp from any to any port smtp flags S/SAFR keep state \ (max-src-conn 15, max-src-conn-rate 15/30, overload <spamers> flush global) block return-icmp (host-prohib) log quick proto tcp from <spamers> to any port smtp table <icmp_flooders> persist pass in inet proto icmp all icmp-type {echoreq, unreach} keep state \ (max-src-conn 15, max-src-states 15, overload <icmp_flooders> flush global) block return-icmp (host-prohib) log quick proto icmp from <icmp_flooders> to any table <dns_flooders> persist pass in on $int_if inet proto udp from any to any port 53 keep state \ (max-src-conn 5, max-src-conn-rate 10/10, overload <dns_flooders> flush global) block return-icmp (host-prohib) log quick proto udp from <dns_flooders> to any port 53 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 23 января, 2012 · Жалоба Кстати, у меня не всё ладно с настройками, как оказалось: vmstat -z | grep -vw '0$' ITEM SIZE LIMIT USED FREE REQUESTS FAILURES 32 Bucket: 280, 0, 226, 12, 232, 1 64 Bucket: 536, 0, 262, 11, 274, 77 128 Bucket: 1048, 0, 6106, 1253, 17773569, 23485 tcptw: 72, 65550, 15, 5135, 4080740, 17289157 pfstatepl: 392, 600000, 349367, 250633, 13353219176, 314449 pffrent: 32, 100091, 208, 99883, 11529228564, 139756 NetGraph data items: 72, 522, 1, 521, 191805532449, 23582 Буду тюнить соотвествующие переменные, а то уже жаловаться начали на потери. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 23 января, 2012 (изменено) · Жалоба Подтюнил. echo "net.graph.maxdata=16384" >> /boot/loader.conf echo "net.inet.tcp.maxtcptw=65535" >> /etc/sysctl.conf В /etc/pf.conf: set limit { states 900000, frags 300000, src-nodes 60000, table-entries 400000} Результат: 600 Мбит/сек отшейпированного трафика практически не видны по загрузке. # top -aSCHIP last pid: 25069; load averages: 0.04, 0.26, 0.26 up 0+02:03:37 19:31:36 140 processes: 6 running, 93 sleeping, 41 waiting CPU 0: 0.0% user, 0.0% nice, 10.6% system, 40.9% interrupt, 48.5% idle CPU 1: 0.0% user, 0.0% nice, 12.1% system, 47.0% interrupt, 40.9% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 24.2% interrupt, 75.8% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 30.3% interrupt, 69.7% idle Mem: 25M Active, 16M Inact, 436M Wired, 204K Cache, 49M Buf, 7426M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 root 171 ki31 0K 64K CPU2 2 100:02 83.79% {idle: cpu2} 10 root 171 ki31 0K 64K CPU3 3 98:57 82.28% {idle: cpu3} 10 root 171 ki31 0K 64K RUN 0 73:48 70.65% {idle: cpu0} 10 root 171 ki31 0K 64K RUN 1 71:49 59.38% {idle: cpu1} 11 root -68 - 0K 656K WAIT 1 12:44 16.16% {irq257: igb0:que} 11 root -68 - 0K 656K WAIT 3 13:43 16.06% {irq259: igb0:que} 11 root -68 - 0K 656K WAIT 0 13:00 15.48% {irq256: igb0:que} 11 root -68 - 0K 656K WAIT 1 10:46 15.28% {irq261: igb1:que} 11 root -68 - 0K 656K WAIT 2 12:46 14.79% {irq258: igb0:que} 11 root -68 - 0K 656K WAIT 0 10:46 14.06% {irq264: igb1:que} 11 root -68 - 0K 656K WAIT 3 10:38 7.28% {irq263: igb1:que} 11 root -68 - 0K 656K WAIT 2 10:29 6.40% {irq262: igb1:que} 0 root -68 0 0K 400K - 0 9:30 3.56% {igb1 que} 0 root -68 0 0K 400K - 1 10:02 3.27% {igb1 que} 0 root -68 0 0K 400K - 1 9:25 2.29% {igb1 que} 0 root -68 0 0K 400K - 0 8:45 0.59% {igb1 que} 11 root -32 - 0K 656K WAIT 1 1:06 0.49% {swi4: clock} 0 root -68 0 0K 400K - 0 0:29 0.49% {igb0 que} 0 root -68 0 0K 400K CPU0 0 12:19 0.39% {dummynet} 0 root -68 0 0K 400K - 0 0:28 0.29% {igb0 que} # atop -1 2 PRC | sys 0.00s | user 0.04s | | #proc 36 | #trun 1 | #tslpi 36 | | #tslpu 0 | #zombie 0 | clones 0/s | | #exit 0/s | CPU | sys 35% | user 1% | irq 121% | | idle 244% | wait 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 19% | user 0% | irq 30% | | idle 50% | cpu001 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 16% | user 0% | irq 30% | | idle 54% | cpu000 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 0% | user 0% | irq 33% | | idle 67% | cpu003 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 0% | user 0% | irq 27% | | idle 73% | cpu002 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | CPL | avg1 0.02 | | avg5 0.12 | avg15 0.20 | | | csw 115498/s | | intr 58183/s | | | numcpu 4 | MEM | tot 8.0G | free 7.2G | cache 0.2M | | inact 15.8M | wired 442.6M | activ 24.2M | | | | | | SWP | tot 1.0G | free 1.0G | | | | | | | | | vmcom 0.0M | vmlim 0.0M | NET | transport | tcpi 1/s | tcpo 1/s | udpi 0/s | udpo 209/s | tcpao 0/s | tcppo 0/s | tcprs 0/s | tcpie 1/s | tcpor 0/s | udpnp 0/s | udpip 0/s | NET | network | ipi 128504/s | ipo 212/s | | ipfrw 57e3/s | deliv 2/s | | | | | icmpi 2/s | icmpo 2/s | NET | igb0 51% | pcki 71069/s | pcko 56863/s | si 517 Mbps | so 269 Mbps | coll 0/s | | mlti 2/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | igb1 51% | pcki 57018/s | pcko 62871/s | si 271 Mbps | so 513 Mbps | coll 0/s | | mlti 247/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | vlan305 50% | pcki 57222/s | pcko 62722/s | si 271 Mbps | so 501 Mbps | coll 0/s | | mlti 247/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | vlan400 0% | pcki 0/s | pcko 209/s | si 0 Kbps | so 2501 Kbps | coll 0/s | | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | pflog0 ---- | pcki 0/s | pcko 2/s | si 0 Kbps | so 0 Kbps | coll 0/s | | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | #vmstat -z | grep -vw '0 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES 32 Bucket: 280, 0, 172, 10, 172, 2 64 Bucket: 536, 0, 177, 5, 177, 1 128 Bucket: 1048, 0, 1653, 0, 1653, 270 Без шейпирования гигабит пропускает опять же без замечаний: last pid: 25183; load averages: 0.30, 0.20, 0.22 up 0+02:08:53 19:36:52 140 processes: 5 running, 94 sleeping, 41 waiting CPU 0: 0.0% user, 0.0% nice, 22.2% system, 16.7% interrupt, 61.1% idle CPU 1: 0.0% user, 0.0% nice, 14.1% system, 16.9% interrupt, 69.0% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 19.7% interrupt, 80.3% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 25.4% interrupt, 74.6% idle Mem: 25M Active, 16M Inact, 440M Wired, 204K Cache, 49M Buf, 7421M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 root 171 ki31 0K 64K CPU3 3 102:45 76.66% {idle: cpu3} 10 root 171 ki31 0K 64K CPU2 2 103:56 74.85% {idle: cpu2} 10 root 171 ki31 0K 64K CPU0 0 75:43 66.36% {idle: cpu0} 10 root 171 ki31 0K 64K RUN 1 73:53 66.16% {idle: cpu1} 11 root -68 - 0K 656K WAIT 3 14:34 16.16% {irq259: igb0:que} 11 root -68 - 0K 656K WAIT 2 13:33 14.70% {irq258: igb0:que} 11 root -68 - 0K 656K WAIT 0 13:46 13.87% {irq256: igb0:que} 11 root -68 - 0K 656K WAIT 1 13:31 13.28% {irq257: igb0:que} 11 root -68 - 0K 656K WAIT 0 11:21 10.69% {irq264: igb1:que} 11 root -68 - 0K 656K WAIT 3 11:15 10.35% {irq263: igb1:que} 11 root -68 - 0K 656K WAIT 1 11:23 9.96% {irq261: igb1:que} 11 root -68 - 0K 656K WAIT 2 11:04 8.79% {irq262: igb1:que} 0 root -68 0 0K 400K - 0 10:48 5.96% {igb1 que} 0 root -68 0 0K 400K - 0 10:12 5.37% {igb1 que} 0 root -68 0 0K 400K - 1 9:23 4.69% {igb1 que} 0 root -68 0 0K 400K - 0 10:00 4.49% {igb1 que} 7 root 44 - 0K 16K pftm 0 1:18 0.49% [pfpurge] 11 root -32 - 0K 656K WAIT 0 1:09 0.49% {swi4: clock} 0 root -68 0 0K 400K - 0 0:33 0.10% {igb0 que} 0 root -68 0 0K 400K - 0 0:32 0.10% {igb0 que} ATOP - Stella 2012/01/23 19:37:32 ---1-- 2s elapsed PRC | sys 0.00s | user 0.00s | | #proc 36 | #trun 1 | #tslpi 36 | | #tslpu 0 | #zombie 0 | clones 0/s | | #exit 0/s | CPU | sys 56% | user 0% | irq 89% | | idle 255% | wait 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 29% | user 0% | irq 22% | | idle 50% | cpu000 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 27% | user 0% | irq 21% | | idle 51% | cpu001 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 0% | user 0% | irq 23% | | idle 77% | cpu003 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | cpu | sys 0% | user 0% | irq 23% | | idle 77% | cpu002 w 0% | | | steal 0% | guest 0% | curf 3.39GHz | curscal 100% | CPL | avg1 0.49 | | avg5 0.26 | avg15 0.24 | | | csw 112218/s | | intr 51034/s | | | numcpu 4 | MEM | tot 8.0G | free 7.2G | cache 0.2M | | inact 15.8M | wired 443.8M | activ 24.2M | | | | | | SWP | tot 1.0G | free 1.0G | | | | | | | | | vmcom 0.0M | vmlim 0.0M | NET | transport | tcpi 1/s | tcpo 1/s | udpi 1235/s | udpo 199/s | tcpao 0/s | tcppo 0/s | tcprs 0/s | tcpie 1/s | tcpor 0/s | udpnp 0/s | udpip 1/s | NET | network | ipi 184060/s | ipo 203/s | | ipfrw 18e4/s | deliv 1237/s | | | | | icmpi 1/s | icmpo 3/s | NET | igb1 98% | pcki 73981/s | pcko 102e3/s | si 287 Mbps | so 980 Mbps | coll 0/s | | mlti 1237/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | igb0 96% | pcki 109e3/s | pcko 72879/s | si 963 Mbps | so 276 Mbps | coll 0/s | | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | vlan305 95% | pcki 74241/s | pcko 102e3/s | si 288 Mbps | so 959 Mbps | coll 0/s | | mlti 1237/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | vlan400 0% | pcki 0/s | pcko 199/s | si 0 Kbps | so 2397 Kbps | coll 0/s | | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | pflog0 ---- | pcki 0/s | pcko 4/s | si 0 Kbps | so 1 Kbps | coll 0/s | | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | Чуть не забыл - без "ifconfig igb? -rxcsum -txcsum -tso -lro" загрузка процессора была раза в два больше, так что не пренебрегайте. Изменено 23 января, 2012 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 23 января, 2012 · Жалоба echo "net.inet.tcp.maxtcptw=65535" >> /etc/sysctl.conf Это касается TCP, а при роутинге/НАТе до его разбора не доходит. Чуть не забыл - без "ifconfig igb? -rxcsum -txcsum -tso -lro" загрузка процессора была раза в два больше, так что не пренебрегайте Как минимум rxcsum стоило оставить, потому что контрольные суммы при получении проверяются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 24 января, 2012 · Жалоба Dyr (Вчера, 18:42) писал:echo "net.inet.tcp.maxtcptw=65535" >> /etc/sysctl.conf Это касается TCP, а при роутинге/НАТе до его разбора не доходит. Я его увеличивал, исходя из диагностики по vmstat -z, которая показывала большое количество failures для tcptw. Как минимум rxcsum стоило оставить, потому что контрольные суммы при получении проверяются. У меня подозрение, что проверка CRC самой сетевой картой становится узким местом на больших обьёмах трафика. В пользу этой теории говорит и практика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 26 января, 2012 · Жалоба Dyr, я вижу у Вас ядра более менее равномерно загружены, а у меня CPU1 вечно при пике нагрузки упираеться в idle 10%. Куда копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 27 января, 2012 · Жалоба Посмотрите, что у вас висит на этом ядре ("procstat -at", "top -aSCHIP") и перевестьте, соотвественно, на другие ядра. Мне пришлось подвесить dummynet на CPU0 (на CPU1 он занимал 100%, известный баг) и перенести несколько IRQ от сетевой карты (которые ранее были скриптом раскиданы равномерно по всем ядрам). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Silius Опубликовано 20 марта, 2012 · Жалоба а скажите пожалуйста, кто-нибудь больше 600к сессий на pf делал? а то в свое время так и не смог победить рубеж в 550к-600к сессий, начиналась деградация. Всем доброго времени суток! Тоже заметил такую ситуацию что pf не выходит за пределы 600000 состояний. Кто-нибудь тюнил это? :) Делаешь set limit states 1000000 всеравно не больше 600000. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Silius Опубликовано 20 марта, 2012 · Жалоба В man pf.conf в разделе про лимиты: set limit Sets hard limits on the memory pools used by the packet filter. See zone(9) for an explanation of memory pools. For example, set limit states 20000 Кажется понятно что количество состояний в таблице зависит от memory pool, только вот сколько не гуглю не могу найти как изменить этот размер памяти для pf. Неужели придется править исходники и пересобирать :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 марта, 2012 · Жалоба Он использует UMA алокатор, его статистика доступна так: vmstat -z | grep pf ставите и смотрите сколько лимит для зоны в системе. В системе может не хватать памяти для достижения лимита, особенно в х32. Лимит элементов задаётся через: uma_zone_set_max (в коде) /usr/src/sys/contrib/pf/net/pf_ioctl.c: case DIOCSETLIMIT: { struct pfioc_limit *pl = (struct pfioc_limit *)addr; int old_limit; if (pl->index < 0 || pl->index >= PF_LIMIT_MAX || V_pf_pool_limits[pl->index].pp == NULL) { error = EINVAL; goto fail; } uma_zone_set_max(V_pf_pool_limits[pl->index].pp, pl->limit); old_limit = V_pf_pool_limits[pl->index].limit; V_pf_pool_limits[pl->index].limit = pl->limit; pl->limit = old_limit; break; } (код почищен от ифдеф для опенбсд) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Silius Опубликовано 20 марта, 2012 (изменено) · Жалоба Он использует UMA алокатор, его статистика доступна так: vmstat -z | grep pf ставите и смотрите сколько лимит для зоны в системе. В системе может не хватать памяти для достижения лимита, особенно в х32. Лимит элементов задаётся через: uma_zone_set_max (в коде) /usr/src/sys/contrib/pf/net/pf_ioctl.c: case DIOCSETLIMIT: { struct pfioc_limit *pl = (struct pfioc_limit *)addr; int old_limit; if (pl->index < 0 || pl->index >= PF_LIMIT_MAX || V_pf_pool_limits[pl->index].pp == NULL) { error = EINVAL; goto fail; } uma_zone_set_max(V_pf_pool_limits[pl->index].pp, pl->limit); old_limit = V_pf_pool_limits[pl->index].limit; V_pf_pool_limits[pl->index].limit = pl->limit; pl->limit = old_limit; break; } (код почищен от ифдеф для опенбсд) У меня вот так: pfsrctrpl: 124, 60016, 0, 0, 0, 0 pfrulepl: 828, 0, 37, 155, 353, 0 pfstatepl: 284, 900004, 225464, 395576, 2509145129, 0 pfaltqpl: 224, 0, 0, 0, 0, 0 pfpooladdrpl: 68, 0, 29, 251, 294, 0 pfrktable: 1240, 1002, 0, 0, 0, 0 pfrkentry: 156, 400000, 0, 0, 0, 0 pfrkentry2: 156, 0, 0, 0, 0, 0 pffrent: 16, 300034, 0, 1218, 363642658, 0 pffrag: 48, 0, 0, 1014, 179993779, 0 pffrcache: 48, 10062, 0, 0, 0, 0 pffrcent: 12, 50141, 0, 0, 0, 0 pfstatescrub: 28, 0, 0, 0, 0, 0 pfiaddrpl: 100, 0, 0, 0, 0, 0 pfospfen: 108, 0, 696, 204, 9744, 0 pfosfp: 28, 0, 407, 482, 5698, 0 Это не пиковая загрузка. Днем сегодня кол-во состояний было до упора, потом я перезапустил pf, теперь их кол-во плавно растет. До перезапуска было впечатление что pf не очищал состояния... P.S. система i386 7.3-STABLE-201008 FreeBSD 7.3-STABLE-201008 Изменено 20 марта, 2012 пользователем Silius Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dwemer Опубликовано 21 марта, 2012 · Жалоба может быть в таймаутах дело? adaptive.start When the number of state entries exceeds this value, adaptive scaling begins. All timeout values are scaled linearly with factor (adaptive.end - number of states) / (adaptive.end - adaptive.start). Adaptive timeouts are enabled by default, with an adaptive.start value equal to 60% of the state limit, and an adaptive.end value equal to 120% of the state limit. They can be disabled by setting both adaptive.start and adaptive.end to 0. было примерно то же, пока не сделал так: # pfctl -st | grep adaptive adaptive.start 0 states adaptive.end 0 states Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 марта, 2012 · Жалоба Или поставить агрессив, тогда стейтов станет меньше в принципе. На х32 памяти под ядерные нужды меньше отводится. Был какой то тюнинг на тему мах кернел мем, именно для х32, погуглите, может даже в тюнигах Сысова. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Silius Опубликовано 21 марта, 2012 · Жалоба Или поставить агрессив, тогда стейтов станет меньше в принципе. На х32 памяти под ядерные нужды меньше отводится. Был какой то тюнинг на тему мах кернел мем, именно для х32, погуглите, может даже в тюнигах Сысова. Добрый день! Причину в принципе нашел, aggressive уже давно стоит. В конфиге теперь так: set limit { states 1800000, frags 300000, src-nodes 60000, table-entries 400000} set optimization aggressive До этого стояло set limit 900000 и эти adaptive timeouts вычисляются автоматически: # pfctl -st | grep adaptive adaptive.start 1080000 states adaptive.end 2160000 states Поставил просто limit побольше до 1800000 теперь adaptive стал больше. В man pf.conf говориться что отключить эти adaptive timeouts можно выставив их в ноль: set timeout { adaptive.start 0, adaptive.end 0 } я это проверил, в итоге сессии достигают выставленного лимита и начинается деградация (разрывы соединения и т.д.). В общем пока точно не понял про механизм adaptive, надо еще почитать. Главное то что если ставить состояний больше то они всеравно не достигают этого лимита а максимум будет это adaptive.start. По памяти ядра делался тюнинг на увеличение, пока все стабильно на x32. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
