vitalyR Опубликовано 2 февраля, 2011 (изменено) · Жалоба Добрый день! Имеется сервер: - FreeBSD 8.1-RELEASE amd64 - 2 x igb карточки, <Intel® PRO/1000 Network Connection version - 1.9.5> - 2 x CPU: Intel® Xeon® CPU E5620 @ 2.40GHz, всего 16 ядер - 4Гб RAM - ipfw+nat+dummynet cat /boot/loader.conf net.isr.maxthreads=8 kern.ipc.nmbclusters=65536 hw.igb.rxd=2048 hw.igb.txd=2048 net.isr.bindthreads=1 часть sysctl.conf: cat /etc/sysctl.conf net.inet.ip.fw.one_pass=0 net.link.ether.ipfw=0 net.isr.direct=0 net.isr.direct_force=0 net.inet.ip.intr_queue_maxlen=1024 net.route.netisr_maxqlen=1024 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=8192 net.inet.ip.dummynet.expire=1 net.inet.ip.fastforwarding=0 net.inet.ip.forwarding=1 Сразу оговорюсь, что при текущей пиковой нагрузке 200Мбит/с и около 20-30 kpps (in/out) у меня нет никаких проблем или ошибок!!! Вопрос мой касается следующего: почему вне зависимости от значения net.isr.maxthreads (8 9 10) используется только 4 netisr потока, а остальные курят??? При net.isr.maxthreads=8 такая картина вечером: top -SH -n 500 | grep isr 12 root -44 - 0K 720K WAIT 15 696:03 26.98% {swi1: netisr 15} 12 root -44 - 0K 720K WAIT 13 631:42 25.66% {swi1: netisr 13} 12 root -44 - 0K 720K WAIT 0 690:25 22.98% {swi1: netisr 0} 12 root -44 - 0K 720K CPU14 14 698:00 22.69% {swi1: netisr 14} 12 root -44 - 0K 720K WAIT 11 0:00 0.00% {swi1: netisr 11} 12 root -44 - 0K 720K WAIT 9 0:00 0.00% {swi1: netisr 9} 12 root -44 - 0K 720K WAIT 10 0:00 0.00% {swi1: netisr 10} 12 root -44 - 0K 720K WAIT 0 0:00 0.00% {swi1: netisr 12} Увеличиваешь net.isr.maxthreads=10, картина остается прежней... Конечно, сейчас сервер отлично справляется с нагрузкой, но хотелось бы, чтобы в будущем у меня не было такого, что 4 ядра нагружены, а остальные 12 курили. Этот вопрос неоднократно поднимался, например, в этой теме: http://forum.nag.ru/forum/index.php?showto...rt=#entry569422 НО я так и не понял, что все таки надо допиливать и куда смотреть! Если я недостаточно точно обрисовал картину, напишите, что еще нужно и я обязательно кину необходимые данные=) -- С уважением Разживин Виталий г. Тамбов Изменено 2 февраля, 2011 пользователем vitalyR Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmvds Опубликовано 17 февраля, 2011 · Жалоба аналогичная проблема, есть какое-то решение? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 19 февраля, 2011 · Жалоба Какие именно интеловские карты у вас используются? Если с поддержкой MSI-X, и в обработке пакетов не задействован netgraph, то распараллелить нагрузку можно без net.isr. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmvds Опубликовано 20 февраля, 2011 · Жалоба поддерживается em0: Using MSIX interrupts with 5 vectors em1: Using MSIX interrupts with 5 vectors но netgraph задействован :( em такие: em0: <Intel(R) PRO/1000 Network Connection 7.0.5> port 0xdc00-0xdc1f mem 0xfbce0 000-0xfbcfffff,0xfbcdc000-0xfbcdffff irq 16 at device 0.0 on pci6 em1: <Intel(R) PRO/1000 Network Connection 7.0.5> port 0xec00-0xec1f mem 0xfbde0 000-0xfbdfffff,0xfbddc000-0xfbddffff irq 17 at device 0.0 on pci7 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 20 февраля, 2011 · Жалоба но netgraph задействован :( Как именно задействован? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmvds Опубликовано 21 февраля, 2011 · Жалоба но netgraph задействован :(Как именно задействован? 04998 176935409 24127356430 skipto 5990 ip from table(101) to any in via em005090 5406669966 3175293576658 pipe tablearg ip from table(121) to any in via em0 05990 5565513452 3184195737078 allow ip from table(121) to any in via em0 08090 5565078030 3187199099245 ngtee 21 ip from table(121) to any out via em1 09999 176744796 25277700292 skipto 20000 ip from table(100) to any out via em1 10090 5392033870 3165062425268 nat 100 ip from table(121) to any out via em1 20000 5982888510 5374922131587 nat 100 ip from any to me in via em1 29999 137786608 14945440282 skipto 30590 ip from any to table(101) in via em1 30090 5748944738 5361023299559 pipe tablearg ip from any to table(122) in via em1 30590 5737564637 5213241972935 ngtee 21 ip from any to table(121) in via em1 31090 5739160822 5214517829935 allow ip from any to table(121) in via em1 51090 5756396932 5237682243248 allow ip from any to table(121) out via em0 60000 5566568697 3188891460978 allow ip from any to any out via em1 65535 233378936 15151578217 deny ip from any to any в 121 таблице ip #исх пайпа в 122 таблице ip #вх пайпа Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 21 февраля, 2011 · Жалоба ngtee - это правильно. Netgraph будет работать в ng_queue, но ipfw останется в irq. По опыту, при замене "ngtee" на "netgraph" существенная часть нагрузки переедет из irq в net.isr (swi1:), а общая производительность упадёт. Как сейчас нагрузка распределяется по процессам в процентном соотношении? top -SHPb 100 | grep -v ' 0.00% ' Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyR Опубликовано 22 февраля, 2011 (изменено) · Жалоба Какие именно интеловские карты у вас используются?Если с поддержкой MSI-X, и в обработке пакетов не задействован netgraph, то распараллелить нагрузку можно без net.isr. Карты Intel 82575EB Gigabit Network Connection [igb] netgraph используется, но только для подсчета трафика, в целом nat и шейпинг - без netgraph, поэтому без netisr не получится. пробовал net.isr.direct=1, обработка идет в треде irq, но в целом задействуется так же только 4 ядра! ! ! Изменено 22 февраля, 2011 пользователем vitalyR Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmvds Опубликовано 22 февраля, 2011 · Жалоба ...Как сейчас нагрузка распределяется по процессам в процентном соотношении? top -SHPb 100 | grep -v ' 0.00% ' При полной нагрузке при net.isr.direct=0 last pid: 10381; load averages: 0.00, 0.00, 0.00 up 3+12:42:41 22:39:17 183 processes: 19 running, 112 sleeping, 1 stopped, 51 waiting CPU 0: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 3: 0.0% user, 0.0% nice, 1.1% system, 0.0% interrupt, 98.9% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 2.3% interrupt, 97.7% idle CPU 8: 0.0% user, 0.0% nice, 0.0% system, 16.5% interrupt, 83.5% idle CPU 9: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 10: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 98.5% interrupt, 1.5% idle CPU 12: 0.0% user, 0.0% nice, 0.0% system, 1.9% interrupt, 98.1% idle CPU 13: 0.0% user, 0.0% nice, 0.0% system, 1.1% interrupt, 98.9% idle CPU 14: 0.0% user, 0.0% nice, 0.0% system, 100% interrupt, 0.0% idle CPU 15: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 28M Active, 231M Inact, 330M Wired, 392K Cache, 63M Buf, 2371M Free Swap: 4096M Total, 4096M Free Т.е. 2 ядра грузятся под 100% и все, на остальные идет по 1-4% при net.isr.direct=1 кстати ситуация почти такая же last pid: 84879; load averages: 1.35, 1.36, 1.31 up 9+10:47:59 20:44:35 183 processes: 20 running, 111 sleeping, 1 stopped, 51 waiting CPU 0: 0.0% user, 0.0% nice, 1.1% system, 0.0% interrupt, 98.9% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 2: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 5: 0.0% user, 0.0% nice, 94.4% system, 0.0% interrupt, 5.6% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 84.2% interrupt, 15.8% idle CPU 8: 0.0% user, 0.0% nice, 0.0% system, 1.1% interrupt, 98.9% idle CPU 9: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 10: 0.0% user, 0.0% nice, 0.0% system, 0.4% interrupt, 99.6% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 12: 0.0% user, 0.0% nice, 0.0% system, 96.2% interrupt, 3.8% idle CPU 13: 0.0% user, 0.0% nice, 0.0% system, 4.5% interrupt, 95.5% idle CPU 14: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 15: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 29M Active, 356M Inact, 342M Wired, 360K Cache, 63M Buf, 2234M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 256K CPU6 6 223.2H 100.00% {idle: cpu6} 11 root 171 ki31 0K 256K CPU9 9 223.2H 100.00% {idle: cpu9} 11 root 171 ki31 0K 256K CPU1 1 221.8H 100.00% {idle: cpu1} 11 root 171 ki31 0K 256K RUN 0 221.4H 100.00% {idle: cpu0} 11 root 171 ki31 0K 256K CPU8 8 221.3H 100.00% {idle: cpu8} 11 root 171 ki31 0K 256K CPU3 3 220.6H 100.00% {idle: cpu3} 11 root 171 ki31 0K 256K CPU11 11 209.1H 100.00% {idle: cpu11} 11 root 171 ki31 0K 256K CPU10 10 208.4H 100.00% {idle: cpu10} 11 root 171 ki31 0K 256K CPU15 15 205.8H 100.00% {idle: cpu15} 11 root 171 ki31 0K 256K CPU14 14 191.1H 100.00% {idle: cpu14} 12 root -68 - 0K 848K CPU12 12 57.8H 100.00% {irq261: em1} 0 root -68 0 0K 272K CPU2 2 170:18 100.00% {em1 rxq} 11 root 171 ki31 0K 256K CPU13 13 223.9H 96.92% {idle: cpu13} 12 root -68 - 0K 848K CPU7 7 40.5H 83.94% {irq256: em0} 11 root 171 ki31 0K 256K CPU4 4 208.3H 83.89% {idle: cpu4} 0 root -68 0 0K 272K - 5 36.3H 67.29% {dummynet} 11 root 171 ki31 0K 256K CPU5 5 217.3H 53.91% {idle: cpu5} 11 root 171 ki31 0K 256K RUN 7 185.9H 16.46% {idle: cpu7} 11 root 171 ki31 0K 256K RUN 12 169.1H 3.32% {idle: cpu12} 12 root -68 - 0K 848K WAIT 13 157:24 1.76% {irq262: em1} 12 root -68 - 0K 848K WAIT 8 130:27 0.73% {irq257: em0} 12 root -32 - 0K 848K WAIT 10 111:50 0.39% {swi4: clock} 0 root -68 0 0K 272K - 0 41:14 0.10% {em1 txq} 17 root 44 - 0K 16K syncer 0 5:40 0.05% syncer 0 root -68 0 0K 272K - 1 5:21 0.05% {em0 rxq} Но в этом случае на 100% забивается прерываниями карточка 12 root -68 - 0K 848K CPU12 12 57.8H 100.00% {irq261: em1} Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Сильвер Опубликовано 22 февраля, 2011 · Жалоба Но в этом случае на 100% забивается прерываниями карточка 12 root -68 - 0K 848K CPU12 12 57.8H 100.00% {irq261: em1} Для igb есть hw.igb.max_interrupt_rate. Им можно изменять лимит прерываний в секунду. Для em есть патч.Можно погуглить, есть некоторая информация для размышления. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyR Опубликовано 24 февраля, 2011 · Жалоба Но в этом случае на 100% забивается прерываниями карточка 12 root -68 - 0K 848K CPU12 12 57.8H 100.00% {irq261: em1} Для igb есть hw.igb.max_interrupt_rate. Им можно изменять лимит прерываний в секунду. Для em есть патч.Можно погуглить, есть некоторая информация для размышления. а можно по подробней про hw.igb.max_interrupt_rate....как увеличение или уменьшение его значения может повлиять на распараллеливание по CPU? что бы не делал, не получается задействовать больше 4 ядер из 16 имеющихся((( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmvds Опубликовано 25 февраля, 2011 · Жалоба а можно по подробней про hw.igb.max_interrupt_rate....как увеличение или уменьшение егозначения может повлиять на распараллеливание по CPU? что бы не делал, не получается задействовать больше 4 ядер из 16 имеющихся((( Да, все верно, единственное ядер не 4, а 2, гипертрейдинг не в счет. По поводу проблемы, мне подсказали что больше чем 2 ядра не нагрузится, как ни старайся, т.е. 2процессора * 4 ядра = 8 ядер, 100%/8 = 12,5% - одно ядро, умножаем на 2, 25%, именно до этой цифры после всех манипуляций и доходит нагрузка процессора. Посоветовали искать источник проблемы, а не устранять последствия. Проанализировал логи трафика по частоте отправки пакетов с 1 ip, получил следующее: около 2% юзеров отправляют от 1000 до 30 000 пакетов за 5 минут, еще 10% от 100 до 1000, все остальные менее 100 пакетов за 5 минут сделал список тех 2% юзеров, от которых отправка пакетов наибольшая и отдал техподдержке на обзвон, чтоб проверили на вирусы, как оказалось, многие просто пользуются торентами с кучей коннектов им "наплевать, их все устраивает". Моя тема на другом форуме _http://forum.lissyara.su/viewtopic.php?f=8&t=31297 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Сильвер Опубликовано 25 февраля, 2011 · Жалоба а можно по подробней про hw.igb.max_interrupt_rate....как увеличение или уменьшение егозначения может повлиять на распараллеливание по CPU? что бы не делал, не получается задействовать больше 4 ядер из 16 имеющихся((( Никак. Я на вопрос о прерываниях отвечал.По распараллеливанию Вам лучше в freebsd-net@ задать вопрос, Роберт там отписывается. Может быть стоит попробовать это. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 25 февраля, 2011 · Жалоба mmvds http://forum.nag.ru/forum/index.php?showtopic=58334 не ? но даже если там и заведется, о всю пачку ядер на задействовать... ну и там всякие /boot/loader.conf и vmstat -i ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyR Опубликовано 16 июля, 2011 · Жалоба забил я на эту отложенную обработку, никак не получилось распараллелить более, чем на 4 ядра, сделал так: 1. net.isr.direct=1 2. net.isr.direct_force=1 3. прибил igb треды к ядрам по tid`ам: procstat -at | sed -E '/irq.*igb*/!d;' | awk '{print $2, $4, $5;}'| sed -E 's/^([0-9]+) irq([0-9]+): igb([0-9])/\1 \2 \3/' | while read tid irq igb do cpu=$(( ($irq + $igb) % $cpus )) echo "Linking irg${irq}:igb${igb} to cpu${cpu}" ${cpusetctl} -l $cpu -t $tid done 2 x igb-карты, по 4 треда на карту, итого задействовано 8 ядер, еще 2 igb-треда (по одному с каждой карты) все равно "курят" полет пока нормальный, хотя особо больших нагрузок тоже не было, максимально около 50 килопакетов... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 июля, 2011 · Жалоба полет пока нормальный, хотя особо больших нагрузок тоже не было, максимально около 50 килопакетов... можно было вообще ничего не тюнить Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyR Опубликовано 18 июля, 2011 · Жалоба полет пока нормальный, хотя особо больших нагрузок тоже не было, максимально около 50 килопакетов... можно было вообще ничего не тюнить пробовал...все 8 igb-тредов собираются в кучу на 4 ядра, с прибиванием хотя бы на 8 получается разбить! до сих пор остается для меня все равно непонятным почему по 1 одному треду с каждой карточки все равно бездействует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 июля, 2011 · Жалоба Откройте исходники и почитайте. На вскидку, возможно "бездейстуют" потоки которые обслуживают линкстатус портов карточки, под это отдельное прерывание есть в железе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyR Опубликовано 20 июля, 2011 · Жалоба На вскидку, возможно "бездейстуют" потоки которые обслуживают линкстатус портов карточки, под это отдельное прерывание есть в железе. как вариант.....всего {irqXXX: igb}-тредов у меня 10, а {igbX que}-тредов 8 штук, плюс 2 штуки вида {igbX link}, которые как раз наверное и отвечают за линк-статус, итого в обработке трафа участвуют только 8 {irqXXX: igb}-тредов! судя по исходникам: /* ** This will autoconfigure based on ** the number of CPUs if left at 0. */ static int igb_num_queues = 0; TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); количество очередей регулируется параметром hw.igb.num_queues, попробую поиграться с его значением... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 20 июля, 2011 · Жалоба А я бы гипертрейдинг отключил нафиг, от него только top ядрами обрастает и админ расслабляется. И процессор второй вынул, не нужен он там. 5620 ксеон в качестве рррое-концентратора соло молотит под 200 кппс в каждую сторону с натом шейпером, шахматами и поэтессами. При этом успешно укладываются в планку 4 порта собраные в 2 lagg практически без тюнинга. А много потоков это не всегда хорошо, иногда даже плохо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyR Опубликовано 21 июля, 2011 · Жалоба А я бы гипертрейдинг отключил нафиг, от него только top ядрами обрастает и админ расслабляется. И процессор второй вынул, не нужен он там. 5620 ксеон в качестве рррое-концентратора соло молотит под 200 кппс в каждую сторону с натом шейпером, шахматами и поэтессами. При этом успешно укладываются в планку 4 порта собраные в 2 lagg практически без тюнинга. А много потоков это не всегда хорошо, иногда даже плохо. насчет гипертрединга у меня уже давно такие мысли, ничего хорошего от него нету, все руки не доходят, но второй проц вынимать не буду! а насчет количества потоков, по 4 потока на карту эт как бы не оч и много, при условии наличия всего 2 карт =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimic Опубликовано 27 августа, 2011 · Жалоба Ребят, в чем может быть проблема? в /boot/loader.conf: cat /boot/loader.conf net.isr.maxthreads=3 hw.bge.allow_asf=1 net.inet.tcp.tcbhashsize=4096 Но после перезагрузки все равно: sysctl net.isr.maxthreads net.isr.maxthreads: 1 Почему не удается увеличить количество тредов? Одного потока катастрофически не хватает. ОС - FreeBSD 8.2-STABLE amd64 Сервак HP Proliant DL-360 G4 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimic Опубликовано 27 августа, 2011 · Жалоба Все, разобрался. DEVICE_POLLING из ядра выкинуть забыл.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimic Опубликовано 27 сентября, 2011 · Жалоба Теперь картина следующая: top -PSH -n 1000 | grep netisr 12 root -44 - 0K 336K CPU0 0 180.1H 72.17% {swi1: netisr 2} 12 root -44 - 0K 336K CPU1 1 238.9H 68.95% {swi1: netisr 3} 12 root -44 - 0K 336K WAIT 3 124.9H 0.00% {swi1: netisr 0} Я так понял только по физическим ядрам. Где-то при 30К ппс появляются ощутимые тормоза, когда netisr полностью сжирает оба процессора. Можно ли из этой железки больше выжать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Рейнер Дмитрий Опубликовано 20 октября, 2011 · Жалоба Где-то при 30К ппс появляются ощутимые тормоза, когда netisr полностью сжирает оба процессора. Можно ли из этой железки больше выжать? Собственно присоединяюсь к вопросу? Кстати, коллега, а у вас на нем что-то помимо маршрутизации крутиться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...