[vitalyR]

Добрый день!

 

Имеется сервер:

- 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

[mmvds]

аналогичная проблема, есть какое-то решение?

[Ilya Evseev]

Какие именно интеловские карты у вас используются?

Если с поддержкой MSI-X, и в обработке пакетов не задействован netgraph,

то распараллелить нагрузку можно без net.isr.

[mmvds]

поддерживается

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

[Ilya Evseev]

но netgraph задействован :(

Как именно задействован?

[mmvds]

но netgraph задействован :(

Как именно задействован?

04998 176935409 24127356430 skipto 5990 ip from table(101) to any in via em0

05090 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 #вх пайпа

[Ilya Evseev]

ngtee - это правильно.

Netgraph будет работать в ng_queue, но ipfw останется в irq.

По опыту, при замене "ngtee" на "netgraph" существенная часть нагрузки

переедет из irq в net.isr (swi1:), а общая производительность упадёт.

 

Как сейчас нагрузка распределяется по процессам в процентном соотношении?

top -SHPb 100 | grep -v ' 0.00% '

[vitalyR]

Какие именно интеловские карты у вас используются?

Если с поддержкой MSI-X, и в обработке пакетов не задействован netgraph,

то распараллелить нагрузку можно без net.isr.

Карты Intel 82575EB Gigabit Network Connection [igb]

 

netgraph используется, но только для подсчета

трафика, в целом nat и шейпинг - без netgraph,

поэтому без netisr не получится.

 

пробовал net.isr.direct=1, обработка идет в треде irq,

но в целом задействуется так же только 4 ядра! ! !

Изменено 22 февраля, 2011 пользователем vitalyR

[mmvds]

...

Как сейчас нагрузка распределяется по процессам в процентном соотношении?

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}

[Сильвер]

Но в этом случае на 100% забивается прерываниями карточка

12 root -68 - 0K 848K CPU12 12 57.8H 100.00% {irq261: em1}

Для igb есть hw.igb.max_interrupt_rate. Им можно изменять лимит прерываний в секунду. Для em есть патч.

Можно погуглить, есть некоторая информация для размышления.

 

[vitalyR]

Но в этом случае на 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 имеющихся(((

 

[mmvds]

а можно по подробней про 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

[Сильвер]

а можно по подробней про hw.igb.max_interrupt_rate....как увеличение или уменьшение его

значения может повлиять на распараллеливание по CPU? что бы не делал, не получается

задействовать больше 4 ядер из 16 имеющихся(((

Никак. Я на вопрос о прерываниях отвечал.

По распараллеливанию Вам лучше в freebsd-net@ задать вопрос, Роберт там отписывается. Может быть стоит попробовать это.

[st_re]

mmvds

http://forum.nag.ru/forum/index.php?showtopic=58334

не ? но даже если там и заведется, о всю пачку ядер на задействовать... ну и там всякие /boot/loader.conf и vmstat -i ?

[vitalyR]

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

[Ivan_83]

полет пока нормальный, хотя особо больших нагрузок тоже не было, максимально около 50 килопакетов...

 

можно было вообще ничего не тюнить

 

 

[vitalyR]

полет пока нормальный, хотя особо больших нагрузок тоже не было, максимально около 50 килопакетов...

 

можно было вообще ничего не тюнить

 

пробовал...все 8 igb-тредов собираются в кучу на 4 ядра, с прибиванием хотя

бы на 8 получается разбить! до сих пор остается для меня все равно непонятным

почему по 1 одному треду с каждой карточки все равно бездействует.

[Ivan_83]

Откройте исходники и почитайте.

 

На вскидку, возможно "бездейстуют" потоки которые обслуживают линкстатус портов карточки, под это отдельное прерывание есть в железе.

 

 

[vitalyR]

 

На вскидку, возможно "бездейстуют" потоки которые обслуживают линкстатус портов карточки, под это отдельное прерывание есть в железе.

 

как вариант.....всего {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,

попробую поиграться с его значением...

[make.kernel]

А я бы гипертрейдинг отключил нафиг, от него только top ядрами обрастает и админ расслабляется. И процессор второй вынул, не нужен он там. 5620 ксеон в качестве рррое-концентратора соло молотит под 200 кппс в каждую сторону с натом шейпером, шахматами и поэтессами. При этом успешно укладываются в планку 4 порта собраные в 2 lagg практически без тюнинга. А много потоков это не всегда хорошо, иногда даже плохо.

[vitalyR]

А я бы гипертрейдинг отключил нафиг, от него только top ядрами обрастает и админ расслабляется. И процессор второй вынул, не нужен он там. 5620 ксеон в качестве рррое-концентратора соло молотит под 200 кппс в каждую сторону с натом шейпером, шахматами и поэтессами. При этом успешно укладываются в планку 4 порта собраные в 2 lagg практически без тюнинга. А много потоков это не всегда хорошо, иногда даже плохо.

 

насчет гипертрединга у меня уже давно такие мысли, ничего хорошего от него нету, все руки не доходят,

но второй проц вынимать не буду! а насчет количества потоков, по 4 потока на карту эт как бы не оч и

много, при условии наличия всего 2 карт =)

[Dimic]

Ребят, в чем может быть проблема?

в /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

[Dimic]

Все, разобрался. DEVICE_POLLING из ядра выкинуть забыл..

[Dimic]

Теперь картина следующая:

 

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 полностью сжирает оба процессора.

 

Можно ли из этой железки больше выжать?

[Рейнер Дмитрий]

Где-то при 30К ппс появляются ощутимые тормоза, когда netisr полностью сжирает оба процессора.

Можно ли из этой железки больше выжать?

Собственно присоединяюсь к вопросу?

 

Кстати, коллега, а у вас на нем что-то помимо маршрутизации крутиться?