John_obn Опубликовано 31 января, 2013 · Жалоба Добрый день. FreeBSD 8.3-STABLE, CPU: Intel® Xeon® CPU E5-2650, 8 ядер, без HT. Карточка двухпортовая Intel X520-DA2, драйвер последний с Intel 2.4.10. Ядро с добавлением: IPFIREWALL, DUMMYNET, pf. Машина роутит, NATит (pf nat), шейпит + фильтрует(ipfw+dummynet). Машину собрали в надежде, что возьмет на себя роль хотя бы 2-3 машин на E3-1240 с 82576 igb карточками. Вчера перенесли на нее с одной машины нагрузку, вечером в ЧНН показала загрузку, приведенную ниже. По непонятной для меня причине dummynet отжирает много CPU в это время. Dummynet прибит к 0 ядру. Если к этому же ядру будет прибит еще и irq256, то загрузка от dummynet возрастает еще сильнее. Остальные irq от ix прибиты к ядрам 1-7. Если опустошить таблицы 1 и 2 (абоненты, которых надо шейпить), то dummynet перестает быть таким прожорливым, это понятно, и, естественно, возрастает загрузка от irq ix, т.к. увеличивается трафик. Если убрать все правила ipfw кроме пайпов и загоняющих в них пакеты правил, также загрузка от dummynet пропадает. Пробовал удалять правила по одному, не нашлось четкого правила, которое бы так заставляло грузить dummynet. Переключение переменных net.isr.direct и net.isr.direct_force в 0 только увеличивает общую загрузку. Долго не удалось изучать проблему, т.к. когда трафик постепенно упал до меньше 550-600 мегабит в одну сторону, dummynet стал кушать < 3% своего ядра. Подскажите, пожалуйста, куда можно копать, какой тюнинг подобной системы делали вы. Повторюсь, на E3-1240 с igb карточкой, такой же трафик с таким же набором правил ipfw и pf просто практически не замечал, по крайней мере dummynet был не больше 0.9% # ipfw show 00300 3011958 2026075151 pipe tablearg ip from table(1) to any in via vlan9 00400 3158250 3000176133 pipe tablearg ip from any to table(2) out via vlan9 11240 6402939 5107957893 skipto 13700 ip from any to any in 11270 3069083 2028971325 allow ip from table(50) to any out xmit ix0 11900 5330 1487218 allow ip from table(52) to any out 12000 0 0 allow ip from any to table(52) out 12100 293 15710 deny ip from any to table(53) out xmit vlan* 12300 394 20737 allow ip from me to any out 12400 320 14576 deny ip from any to not table(54) out xmit vlan* 12500 15242 1445088 allow icmp from any to any out 12600 0 0 allow ip from table(55) to table(50) out 12700 0 0 allow ip from table(50) to table(55) out 12800 43480 47573617 allow ip from table(50) to table(50) out 12900 1 40 deny ip from any to table(57) out xmit vlan* 13000 4686 5652885 allow ip from any to table(56) out xmit vlan* 13200 3165332 2879335727 allow ip from any to table(50) out 13300 0 0 deny ip from any to any out 13700 12 1104 allow tcp from table(50) to me dst-port 22 in recv ix0 13800 0 0 deny tcp from any to me dst-port 22 in recv ix0 13900 3379880 3109830959 allow ip from any to table(50) in recv ix0 14000 26 1648 allow ip from table(53) to table(52) in recv vlan* 14100 294 25463 deny ip from table(53) to any in recv vlan* 14205 1241748 1017781043 skipto 14300 udp from any to any in recv vlan* 14210 2028 237761 skipto 15000 icmp from any to any in recv vlan* 14220 25 1396 skipto 15500 tcp from any to any dst-port 25,587 in recv vlan* 14230 1785779 984864597 skipto 15990 ip from any to any in recv vlan* 14300 936 86154 deny udp from any to any dst-port 135-139,445 recv vlan* 14400 0 0 deny udp from any to any dst-port 1434 in recv vlan* 14500 0 0 deny udp from table(58) to any in recv vlan* 14600 8123 661036 allow udp from table(50) to table(50) in recv vlan* 14700 0 0 deny udp from table(59) to any in recv vlan* 14800 2 656 allow udp from any to any dst-port 67,68 in recv vlan* 14900 1232721 1017080173 allow udp from table(50) to any in recv vlan* 15000 0 0 deny icmp from any to any frag in recv vlan* 15100 0 0 deny icmp from table(60) to any in recv vlan* 15200 732 96951 allow icmp from table(50) to table(50) in recv vlan* 15300 1 121 deny icmp from table(61) to any in recv vlan* 15400 1295 140689 allow icmp from table(50) to any in recv vlan* 15500 0 0 allow tcp from table(62) to any dst-port 25,587 in recv vlan* 15600 0 0 deny tcp from table(64) to any dst-port 25,587 in recv vlan* 15700 0 0 allow tcp from table(50) to table(63) dst-port 25,587 in recv vlan* limit src-addr 25 15800 0 0 deny tcp from table(65) to any dst-port 25,587 in recv vlan* 15900 25 1396 allow tcp from table(50) to any dst-port 25,587 in recv vlan* limit src-addr 25 15990 12 608 deny tcp from any to any dst-port 135-139,445 recv vlan* 16000 1785595 984938846 allow ip from table(50) to any in recv vlan* 16100 217 10464 deny ip from any to any in recv vlan* 65535 182611608 147327665628 allow ip from any to any # pfctl -sn no nat on ix0 from any to <local_networks> no nat on ix0 from <nat_exclude> to any no nat on ix0 from <local_only> to any nat on ix0 from <unlim_ips> to any -> <nat_pool> round-robin sticky-address rdr pass on vlan0 inet proto tcp from <blocked_clients> to ! <servers> port = http -> 4.4.4.4 port 8000 last pid: 92015; load averages: 4.27, 3.40, 3.60 up 2+04:59:16 21:16:46 184 processes: 14 running, 111 sleeping, 59 waiting CPU 0: 0.0% user, 0.0% nice, 66.7% system, 26.7% interrupt, 6.7% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 33.3% interrupt, 66.7% idle CPU 2: 100% user, 0.0% nice, 0.0% system, 46.7% interrupt, 53.3% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 53.3% interrupt, 46.7% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 13.3% interrupt, 86.7% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 33.3% interrupt, 66.7% idle CPU 6: 6.3% user, 0.0% nice, 0.0% system, 18.8% interrupt, 75.0% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 26.7% interrupt, 73.3% idle Mem: 96M Active, 25G Inact, 3891M Wired, 1063M Cache, 3283M Buf, 572M Free Swap: 64G Total, 64G Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 171 ki31 0K 128K CPU1 1 50.8H 67.77% [idle{idle: cpu1}] 11 root 171 ki31 0K 128K CPU4 4 50.7H 67.77% [idle{idle: cpu4}] 11 root 171 ki31 0K 128K RUN 7 50.7H 66.99% [idle{idle: cpu7}] 11 root 171 ki31 0K 128K RUN 6 50.7H 66.26% [idle{idle: cpu6}] 11 root 171 ki31 0K 128K RUN 2 50.7H 65.97% [idle{idle: cpu2}] 11 root 171 ki31 0K 128K RUN 5 50.7H 61.96% [idle{idle: cpu5}] 11 root 171 ki31 0K 128K RUN 3 50.7H 56.98% [idle{idle: cpu3}] 0 root -68 0 0K 704K CPU0 0 282:10 38.38% [kernel{dummynet}] 11 root 171 ki31 0K 128K RUN 0 46.5H 29.98% [idle{idle: cpu0}] 12 root -68 - 0K 1008K RUN 0 46:52 27.88% [intr{irq265: ix1:que }] 12 root -68 - 0K 1008K WAIT 5 58:41 21.58% [intr{irq261: ix0:que }] 12 root -68 - 0K 1008K WAIT 3 58:00 20.75% [intr{irq256: ix0:que }] 12 root -68 - 0K 1008K WAIT 3 56:14 20.26% [intr{irq268: ix1:que }] 12 root -68 - 0K 1008K WAIT 3 61:26 18.07% [intr{irq259: ix0:que }] 12 root -68 - 0K 1008K WAIT 2 59:08 17.48% [intr{irq258: ix0:que }] 12 root -68 - 0K 1008K WAIT 4 53:31 17.29% [intr{irq269: ix1:que }] 12 root -68 - 0K 1008K WAIT 4 62:13 16.89% [intr{irq260: ix0:que }] 12 root -68 - 0K 1008K RUN 6 57:00 16.46% [intr{irq271: ix1:que }] 12 root -68 - 0K 1008K WAIT 7 58:33 15.77% [intr{irq263: ix0:que }] 12 root -68 - 0K 1008K WAIT 1 56:43 15.77% [intr{irq257: ix0:que }] 12 root -68 - 0K 1008K CPU6 6 59:27 14.89% [intr{irq262: ix0:que }] 12 root -68 - 0K 1008K CPU2 2 57:00 14.79% [intr{irq267: ix1:que }] 12 root -68 - 0K 1008K WAIT 7 56:17 14.16% [intr{irq272: ix1:que }] 12 root -68 - 0K 1008K WAIT 5 55:59 13.57% [intr{irq270: ix1:que }] 12 root -68 - 0K 1008K WAIT 1 51:08 12.35% [intr{irq266: ix1:que }] 68308 root 44 0 50064K 44324K bpf 2 2:28 0.88% /usr/local/bin/trafd -p -i vlan9 ether src 90:e2:ba:2c:a0:e9 0 root -68 0 0K 704K - 7 4:05 0.20% [kernel{ix0 que}] 0 root -68 0 0K 704K - 4 2:59 0.20% [kernel{ix0 que}] 0 root -68 0 0K 704K - 1 2:26 0.20% [kernel{ix1 que}] 0 root -68 0 0K 704K - 4 2:39 0.10% [kernel{ix0 que}] 0 root -68 0 0K 704K - 7 2:37 0.10% [kernel{ix1 que}] 0 root -68 0 0K 704K - 1 2:34 0.10% [kernel{ix1 que}] 0 root -68 0 0K 704K - 6 2:29 0.10% [kernel{ix1 que}] 0 root -68 0 0K 704K - 2 2:22 0.10% [kernel{ix1 que}] 0 root -68 0 0K 704K - 2 2:09 0.10% [kernel{ix1 que}] input (ix1) output packets errs idrops bytes packets errs bytes colls 73k 0 0 48M 78k 0 75M 0 72k 0 0 45M 80k 0 80M 0 73k 0 0 47M 80k 0 78M 0 72k 0 0 45M 79k 0 77M 0 73k 0 0 46M 81k 0 79M 0 73k 0 0 46M 80k 0 77M 0 75k 0 0 48M 83k 0 81M 0 77k 0 0 49M 87k 0 87M 0 75k 0 0 48M 83k 0 82M 0 76k 0 0 47M 85k 0 85M 0 80k 0 0 46M 88k 0 89M 0 79k 0 0 45M 87k 0 89M 0 78k 0 0 45M 89k 0 91M 0 75k 0 0 45M 86k 0 87M 0 75k 0 0 44M 87k 0 89M 0 76k 0 0 48M 84k 0 83M 0 74k 0 0 46M 83k 0 83M 0 74k 0 0 47M 83k 0 83M 0 72k 0 0 44M 82k 0 81M 0 75k 0 0 45M 86k 0 87M 0 76k 0 0 47M 87k 0 88M 0 # cat /boot/loader.conf kern.ipc.maxsockbuf=16777216 # kernel socket buffer space kern.ipc.nmbclusters=262144 # kernel mbuf space raised 275MB of kernel dedicated ram kern.ipc.somaxconn=32768 # size of the listen queue for accepting new TCP connections kern.ipc.maxsockets=204800 # increase the limit of the open sockets hw.igb.lro=0 hw.ixgbe.lro=0 hw.ixgbe.rxd=4096 hw.ixgbe.txd=4096 hw.ixgbe.rx_process_limit=4096 hw.ixgbe.max_interrupt_rate=10240 hw.intr_storm_threshold=9000 net.isr.defaultqlimit=8192 net.isr.bindthreads=1 net.isr.maxthreads=8 # cat /etc/sysctl.conf hw.intr_storm_threshold=9000 kern.ipc.nmbclusters=262144 kern.ipc.nmbjumbop=262144 kern.ipc.somaxconn=32768 kern.ipc.maxsockets=204800 kern.maxfiles=256000 kern.maxfilesperproc=230400 dev.ix.0.rx_processing_limit=4096 dev.ix.1.rx_processing_limit=4096 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fw.dyn_buckets=2048 net.inet.ip.dummynet.hash_size=16384 net.inet.icmp.drop_redirect=1 net.inet.ip.redirect=0 net.inet.ip.dummynet.pipe_slot_limit=2048 kern.ipc.maxsockbuf=83886080 net.inet.ip.intr_queue_maxlen=5120 net.inet.tcp.blackhole=2 # drop any TCP packets to closed ports net.inet.tcp.delayed_ack=0 # no need to delay ACK's net.inet.tcp.drop_synfin=1 # drop TCP packets which have SYN and FIN set net.inet.tcp.nolocaltimewait=1 # do not create TIME_WAIT state for localhost net.inet.udp.blackhole=1 # drop any UDP packets to closed ports Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 31 января, 2013 · Жалоба Сравните кеши на процах, если все остальные настройки ос и сами ос одинаковые то может просто упираться в кеш проца или в шину между кешами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 31 января, 2013 (изменено) · Жалоба FreeBSD 8.3-STABLE, CPU: Intel® Xeon® CPU E5-2650, 8 ядер, без HT. Машину собрали в надежде, что возьмет на себя роль хотя бы 2-3 машин на E3-1240 с 82576 igb карточками. Повторюсь, на E3-1240 с igb карточкой, такой же трафик с таким же набором правил ipfw и pf просто практически не замечал, по крайней мере dummynet был не больше 0.9% Сорри, что немного вклиниваюсь с комментарием относительно железа, но E3-1240 с включенным HT не уступает, а даже выигрывает и немало у одиночного E5-2650 с выключенным HT. Если брать E5, то только совсем топовые и пару штук, чтобы гарантированно переплюнуть E3-12хх. Я понимаю что BogoMIPS вообще ни разу не показатель, но... Total of 8 processors activated (54393.23 BogoMIPS) - E3-1240v2 (с HT) Total of 8 processors activated (40531.26 BogoMIPS) - E5-2665 (без HT) Как бы принято считать что E5 хорошо только с HT и в системах с двумя физическими процессорами. В остальных случаях не шибко он и лучше. Кеша и шины даже у E3 вполне достаточно, чтобы не беспокоиться что он упрется в полку по этим показателям. X5680 (хоть и старичок) или парочка E5-2620 были бы веселее и по крайней мере парочка была бы еще и дешевле на 30%. Изменено 31 января, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 1 февраля, 2013 · Жалоба В E3 L3 кэш 8 MB shared на все ядра. В E5 - 20 MB. Собственно на этот параметр обращал внимание при выборе процессора. Единственное, полистав даташит на E5 обнаружил следующее: Up to 20 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores В E3 про L3 просто написано: Up to 8 MB shared instruction/data third-level cache (L3), shared among all cores, делим на количество ядер, получаем 2MB, но не написано, что жестко до 2MB на ядро.О шине не нашел ничего или неправильно искал. По поводу HyperThreading - оно для фряхи уже не вредно? Стоит включить? Топовый E5 решил не брать, т.к. у него цена уже запредельная, а отличие только в частоте (2.9 ГГц против 2.0 ГГц). Частота шины одинаковая 8000 МГц. Кстати, стоит ли включать TurboBoost на сервере с такими задачами, стабильно будет работать? Второй процессор нет возможности поставить, т.к. платформа только для 1 CPU. Интересно конечно провести эксперимент, в машину с E3-1270 или E3-1240 вместо igb воткнуть эту ix карточку, посмотреть, что покажет. Возможно на следующей неделе проведу этот эксперимент, надо будет купить еще одну Intel X520-DA2 и Direct Attach кабели. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 1 февраля, 2013 · Жалоба Есть нюансы. Если все 8 процов работают с одними данными - изменяют их, то содержимое кешей объявляется не действительным и они заново синхронизируются, с простоем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 1 февраля, 2013 · Жалоба Это справедливо и для 4-х ядерного процессора. Вы к тому, что 4 ядра быстрее синхронизируются и 8 ядер зло в данном случае? Чем же тогда лучше вариант с 2 физическими процессорами? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 1 февраля, 2013 · Жалоба Там могут различаться механизмы синхронизации и локов кешей. За деталями - к интелу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 1 февраля, 2013 · Жалоба Да уж, весело. В общем, буду пробовать менять дрова на те, которые шли с фрей STABLE, далее придется пробовать менять в роутере с E3-1240(70) менять 82576 карточку на 82599. Отпишитесь, пожалуйста, те, кто имеет подобную конфигурацию железа и задач, что у вас есть, какие объемы трафика, kpps, какие средства используются (ipfw, pf), какие параметры sysctl , loader.conf используете. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 1 февраля, 2013 (изменено) · Жалоба Да уж, весело. В общем, буду пробовать менять дрова на те, которые шли с фрей STABLE, далее придется пробовать менять в роутере с E3-1240(70) менять 82576 карточку на 82599. Отпишитесь, пожалуйста, те, кто имеет подобную конфигурацию железа и задач, что у вас есть, какие объемы трафика, kpps, какие средства используются (ipfw, pf), какие параметры sysctl , loader.conf используете. В Linux E5 меня разочаровал и ценой и производительностью, показав полную неконкурентоспособность в борьбе с E3 в задачах обработки трафика (нат, шейпинг, форвардинг и т.п.). А кеша и шины честно говоря 5ГT и 8 Мб хватает за глаза. Многоядерность многоядерностью, но тактовую частоту пока еще никто не отменял и она в 1.7 раз отличается в пользу E3, что совсем не здорово для E5, который в этом отношении бледно выглядит. E5 был сослан работать на хостинговые сервисы в наказание. Там он более чем справляется с работой. Тут где-то упоминали что HT допилили во Фре и теперь вроде как без проблем. Попробуйте включить. Turbo Boost тоже делу не помешает. Изменено 1 февраля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 1 февраля, 2013 (изменено) · Жалоба У нас система из 2 серверов (мост-шейпер + нат) гоняет In: 3,2Гбит/с + Out: 850Мбит/с, мост на core i7-3770, нат на 2 x L5520 Но, нат тоже будем переводить на i7-3770K, по запасу производительности надеемся до 5Гб/с, если что-то вдруг не поднимет нагрузку экспоненциально. В табл. шейпера порядка 7,5К IP адресов. OS: FB 9.1 Суммарно через мост input (Total) output packets errs idrops bytes packets errs bytes colls drops 1.1M 0 0 890M 1.0M 0 890M 0 0 В топе на мосте еще суммарно 40.4% idle Изменено 1 февраля, 2013 пользователем Azamat Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 2 февраля, 2013 · Жалоба Azamat, мост-шейпер и нат какими средствами сделаны? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 2 февраля, 2013 · Жалоба все по местным рекомендациям. OS: FB 9.1 ipfw nat в 120 instances, dummynet по таблицам Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 11 февраля, 2013 · Жалоба Небольшой апдейт: в первом посте писал, что irq256 отвязал от 0 ядра. Но тогда я совсем забыл про irq265 от ix1, который был тоже прибит к 0 ядру. Отвязал его от 0 ядра и все стало гораздо лучше, dummynet занимает не больше 8% cpu. А после того как привязал irq256 и irq265 к другим ядрам, то dummynet стал грузить не больше 4%. Хочу задать количество queue для ixgbe = 7, чтобы каждая очередь была в своем ядре. В коде ixgbe.c посмотрел, привязки к четности этого числа не нашел. Ну и плюс попробую включить Hyper Threading. Но сначала в среду поставлю X520-DA2 в машину с E3-1240 вместо igb 82576, посмотрю, какая там будет нагрузка при такой же работе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 17 февраля, 2013 · Жалоба Продолжаю, если кому интересно. Сделал, как и планировал. Только процессор там E3-1270. Результат уже гораздо лучше: # top -aSCHPI last pid: 12273; load averages: 3.95, 4.05, 3.83 up 4+13:45:07 22:59:11 151 processes: 13 running, 95 sleeping, 43 waiting CPU 0: 0.0% user, 0.0% nice, 50.9% system, 0.0% interrupt, 49.1% idle CPU 1: 0.0% user, 0.0% nice, 1.1% system, 35.0% interrupt, 63.9% idle CPU 2: 0.0% user, 0.0% nice, 0.8% system, 44.0% interrupt, 55.3% idle CPU 3: 0.0% user, 0.0% nice, 0.4% system, 42.7% interrupt, 56.9% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 41.7% interrupt, 58.3% idle CPU 5: 0.0% user, 0.0% nice, 0.8% system, 44.7% interrupt, 54.5% idle CPU 6: 0.0% user, 0.0% nice, 1.5% system, 37.6% interrupt, 60.9% idle CPU 7: 0.4% user, 0.0% nice, 0.7% system, 34.5% interrupt, 64.4% idle Mem: 117M Active, 998M Inact, 763M Wired, 124K Cache, 417M Buf, 2063M Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 171 ki31 0K 128K RUN 0 73.7H 100.00% [idle{idle: cpu0}] 11 root 171 ki31 0K 128K CPU7 7 87.8H 70.07% [idle{idle: cpu7}] 11 root 171 ki31 0K 128K CPU6 6 87.5H 69.48% [idle{idle: cpu6}] 11 root 171 ki31 0K 128K CPU4 4 87.5H 66.89% [idle{idle: cpu4}] 11 root 171 ki31 0K 128K RUN 1 86.5H 66.55% [idle{idle: cpu1}] 11 root 171 ki31 0K 128K CPU3 3 86.7H 63.48% [idle{idle: cpu3}] 11 root 171 ki31 0K 128K RUN 2 85.9H 61.08% [idle{idle: cpu2}] 11 root 171 ki31 0K 128K RUN 5 87.7H 50.10% [idle{idle: cpu5}] 12 root -68 - 0K 736K WAIT 5 613:28 28.56% [intr{irq260: ix0:que }] 12 root -68 - 0K 736K WAIT 5 615:28 25.49% [intr{irq268: ix1:que }] 12 root -68 - 0K 736K WAIT 3 668:12 25.00% [intr{irq258: ix0:que }] 12 root -68 - 0K 736K CPU2 2 638:49 22.36% [intr{irq257: ix0:que }] 12 root -68 - 0K 736K WAIT 4 617:12 21.78% [intr{irq259: ix0:que }] 12 root -68 - 0K 736K RUN 2 709:36 21.48% [intr{irq265: ix1:que }] 12 root -68 - 0K 736K WAIT 1 650:14 20.56% [intr{irq256: ix0:que }] 12 root -68 - 0K 736K WAIT 7 606:05 19.38% [intr{irq262: ix0:que }] 12 root -68 - 0K 736K WAIT 1 660:39 19.09% [intr{irq264: ix1:que }] 12 root -68 - 0K 736K WAIT 6 610:30 18.16% [intr{irq261: ix0:que }] 12 root -68 - 0K 736K WAIT 6 632:25 17.38% [intr{irq269: ix1:que }] 12 root -68 - 0K 736K WAIT 3 626:39 16.89% [intr{irq266: ix1:que }] 12 root -68 - 0K 736K CPU4 4 628:53 16.26% [intr{irq267: ix1:que }] 12 root -68 - 0K 736K WAIT 7 631:31 15.28% [intr{irq270: ix1:que }] 0 root -68 0 0K 480K CPU0 0 35.2H 2.69% [kernel{dummynet}] 6499 root 44 0 50060K 44656K bpf 2 35:08 0.49% /usr/local/bin/trafd -p -i vlan0 ether src 9 0 root -68 0 0K 480K - 6 20:03 0.10% [kernel{ix0 que}] 0 root -68 0 0K 480K - 2 19:22 0.10% [kernel{ix0 que}] 0 root -68 0 0K 480K - 7 19:10 0.10% [kernel{ix0 que}] 0 root -68 0 0K 480K - 2 18:55 0.10% [kernel{ix0 que}] # ifstat -i ix0 -i ix1 -b ix0 ix1 Kbps in Kbps out Kbps in Kbps out 1.01e+06 509342.0 515080.1 989864.3 984354.6 509109.4 513132.6 963676.0 977127.8 534342.8 540353.8 956811.0 935279.3 520136.7 525001.2 919957.7 Параметры тюнинга немного изменил в плане количества очередей сетевых карт, 7 очередей на карту, чтобы 0-е ядро не занимали. Ну и пришлось перепривязать прерывания ix карточек: # cat /boot/loader.conf kern.ipc.nmbclusters=262144 kern.ipc.nmbjumbop=262144 kern.ipc.somaxconn=32768 kern.ipc.maxsockets=204800 kern.maxfiles=256000 kern.maxfilesperproc=230400 hw.igb.lro=0 hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.max_interrupt_rate=32000 hw.igb.rx_process_limit=4096 hw.igb.num_queues=3 net.isr.defaultqlimit=8192 net.isr.bindthreads=1 net.isr.maxthreads=4 hw.ixgbe.lro=0 hw.ixgbe.rxd=4096 hw.ixgbe.txd=4096 hw.ixgbe.rx_process_limit=4096 hw.ixgbe.num_queues=7 hw.intr_storm_threshold=9000 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zlolotus Опубликовано 18 февраля, 2013 · Жалоба все по местным рекомендациям. OS: FB 9.1 ipfw nat в 120 instances, dummynet по таблицам Азамат подскажите какую серверную платформу используете, какой проц. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dadv Опубликовано 20 февраля, 2013 (изменено) · Жалоба Начнём с того, что показаниям top в отношениии dummynet верить нельзя. Вообще от слова совсем. Он почему-то показывает погоду на Марсе, а не потребление процессора dummynet'ом. Корректный способ мониторить потребление процессора ядерным тредом dummynet это смотреть на его монотонно возрастающий ядерный счетчик accumulated CPU time. Следующая команда выдаёт его значение в сотых долях секунды. Его можно рисовать на графике хоть mrtg, хоть чем. export LC_ALL=C ps -Hxo time,lwp | awk -vT=$(procstat -t 0 | awk '/dummynet/ {print $2}')\ ' $2 == T { split($1, a, /[:.]/); print a[1]*6000+a[2]*100+a[3]; } Лично я отдаю это значение как есть по SNMP и рисую его тоже "как есть" на графике, при привязке к одному ядру CPU на графике получается процентная загрузка этого ядра тредом dummynet. Изменено 20 февраля, 2013 пользователем dadv Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 20 февраля, 2013 · Жалоба export LC_ALL=C ps -aHxo time,lwp | awk -vT=$(procstat -t 0 | awk '/dummynet/ {print $2}')\ ' $2 == T { split($1, a, /[:.]/); print a[1]*6000+a[2]*100+a[3]; }' так более корректно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dadv Опубликовано 20 февраля, 2013 · Жалоба так более корректно Если запускать команду от рута, то корректно ровно так же, зато более производительно :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 20 февраля, 2013 · Жалоба Не выходит каменный цветок. E5-2650 # netstat -I ix1 -w1 -h input (ix1) output packets errs idrops bytes packets errs bytes colls 93k 0 0 50M 106k 0 103M 0 94k 0 0 53M 103k 0 98M 0 94k 0 0 52M 103k 0 98M 0 93k 0 0 51M 104k 0 99M 0 last pid: 32391; load averages: 9.00, 10.45, 9.68 up 0+03:21:24 20:52:16 195 processes: 24 running, 108 sleeping, 63 waiting CPU 0: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle CPU 1: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle CPU 2: 0.0% user, 0.0% nice, 0.4% system, 45.1% interrupt, 54.5% idle CPU 3: 0.0% user, 0.0% nice, 1.5% system, 42.9% interrupt, 55.6% idle CPU 4: 0.0% user, 0.0% nice, 0.7% system, 42.3% interrupt, 56.9% idle CPU 5: 0.7% user, 0.0% nice, 0.0% system, 35.6% interrupt, 63.7% idle CPU 6: 0.0% user, 0.0% nice, 0.4% system, 31.1% interrupt, 68.5% idle CPU 7: 0.4% user, 0.0% nice, 1.5% system, 38.3% interrupt, 59.8% idle CPU 8: 0.0% user, 0.0% nice, 1.1% system, 37.1% interrupt, 61.8% idle CPU 9: 0.0% user, 0.0% nice, 0.7% system, 41.2% interrupt, 58.1% idle CPU 10: 0.0% user, 0.0% nice, 1.1% system, 42.9% interrupt, 56.0% idle CPU 11: 0.0% user, 0.0% nice, 1.1% system, 33.5% interrupt, 65.4% idle CPU 12: 0.0% user, 0.0% nice, 0.7% system, 31.1% interrupt, 68.2% idle CPU 13: 0.0% user, 0.0% nice, 0.7% system, 28.5% interrupt, 70.8% idle CPU 14: 0.0% user, 0.0% nice, 0.8% system, 41.4% interrupt, 57.9% idle CPU 15: 0.4% user, 0.0% nice, 1.1% system, 34.6% interrupt, 63.9% idle Mem: 162M Active, 17M Inact, 831M Wired, 112K Cache, 107M Buf, 30G Free Swap: 64G Total, 64G Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 0 root -68 0 0K 672K CPU0 0 173:42 100.00% [kernel{dummynet}] 11 root 171 ki31 0K 256K CPU1 1 196:11 91.16% [idle{idle: cpu1}] 11 root 171 ki31 0K 256K RUN 11 138:23 70.07% [idle{idle: cpu11}] 11 root 171 ki31 0K 256K CPU13 13 143:01 67.97% [idle{idle: cpu13}] 11 root 171 ki31 0K 256K CPU15 15 141:58 66.99% [idle{idle: cpu15}] 11 root 171 ki31 0K 256K RUN 12 141:23 66.55% [idle{idle: cpu12}] 11 root 171 ki31 0K 256K RUN 14 138:20 64.79% [idle{idle: cpu14}] 11 root 171 ki31 0K 256K CPU7 7 136:04 64.16% [idle{idle: cpu7}] 11 root 171 ki31 0K 256K RUN 9 136:08 62.99% [idle{idle: cpu9}] 11 root 171 ki31 0K 256K CPU6 6 132:59 62.26% [idle{idle: cpu6}] 11 root 171 ki31 0K 256K RUN 10 134:26 61.96% [idle{idle: cpu10}] 11 root 171 ki31 0K 256K CPU2 2 132:05 61.87% [idle{idle: cpu2}] 11 root 171 ki31 0K 256K CPU3 3 131:02 59.18% [idle{idle: cpu3}] 11 root 171 ki31 0K 256K RUN 8 133:24 58.69% [idle{idle: cpu8}] 11 root 171 ki31 0K 256K RUN 5 133:22 56.30% [idle{idle: cpu5}] 11 root 171 ki31 0K 256K CPU4 4 135:53 54.49% [idle{idle: cpu4}] 12 root -68 - 0K 1104K WAIT 3 66:35 47.07% [intr{irq257: ix0:que }] 12 root -68 - 0K 1104K CPU10 10 62:27 44.48% [intr{irq265: ix1:que }] 12 root -68 - 0K 1104K WAIT 6 64:08 44.38% [intr{irq260: ix0:que }] 12 root -68 - 0K 1104K WAIT 5 63:57 44.29% [intr{irq259: ix0:que }] 12 root -68 - 0K 1104K CPU8 8 63:46 42.87% [intr{irq262: ix0:que }] 12 root -68 - 0K 1104K WAIT 2 65:20 42.19% [intr{irq256: ix0:que }] 12 root -68 - 0K 1104K WAIT 7 61:21 40.19% [intr{irq261: ix0:que }] 12 root -68 - 0K 1104K WAIT 4 61:18 39.45% [intr{irq258: ix0:que }] 12 root -68 - 0K 1104K CPU9 9 60:41 39.16% [intr{irq264: ix1:que }] 12 root -68 - 0K 1104K WAIT 14 58:26 39.16% [intr{irq269: ix1:que }] 12 root -68 - 0K 1104K CPU15 15 54:08 37.50% [intr{irq270: ix1:que }] 12 root -68 - 0K 1104K CPU12 12 54:37 36.96% [intr{irq267: ix1:que }] 12 root -68 - 0K 1104K WAIT 13 53:05 35.60% [intr{irq268: ix1:que }] 12 root -68 - 0K 1104K WAIT 11 57:56 32.67% [intr{irq266: ix1:que }] До этого пробовал с 15 потоками для ixgbe сетевых. Сейчас с 7 очередями. Результат неизменный. Делал ipfw -f flush ; ipfw -f pipe flush - количество трафика увеличивается до 1.1 гигабита в сторону абонентов, и могло бы быть болше, только у некоторых ядер-тредов idle=0, либо близко к тому. Буду пробовать отключать гипертрединг. Рядом такая же машина с E3-1270: last pid: 31931; load averages: 4.18, 3.84, 3.82 up 7+11:43:31 20:57:35 153 processes: 11 running, 98 sleeping, 44 waiting CPU 0: 0.0% user, 0.0% nice, 46.2% system, 0.0% interrupt, 53.8% idle CPU 1: 0.4% user, 0.0% nice, 1.1% system, 35.7% interrupt, 62.8% idle CPU 2: 0.0% user, 0.0% nice, 0.7% system, 38.6% interrupt, 60.7% idle CPU 3: 0.0% user, 0.0% nice, 0.4% system, 41.0% interrupt, 58.6% idle CPU 4: 0.4% user, 0.0% nice, 1.1% system, 36.8% interrupt, 61.7% idle CPU 5: 0.0% user, 0.0% nice, 1.9% system, 47.9% interrupt, 50.2% idle CPU 6: 0.4% user, 0.0% nice, 0.8% system, 38.3% interrupt, 60.5% idle CPU 7: 0.8% user, 0.0% nice, 1.5% system, 36.5% interrupt, 61.3% idle Mem: 128M Active, 2762M Inact, 837M Wired, 123M Cache, 417M Buf, 91M Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 171 ki31 0K 128K CPU0 0 120.3H 98.68% [idle{idle: cpu0}] 11 root 171 ki31 0K 128K CPU7 7 140.1H 66.70% [idle{idle: cpu7}] 11 root 171 ki31 0K 128K RUN 2 137.5H 65.87% [idle{idle: cpu2}] 11 root 171 ki31 0K 128K CPU4 4 139.3H 64.26% [idle{idle: cpu4}] 11 root 171 ki31 0K 128K CPU6 6 139.9H 62.06% [idle{idle: cpu6}] 11 root 171 ki31 0K 128K RUN 3 138.6H 58.50% [idle{idle: cpu3}] 11 root 171 ki31 0K 128K CPU1 1 137.6H 55.57% [idle{idle: cpu1}] 11 root 171 ki31 0K 128K CPU5 5 140.0H 48.29% [idle{idle: cpu5}] 12 root -68 - 0K 736K WAIT 5 18.2H 27.98% [intr{irq268: ix1:que }] 12 root -68 - 0K 736K WAIT 1 20.0H 24.76% [intr{irq256: ix0:que }] 12 root -68 - 0K 736K WAIT 5 18.8H 24.66% [intr{irq260: ix0:que }] 12 root -68 - 0K 736K CPU3 3 18.5H 22.66% [intr{irq266: ix1:que }] 12 root -68 - 0K 736K WAIT 1 19.7H 20.90% [intr{irq264: ix1:que }] 12 root -68 - 0K 736K WAIT 3 20.0H 20.36% [intr{irq258: ix0:que }] 12 root -68 - 0K 736K WAIT 7 18.6H 20.07% [intr{irq262: ix0:que }] 12 root -68 - 0K 736K WAIT 4 19.4H 19.97% [intr{irq259: ix0:que }] 12 root -68 - 0K 736K WAIT 6 18.8H 19.38% [intr{irq261: ix0:que }] 12 root -68 - 0K 736K WAIT 6 18.3H 18.99% [intr{irq269: ix1:que }] 12 root -68 - 0K 736K CPU2 2 19.9H 18.36% [intr{irq257: ix0:que }] 12 root -68 - 0K 736K WAIT 2 19.9H 18.16% [intr{irq265: ix1:que }] 12 root -68 - 0K 736K WAIT 4 18.3H 17.19% [intr{irq267: ix1:que }] 12 root -68 - 0K 736K WAIT 7 18.5H 15.58% [intr{irq270: ix1:que }] 0 root -68 0 0K 480K - 0 57.9H 2.10% [kernel{dummynet}] # netstat -I ix1 -w1 -h input (ix1) output packets errs idrops bytes packets errs bytes colls 97k 0 0 49M 113k 0 109M 0 95k 0 0 48M 110k 0 104M 0 96k 0 0 51M 110k 0 104M 0 94k 0 0 49M 110k 0 106M 0 Флашил таблицы с теми, кто проходит через dummynet, трафик возрастал до 1.35 гигабита, загрузка ядер по прерываниям возрастала до 46%, т.е. запас еще есть. и это на E3-1270+HT. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 21 февраля, 2013 (изменено) · Жалоба У нас не серверная платформа, обычный core i7-3770 в приличной десктопной мамке 8 Гб памяти утренняя загрузка (40 проц от вечерней) на НАТ сервере (int ix0 - смотрит в мир) 188k 0 0 214M 126k 0 38M 0 0 188k 0 0 214M 125k 0 38M 0 0 200k 0 0 230M 133k 0 40M 0 0 195k 0 0 220M 132k 0 39M 0 0 Загрузка проца: last pid: 90986; load averages: 2.67, 2.89, 3.03 up 9+20:52:41 13:25:43 112 processes: 6 running, 81 sleeping, 25 waiting CPU 0: 0.0% user, 0.0% nice, 1.2% system, 46.1% interrupt, 52.8% idle CPU 1: 0.0% user, 0.0% nice, 1.2% system, 47.6% interrupt, 51.2% idle CPU 2: 0.0% user, 0.0% nice, 0.8% system, 43.7% interrupt, 55.5% idle CPU 3: 0.0% user, 0.0% nice, 1.6% system, 43.7% interrupt, 54.7% idle Mem: 26M Active, 185M Inact, 1220M Wired, 1207M Buf, 10G Free все по местным рекомендациям. OS: FB 9.1 ipfw nat в 120 instances, dummynet по таблицам Азамат подскажите какую серверную платформу используете, какой проц. Изменено 21 февраля, 2013 пользователем Azamat Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 21 февраля, 2013 · Жалоба Отключение гипертрединга не помогло. Подскажите, пожалуйста, что еще можно подкрутить? Буду разгружать этот роутер, и выбирать процессор. Сначала хотел i7-3970X , но в мануале к материнской плате supermicro X9SRi-F пишут, что только E5-2600/E5-1600. Из E5-2600 серии процессоров с частотой больше 3 ГГц не нашлось (либо дорого), видимо придется искать E5-1600 серию, только что то их на там же n i x.ru нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 21 февраля, 2013 (изменено) · Жалоба Если запускать команду от рута, то корректно ровно так же, зато более производительно :-) кавычку в конце второй строки шелл сам не подставит :) Пытались с John_obn прибивать dummynet по разным ядрам, на третьем ядре неожиданно загрузка dummynet'ом упала вполовину, но потом всё равно дошла до 100%. Еще в логах пролетело некоторое кол-во сообщений вида kernel: copy_obj (WARN) type 4 inst 65539 have 92 need 96 kernel: copy_obj (WARN) type 4 inst 65539 have 60 need 96 kernel: copy_obj (WARN) type 4 inst 65539 have 92 need 96 Изменено 21 февраля, 2013 пользователем umike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dadv Опубликовано 21 февраля, 2013 · Жалоба Отключение гипертрединга не помогло. Подскажите, пожалуйста, что еще можно подкрутить? Буду разгружать этот роутер, и выбирать процессор. Сначала хотел i7-3970X , но в мануале к материнской плате supermicro X9SRi-F пишут, что только E5-2600/E5-1600. Из E5-2600 серии процессоров с частотой больше 3 ГГц не нашлось (либо дорого), видимо придется искать E5-1600 серию, только что то их на там же n i x.ru нет. Вам нужно не процессоры тасовать, а добиваться равномерной загрузки ядер системы, то есть решать архитектурную проблему. У вас большинство из них вполовину простаивает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dadv Опубликовано 21 февраля, 2013 · Жалоба Отключение гипертрединга не помогло. Подскажите, пожалуйста, что еще можно подкрутить? У вас будет всё плохо, пока вы не удалите pf из ядра полностью. Дело в том, что в восьмерке pf использует глобальную блокировку для всего трафика, при этом обрабатывает трафик в один поток. Поэтому в ядре возникает lock contention, когда другие подсистемы вместо полезной работы начинают драться за право захватить блокировку. pf работает в контексте обработчика прерывания сетевой карты, поэтому, как и ipfw, не виден в top. Не откажетесь от pf полностью - лучше вам не станет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 21 февраля, 2013 (изменено) · Жалоба Евгений, про однопоточность pf-nat в курсе, ipfw nat в множество instance смотрели, загрузка тоже менялась достаточно рандомно. Смущает что ровно те-же pps и Mbps E3-1270 при той-же конфигурации софта обрабатываются спокойно. С точно таким-же pf и dummynet'ом и даже с такой-же карточкой. Изменено 21 февраля, 2013 пользователем umike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...