[2ihi]

Друзья, имеется сервер 360G5 с 2мя картами intel дуал порт и квад порт (em0-em5) на железе крутится следующий софт:

 

uname -a
FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Wed Aug  8 18:26:26 KRAT 2012     root@bgp:/sys/amd64/compile/bgp  amd64

 

dummynet без нагрузки с

cpuset -l 0 -t $(procstat -t 0 | awk '/dummynet/ {print $2}')

pf nat + pf forwarding по таблицам

ipfw с правилом

ipfw add 100 allow ip from any to any

BGP на Quagga version 0.99.20

em0+em1 входят в lagg0 протокол lacp

 

ядро скомпилино с опцией lagg, ipfw, dummynet. Убраны дебаг, все остальное стандартно.

 

из тюнинга только:

 

sysctl.conf

dev.em.0.rx_int_delay=200
dev.em.0.tx_int_delay=200
dev.em.0.rx_abs_int_delay=4000
dev.em.0.tx_abs_int_delay=4000
dev.em.0.rx_processing_limit=4096

dev.em.1.rx_int_delay=200
dev.em.1.tx_int_delay=200
dev.em.1.rx_abs_int_delay=4000
dev.em.1.tx_abs_int_delay=4000
dev.em.1.rx_processing_limit=4096


dev.em.2.rx_int_delay=200
dev.em.2.tx_int_delay=200
dev.em.2.rx_abs_int_delay=4000
dev.em.2.tx_abs_int_delay=4000
dev.em.2.rx_processing_limit=4096

dev.em.3.rx_int_delay=200
dev.em.3.tx_int_delay=200
dev.em.3.rx_abs_int_delay=4000
dev.em.3.tx_abs_int_delay=4000
dev.em.3.rx_processing_limit=4096

dev.em.4.rx_int_delay=200
dev.em.4.tx_int_delay=200
dev.em.4.rx_abs_int_delay=4000
dev.em.4.tx_abs_int_delay=4000
dev.em.4.rx_processing_limit=4096

dev.em.5.rx_int_delay=200
dev.em.5.tx_int_delay=200
dev.em.5.rx_abs_int_delay=4000
dev.em.5.tx_abs_int_delay=4000
dev.em.5.rx_processing_limit=4096

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1

net.inet.tcp.drop_synfin=1
kern.corefile=/tmp/%U.%N.%P.core

 

loader.conf

autoboot_delay="3"
net.isr.maxthreads=4
hw.em.rxd=4096
hw.em.txd=4096

 

 

Вроде всё. Всё хорошо работает, прям на удивление, продавливает в данный момент 200 мегабайт (у меня еще утро), но заметил странный глюк, em0 и em1 образуют lagg0, нагрузка примерно одинаковая по портам но em0 заметно обгоняет по времени процессора em1 и при простом top -SCH видно что нагрузка у em0 в разы выше 31.47% kernel{em0 taskq} против 9.47% kernel{em1 taskq} тогда как pps и трафик различается ну процентов на 30.

 

Так же странным образом проскакивает нагрузка на em4, да сразу по 40-50% тогда как эта карта включается в такой же интел на другом сервере и там подобного рода "всплесков" не наблюдается..

 

em0 это первый порт первой карты, em4 так же первый порт уже второй карты.

 

так же периодами наблюдаю вот такую вещь

34.60% intr{swi4: clock}

- подпрыгнет, постоит минуты 2-3 и снова уходит в нули..

 

Кто чего может подсказать по этим вопросам? Или просто не заморачиваться? На стадии тестирования таких проблем явно видно небыло, сервер прогонялся 3ое суток под качающими нагрузками + там еще и ng_netflow с сенсорами для пущей жестокости были включены.

 

еще вопросец, про многопоточность драйверов em - что-то я с маху и не заметил что один порт обрабатывает 2 и более ядер процессоров, как в этом можно убедиться как например в случае с драйверами яндекса было?

 

Ну и всеж извечный вопрос - что в 9ке (по вашему мнению) стоит подкрутить для просёру большого количества pps и трафика через em карты?

[2ihi]

UPD

Пришлось увеличить некоторые буферы, ибо в 200к pps начали проскакивать ошЫбки.

[andryas]

Поддерживаю вопрос, ибо собрался апгрейдится с 7-ки, тоже используюю lagg, катрочки et и pt. Трафика, правда, побольше, сейчас около гигабита через этот роутер.

[Ivan_83]

net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch.

net.inet.ip.fastforwarding=0 # packets are forwarded directly to the appropriate network interface with a min validity checking, which greatly improves the throughput

[2ihi]

net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch.

net.inet.ip.fastforwarding=0 # packets are forwarded directly to the appropriate network interface with a min validity checking, which greatly improves the throughput

 

млять, точно, эксперементил и забыл добавить в sysctl.conf

 

Короче говоря, вердикт еще рано выносить, но буферов стоит поднакинуть, хоть многие и говорят что все и так зашибись, тем не менее.... имеем то что имеем.

 

Кстати с fastforwarding со времен 8.2 опасаюсь.. В 9ке детские грабли надеюсь подобрали..?

Edited August 16, 2012 by 2ihi

[Ivan_83]

Разбансилось по процам и перекос исчез?

Какие были болезни с фастфорвадом?

[2ihi]

Разбансилось по процам и перекос исчез?

Какие были болезни с фастфорвадом?

перекос небольшой есть (не критично), разнеслось по ядрам да, от тестового стенда правда задействовано 4 ядра в лоадере, но это после ребута устраню, а проблемы были с фастфорвадом в купе с PF и\или lagg, помню патч накатывал, но что куда и зачем уже подзабыл.. Вызывало на 8.1\8.2 (возможно и 8.0 но её я помню после проблем с нетграфом быстро свернул) зависания, которые никак ни по времени, ни по звездам не прогнозировались. Короче я спать, вторые сутки на ногах с этими инсталляциями.. Завтра с утра на трезвую голову на вопросы готов отвечать..

[nera]

UPD

Пришлось увеличить некоторые буферы, ибо в 200к pps начали проскакивать ошЫбки.

Доброе время суток!

С аналогичной проблемой столкнулись. Раньше стала 7-ка и дрова от яндекса для em пропускная способность получалась выше. Сейчас проапдейтелись до 9-ки и уже при 120k pps вижу ошибки. не поделитесь своими подкрутками?

заранее благодарен.

[2ihi]

UPD

Пришлось увеличить некоторые буферы, ибо в 200к pps начали проскакивать ошЫбки.

Доброе время суток!

С аналогичной проблемой столкнулись. Раньше стала 7-ка и дрова от яндекса для em пропускная способность получалась выше. Сейчас проапдейтелись до 9-ки и уже при 120k pps вижу ошибки. не поделитесь своими подкрутками?

заранее благодарен.

 

Да поделюсь конечно, завтра с утра (6мск и позже) стукните в приват - скину.. Сейчас уже поздно, голова не соображает..

[apm]

Зачем в приват. Давайте, всем интересно

[nera]

Пока и в приват не дождался. ждемс... :(

[kosd]

net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch.

Спасибо большое! Реально разнесло прерывания по ядрам.

[roysbike]

net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch.

Спасибо большое! Реально разнесло прерывания по ядрам.

а меня не особо разнесло. netisr1 отжирает больше. Freebsd 9.1 MPD5 , только PPPoE . 4 ядра , ната нет. 2 порта карты em0 и em1 .

на em1 100 вланов , слушает MPD5.6

 

loader.conf

net.isr.numthreads=2
net.isr.maxthreads=2
net.isr.defaultqlimit=4096
hw.em.rxd=4096
hw.em.txd=4096

 

net.isr.dispatch=deferred

 

 

top -SHPI

last pid: 42980;  load averages:  1.24,  1.17,  1.03                                                                                               up 0+01:01:58  23:05:11
110 processes: 6 running, 88 sleeping, 16 waiting
CPU 0:  0.8% user,  0.0% nice,  2.4% system,  0.0% interrupt, 96.9% idle
CPU 1:  0.0% user,  0.0% nice,  4.3% system,  0.0% interrupt, 95.7% idle
CPU 2:  0.0% user,  0.0% nice,  0.4% system,  2.0% interrupt, 97.6% idle
CPU 3:  0.0% user,  0.0% nice,  0.0% system,  9.8% interrupt, 90.2% idle
Mem: 27M Active, 42M Inact, 190M Wired, 55M Buf, 3651M Free
Swap: 1526M Total, 1526M Free

 PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root       155 ki31     0K    64K CPU2    2  60:28 100.00% idle{idle: cpu2}
  11 root       155 ki31     0K    64K CPU0    0  58:46 98.88% idle{idle: cpu0}
  11 root       155 ki31     0K    64K RUN     1  60:03 98.49% idle{idle: cpu1}
  11 root       155 ki31     0K    64K RUN     3  58:43 88.48% idle{idle: cpu3}
  12 root       -72    -     0K   272K CPU3    3   1:46 12.70% intr{swi1: netisr 1}
   0 root       -92    0     0K   208K -       1   2:33  5.76% kernel{em1 que}
   0 root       -92    0     0K   208K -       0   2:07  2.49% kernel{em0 que}
  12 root       -72    -     0K   272K WAIT    2   0:13  2.39% intr{swi1: netisr 0}
32800 root        52    0 75464K 19032K select  2   0:23  0.29% mpd5{mpd5}
32800 root        52    0 75464K 19032K select  3   0:00  0.29% mpd5{mpd5}
9435 root        20    0 43336K  8076K select  1   0:13  0.20% snmpd
32800 root        52    0 75464K 19032K select  3   0:00  0.20% mpd5{mpd5}

Edited January 2, 2013 by roysbike

[Ivan_83]

А может не стоит ограничиваться двумя потоками при 4 ядрах?

Нагрузка зависит от пути пакета, из того на что легко повлиять - правила фаервола.

[roysbike]

А может не стоит ограничиваться двумя потоками при 4 ядрах?

Нагрузка зависит от пути пакета, из того на что легко повлиять - правила фаервола.

попробую четыре. Я другого понять не могу. я не раз уже писал, net.isr меня не спасает. Есть еще один сервер freebsd 9.0 2 порта, igb1 и igb2 в lagg1 (100 влнов слушает PPPoE). 2 порта, igb2 igb3 тоже в lagg0 , это на uplink. Картина следущая , проработает сервер более 1 нед и прерывания igb2 и igb3 выше по загрузке чем на igb0 igb1 в 3 РАЗА!, хотя в первые 3 дня были поровну. pps не изменялся кол-во юзеров 1000 приверно. 4 ядра прибиты к потокам . Сервер HP. Intel® Xeon® CPU E5620 @ 2.40GHz

В первый день хоть 1500 мбит прокачает без проблем, через неделю и 500 не выжмет, упрется в interrupt , не могу найти логическое оъяснения. Как будут счетчики каике переполняются))

top -SHPI

cpu0 трудится над igb0 cpu1-igb1 cpu2-igb2 cpu3-igb3

 

last pid: 27649;  load averages:  1.76,  1.74,  1.70                                                                         up 14+19:19:36  00:19:08
162 processes: 5 running, 115 sleeping, 42 waiting
CPU 0:  1.6% user,  0.0% nice,  0.0% system, 18.0% interrupt, 80.4% idle
CPU 1:  1.6% user,  0.0% nice,  0.0% system, 14.3% interrupt, 84.1% idle
CPU 2:  0.0% user,  0.0% nice,  0.0% system, 67.2% interrupt, 32.8% idle
CPU 3:  1.6% user,  0.0% nice,  0.0% system, 62.4% interrupt, 36.0% idle
Mem: 1328M Active, 1368M Inact, 900M Wired, 622M Buf, 2332M Free
Swap: 4096M Total, 4096M Free

 PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root     155 ki31     0K    64K CPU0    0 308.7H 83.06% idle{idle: cpu0}
  11 root     155 ki31     0K    64K CPU1    1 294.6H 80.08% idle{idle: cpu1}
  12 root     -92    -     0K   672K WAIT    2  28.4H 60.35% intr{irq266: igb2:que}
  12 root     -92    -     0K   672K WAIT    3  24.6H 57.08% intr{irq271: igb3:que}
  11 root     155 ki31     0K    64K CPU2    2 281.6H 42.77% idle{idle: cpu2}
  11 root     155 ki31     0K    64K RUN     3 284.8H 41.80% idle{idle: cpu3}
  12 root     -92    -     0K   672K WAIT    1 156:56  6.98% intr{irq261: igb1:que}
  12 root     -92    -     0K   672K WAIT    0 143:37  4.30% intr{irq259: igb0:que}
  12 root     -92    -     0K   672K WAIT    0 142:54  3.47% intr{irq257: igb0:que}
  12 root     -92    -     0K   672K WAIT    1 142:08  3.47% intr{irq264: igb1:que}
  12 root     -92    -     0K   672K WAIT    0 287:21  3.27% intr{irq256: igb0:que}
  12 root     -92    -     0K   672K WAIT    0 143:24  3.27% intr{irq258: igb0:que}
  12 root     -92    -     0K   672K WAIT    1 143:35  2.59% intr{irq262: igb1:que}
10702 root      22    0 37596K  9372K select  2 526:31  2.49% snmpd
  12 root     -92    -     0K   672K WAIT    1 140:38  2.49% intr{irq263: igb1:que}
10587 root      20    0  1854M  1526M select  1 464:18  0.59% mpd5{mpd5}
  12 root     -92    -     0K   672K WAIT    1  68:24  0.20% intr{irq272: igb3:que}

 

netstat -w1 -h

pppoe2# netstat -w1 -h
           input        (Total)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
     144k     0     0        98M       154k     0       136M     0
     141k     0     0        97M       149k     0       131M     0
     135k     0     0        96M       144k     0       129M     0
     140k     0     0        99M       149k     0       132M     0

pppoe2# ifconfig | grep ng -c
727

Edited January 3, 2013 by roysbike

[2ihi]

Зачем в приват. Давайте, всем интересно

 

Ребят, я ж говорил:

Да поделюсь конечно, завтра с утра (6мск и позже) стукните в приват ..

Не для того чтоб в приват ответить, а чтоб напомнили, ну коль не стукнули - значит так нужно было..

 

 

Еще актуально кому?

 

 

 

PS Перехожу на IGB в самом ближайшем будущем ибо EM не вывозит :(

 

Суммарный трафик до 450 мегабАйт подпрыгивает, на ем нихрена не паралеллится можно сказать..

[2ihi]

вах, приношу свои извинения, почему-то на почту уведомления о личках не пришли, только сейчас заметил...

[napTu]

проработает сервер более 1 нед и прерывания igb2 и igb3 выше по загрузке чем на igb0 igb1 в 3 РАЗА!, хотя в первые 3 дня были поровну. pps не изменялся кол-во юзеров 1000 приверно. 4 ядра прибиты к потокам . Сервер HP. Intel® Xeon® CPU E5620 @ 2.40GHz

В первый день хоть 1500 мбит прокачает без проблем, через неделю и 500 не выжмет, упрется в interrupt , не могу найти логическое оъяснения. Как будут счетчики каике переполняются))

 

 

похожую ситуацию давно наблюдаю на 8.1 с яндекс дровами,

когда перезагрузка раза в два снижает пиковую нагрузку CPU.

 

Были идеи что замусориваются таблицы в ipfw или еще какие буфера.

 

А то что перекос входа-выхода разных интерфейсов роутера, так это действительно быстрее всего разный путь обработки пакета в ipfw

[NeXuSs]

2ihi

 

Конечно актуально, скинь пожалуйста, очень интересно посмотреть. )

[roma33rus]

поддерживаю

[roysbike]

проработает сервер более 1 нед и прерывания igb2 и igb3 выше по загрузке чем на igb0 igb1 в 3 РАЗА!, хотя в первые 3 дня были поровну. pps не изменялся кол-во юзеров 1000 приверно. 4 ядра прибиты к потокам . Сервер HP. Intel® Xeon® CPU E5620 @ 2.40GHz

В первый день хоть 1500 мбит прокачает без проблем, через неделю и 500 не выжмет, упрется в interrupt , не могу найти логическое оъяснения. Как будут счетчики каике переполняются))

 

 

похожую ситуацию давно наблюдаю на 8.1 с яндекс дровами,

когда перезагрузка раза в два снижает пиковую нагрузку CPU.

 

Были идеи что замусориваются таблицы в ipfw или еще какие буфера.

 

А то что перекос входа-выхода разных интерфейсов роутера, так это действительно быстрее всего разный путь обработки пакета в ipfw

Заметил , что помогает погашение внеш интерфейса , на 2-3 минуты. Видимо чет там очищатеся , но не надолго . 3-5 Дней . Пока такое решение у меня.