[morfair]

Прочитал несколько тем на сим форуме, касаемо высокой нагрузке Linux router'а с сетевой картой Intel 82576, но остались вопросы. Надеюсь, подскажите.

Хочу сразу сказать, что руководствовался этим: http://www.intel.com/support/network/adapter/pro100/sb/cs-032498.htm

 

1) Когда собирал модуль igb-4.0.17 на ядре 2.6.32-5-686 (Debian), компиляция останавливалась с ошибкой, что решалось только указанием параметра: make CFLAGS_EXTRA=-DDISABLE_PM install. Насколько отключение этой функции критично и за что оно отвечает?

 

2) Очереди и вектора. Когда без параметров инициализирую модуль (modprobe igb), получаю:

 

dmesg:

Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

/proc/interrupts:

  25:          0          0          0          0          0          0   PCI-MSI-edge      eth1
 26:          0          0          0          0          0          3   PCI-MSI-edge      eth1-TxRx-0

 

Получилась одна очередь с совмещенными векторами rx/tx. Стоит 6'ти ядерный процессор, сетевая карта двухпортовая. Я так понимаю, что мне нужно на каждый интерфейс по три очереди, чтобы каждое ядро занималось своей. Т.е. делаем modprobe igb VMDQ=3,3 и получаем:

 

dmesg:

igb_validate_option: VMDQ - VMDq multiqueue queue count set to 3
...
Using MSI-X interrupts. 3 rx queue(s), 3 tx queue(s)

/proc/interrupts:

  25:          0          0          0          0          0          0   PCI-MSI-edge      eth1
 26:          0          0          0         45          0          0   PCI-MSI-edge      eth1-TxRx-0
 27:          0          0          0          0         45          0   PCI-MSI-edge      eth1-TxRx-1
 28:          0          0          0          0          0         45   PCI-MSI-edge      eth1-TxRx-2
 29:          0          0          0          0          0          0   PCI-MSI-edge      eth2
 30:          0          0          0          1          0          0   PCI-MSI-edge      eth2-TxRx-0
 31:          0          0          0          0          1          0   PCI-MSI-edge      eth2-TxRx-1
 32:          0          0          0          0          0          1   PCI-MSI-edge      eth2-TxRx-2

 

К тому же можно разделить вектора, modprobe igb VMDQ=3,3 QueuePairs=0,0

igb_validate_option: VMDQ - VMDq multiqueue queue count set to 3
igb_validate_option: QueuePairs - Tx/Rx queue pairs for interrupt handling Disabled
...
Using MSI-X interrupts. 3 rx queue(s), 3 tx queue(s)

/proc/interrupts:

  25:          0          0          0          0          0          0   PCI-MSI-edge      eth1
 26:          3          0          0          0          0          0   PCI-MSI-edge      eth1-rx-0
 27:          0          3          0          0          0          0   PCI-MSI-edge      eth1-rx-1
 28:          0          0          3          0          0          0   PCI-MSI-edge      eth1-rx-2
 29:          0          0          0          3          0          0   PCI-MSI-edge      eth1-tx-0
 30:          0          0          0          0          3          0   PCI-MSI-edge      eth1-tx-1
 31:          0          0          0          0          0          3   PCI-MSI-edge      eth1-tx-2
 32:          0          0          0          0          0          0   PCI-MSI-edge      eth2
 33:          3          0          0          0          0          0   PCI-MSI-edge      eth2-rx-0
 34:          0          3          0          0          0          0   PCI-MSI-edge      eth2-rx-1
 35:          0          0          3          0          0          0   PCI-MSI-edge      eth2-rx-2
 36:          0          0          0          3          0          0   PCI-MSI-edge      eth2-tx-0
 37:          0          0          0          0          3          0   PCI-MSI-edge      eth2-tx-1
 38:          0          0          0          0          0          3   PCI-MSI-edge      eth2-tx-2

 

Вопрос, из какой логики нужно исходить выбирая количество очередей и необходимость разделение векторов?

 

3) Как правильно раскидывать прерывания? У меня соображения такие, если вектора совмещенные, то самую загруженную очередь одного интерфейса (нулевую) совмещать с самой свободной (последней) другого. А если вектора разделены, то rx0 одного интерфейса должно обрабатывать тоже ядро, что и tx0 одного интерфейса, т.к. пакет с данными один и тот же (типа вошел с одной стороны, и быстренько, тем же ядром, вышел с другой).

В одном из последних вариантов у меня была следующая конфигурация (что не понравилось, рассказывю в следующем пункте):

 

cpu0: eth1-tx-1/eth2-rx-1/eth1/eth2

cpu1: eth1-rx-1/eth2-tx-1

cpu2: eth1-tx-2/eth2-rx-2

cpu3: eth1-rx-2/eth2-tx-2

cpu4: eth1-tx-0/eth2-rx-0

cpu5: eth1-rx-0/eth2-tx-0

 

Правильно ли я мыслю, или же не так?

 

4) Почему то почти всегда работает только первая очередь на обоих интерфейсах (ну процентов на 80%)! К примеру, берем по три очереди на двух интерфейсах, Присваиваем каждую очередь своему ядру. И при большом трафике видим, что у обоих интерфейсов 0'ые очереди перегружают процессор, ksoftirq этих ядер на 100%!

 

 

Как видно, пятое и шестое ядро на которых висят прерывания нулевых очередей интерфейсов, перегружены. Никак не могу понять, почему трафик не попадает в другие очереди.

Изменено 25 декабря, 2012 пользователем morfair

[Abram]

morfair,

4)

Это у Вас какой-то pptp? Почему не accel?

Насколько я помню, там разграничение по очередям идет по destination ip. Т.е. если к Вам на сервер летит пачка пакетов с одинаковым destination (адрес сервера) - они и попадают в одну очередь.

[morfair]

morfair,

4)

Это у Вас какой-то pptp? Почему не accel?

Насколько я помню, там разграничение по очередям идет по destination ip. Т.е. если к Вам на сервер летит пачка пакетов с одинаковым destination (адрес сервера) - они и попадают в одну очередь.

pptpd стандартный, модуль к ядру accel-pptp. Есть задумки полностью перейти на accel-ppp, но пока не получается. Клиенты VPN, не думаю что все прямо ломятся на один dst-ip... =)

[Abram]

pptpd стандартный, модуль к ядру accel-pptp. Есть задумки полностью перейти на accel-ppp, но пока не получается. Клиенты VPN, не думаю что все прямо ломятся на один dst-ip... =)

Ээээ... Зачем модуль ядра из accel, если pptpd стандартный?

dst ip у всех таки одинаковый - конечный адрес туннеля. Внутри ppp, конечно, разные уже.

[replicant]

6 ядер - 6 комбинированных RxTx очередей и не придумывайте себе головную боль с разделением Rx и Tx на разные ядра.

 

Практика показывает что для задач vpn авторизации с обслуживанием туннелей комбинированные RxTx очереди в кол-ве равном кол-ву ядер - оптимальный вариант, обеспечивающий ровную нагрузку на все процессоры системы.

 

При использовании accel-ppp еще более ровная нагрузка многоядерников достигается, когда число threads = число CPU*2, а не равное числу CPU.

Изменено 25 декабря, 2012 пользователем replicant

[morfair]

pptpd стандартный, модуль к ядру accel-pptp. Есть задумки полностью перейти на accel-ppp, но пока не получается. Клиенты VPN, не думаю что все прямо ломятся на один dst-ip... =)

Ээээ... Зачем модуль ядра из accel, если pptpd стандартный?

dst ip у всех таки одинаковый - конечный адрес туннеля. Внутри ppp, конечно, разные уже.

Без него процессор занимался pptpd и сервер коннектов держал совсем чуть чуть.

 

6 ядер - 6 комбинированных RxTx очередей и не придумывайте себе головную боль с разделением Rx и Tx на разные ядра.

 

Практика показывает что для задач vpn авторизации с обслуживанием туннелей комбинированные RxTx очереди в кол-ве равном кол-ву ядер - оптимальный вариант, обеспечивающий ровную нагрузку на все процессоры системы.

 

При использовании accel-ppp еще более ровная нагрузка многоядерников достигается, когда число threads = число CPU*2, а не равное числу CPU.

Т.е. по три очереди на оба интерфейса? А что за число threads?

[replicant]

Т.е. по три очереди на оба интерфейса?

Да.

[Abram]

Без него процессор занимался pptpd и сервер коннектов держал совсем чуть чуть.

Так, значит, у Вас всё-таки accel, но старый - 0.x?

[morfair]

Без него процессор занимался pptpd и сервер коннектов держал совсем чуть чуть.

Так, значит, у Вас всё-таки accel, но старый - 0.x?

accel-pptp и accel-ppp немного разные вещи. первый - это прсото модуль к ядру (что у нас), а второй - VPN-сервер.

Изменено 25 декабря, 2012 пользователем morfair

[Abram]

accel-pptp и accel-ppp немного разные вещи. первый - это прсото модуль к ядру (что у нас), а второй - VPN-сервер.

Модуль - он модуль. Используется и там, и там.

accel-pptp - это модуль плюс модифицированный poptop.

Обычный poptop (pptpd) о модуле ничего знать не знает.

[morfair]

При использовании accel-ppp еще более ровная нагрузка многоядерников достигается, когда число threads = число CPU*2, а не равное числу CPU.

Как пришли к такому заключению?) Просо интерессно.

[replicant]

Как пришли к такому заключению?) Просо интерессно.

Сравнивал работу 10-ти серверов с четырьмя ядрами в течение нескольких недель. 5 штук были с thread-count=4, а другие 5 с thread-count=8.

 

Суточная, недельная и месячная нагрузка на CPU ровнее на 8-поточных.

 

Типичный 4-х поточник

03:14:32 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
03:14:32 PM  all    0.39    0.00    0.43    0.09    0.01   13.18    0.00    0.00   85.91
03:14:32 PM    0    0.44    0.00    0.34    0.19    0.00   11.74    0.00    0.00   87.28
03:14:32 PM    1    0.26    0.00    0.34    0.08    0.00    9.62    0.00    0.00   89.70
03:14:32 PM    2    0.44    0.00    0.55    0.05    0.02   15.93    0.00    0.00   83.02
03:14:32 PM    3    0.42    0.00    0.50    0.04    0.02   15.87    0.00    0.00   83.16

Типичный 8-ми поточник

03:14:13 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
03:14:13 PM  all    0.51    0.00    0.40    0.08    0.01    8.38    0.00    0.00   90.62
03:14:13 PM    0    0.42    0.00    0.32    0.17    0.00    7.93    0.00    0.00   91.16
03:14:13 PM    1    0.32    0.00    0.31    0.11    0.00    7.08    0.00    0.00   92.18
03:14:13 PM    2    0.66    0.00    0.51    0.02    0.02    9.44    0.00    0.00   89.35
03:14:13 PM    3    0.66    0.00    0.49    0.01    0.02    9.19    0.00    0.00   89.64

 

Чтобы все было чисто и быстро системы я просто клонирую с одного образа, изменяя только IP, пароли и прочие мелочи. Железо одинаковое унифицированное. Отличия могут быть лишь в моделях жестких дисков и частоте CPU +- 200 МHz

 

Картинка в течение часа-пик в колебаниях нагрузки на CPU тоже ровнее на 8-поточном. Получается на 15-20% ровнее относительно максимума нагрузки у 8-ми поточного accel в час-пик. Посуточная картинка слегка размывается, но все же есть некоторые отличия.

 

На самом деле добиться идеально ровной нагрузки всех ядер все равно невозможно, но если применить решение с объединением двух eth в bond, то картинка выравнивается лучше, хотя колебания в пределах процентов тоже не напрягают.

 

По крайней мере решение thread-count=8 нисколько не конфликтует с работой 4хCPU и в пиковые часы все спокойно ровно живет на 4-х ядрах.

Изменено 26 декабря, 2012 пользователем replicant

[MagMike]

При использовании accel-ppp еще более ровная нагрузка многоядерников достигается, когда число threads = число CPU*2, а не равное числу CPU.

Подскажите, пожалуйста, что за threads (thread-count), где он указывается?

 

Про свой опыт пару слов - тоже давно перешли на карточки 82576 с поддержкой нескольких очередей.

сейчас очереди прибиты к прерываниям вот так:

           CPU0       CPU1       CPU2       CPU3
46: 3581613138          0          0          0   PCI-MSI-edge      eth0-rx-0
47:        109 2573456209          0          0   PCI-MSI-edge      eth0-rx-1
48:        162          0 1394890268          0   PCI-MSI-edge      eth0-rx-2
49:        136          0          0 2134582450   PCI-MSI-edge      eth0-rx-3
50: 3193232606          0          0          0   PCI-MSI-edge      eth0-tx-0
51:        104  633196949          0          0   PCI-MSI-edge      eth0-tx-1
52:          9          0  617772211          0   PCI-MSI-edge      eth0-tx-2
53:         11          0          0  121056255   PCI-MSI-edge      eth0-tx-3
54:          1          0          0          0   PCI-MSI-edge      eth1
55:        720          0          0 3709059855   PCI-MSI-edge      eth1-rx-0
56:        677          0 3702096882          0   PCI-MSI-edge      eth1-rx-1
57:         12 4179129594          0          0   PCI-MSI-edge      eth1-rx-2
58: 3544596594          0          0          0   PCI-MSI-edge      eth1-rx-3
59:         21          0          0  973378788   PCI-MSI-edge      eth1-tx-0
60:       1404          0 4002659628          0   PCI-MSI-edge      eth1-tx-1
61:         12 2505447020          0          0   PCI-MSI-edge      eth1-tx-2
62: 2190790729          0          0          0   PCI-MSI-edge      eth1-tx-3

 

Но при высокой нагрузке все равно мог начать расти softirq на одном процессоре, обработка застревала на нем, softirq выростал до 100%, а загрузка на других оставалась низкой.

Значительно помог RPS (receive packet steering). он доступен, правда, только начиная с 2.6.35.

[replicant]

Но при высокой нагрузке все равно мог начать расти softirq на одном процессоре, обработка застревала на нем, softirq выростал до 100%, а загрузка на других оставалась низкой.

Значительно помог RPS (receive packet steering). он доступен, правда, только начиная с 2.6.35.

Потому что не надо делать по 4 очереди на одном CPU. Ядра 3.2.х в плане работы под адовой нагрузкой с выпадением ksoftirq ведут себя лучше. Быстро разгребают завал и выравниваются по показателям, но правила придерживаюсь одна гибридная очередь на одно ядро.

[MagMike]

Потому что не надо делать по 4 очереди на одном CPU.

Как закрепить 16 очередей на 4 процессора?

 

И, пожалуйста, подскажите, что за threads (thread-count), где он указывается?

[morfair]

В общем, на данном этаме остановился данной конфигурации.

 

ethtool -i eth1
driver: igb
version: 4.0.17
firmware-version: 1.1, 0xc8220000
bus-info: 0000:02:00.0

 

Модуль igb инициализирую со следующими параметрами:

 

/etc/modprobe.d/igb.conf:

alias eth1 igb
alias eth2 igb
options igb InterruptThrottleRate=3,3 RSS=3,3 QueuePairs=1,1

 

В предыдущщий раз моя ошибка видимо была в том, что я очереди задавал параметром VMDQ, который, как я понял, очереди то сделал, но рулить их не рулил. А вот параметр RSS всё сделал правильно, аргумент указывает на количество очередей на интерфейс. Т.к. интерфейса два, а ядер шесть, то конфигурация 3,3 сделал по три очереди на интерфейс. В сумме шесть рабочих очередей на шесть ядер процессора. Вектора делал совместные, как советовал replicant, что указал опцией QueuePairs (в начале темы выкладывал ссылку на ман с описанием). InterruptThrottleRate в принципе дефолтный, который, как я понял, ставит тролинг порядка 20000, а при объемном трафике в 8000 (или 4000). М.б. я заблуждаюсь, но не вникал досконально.

 

Прерывания:

  25:          0          0          0          0          0          1   PCI-MSI-edge      eth1
 26:          2          0          0          2  555087807          0   PCI-MSI-edge      eth1-TxRx-0
 27:          2          0  279266455          0          2          0   PCI-MSI-edge      eth1-TxRx-1
 28:  275921969          0          0          0          0          2   PCI-MSI-edge      eth1-TxRx-2
 29:          0          0          0          0          0          1   PCI-MSI-edge      eth2
 30:          1          0          0          2          0  516234457   PCI-MSI-edge      eth2-TxRx-0
 31:          1          0          0  408135285          2          0   PCI-MSI-edge      eth2-TxRx-1
 32:          1  354715245          0          0          0          2   PCI-MSI-edge      eth2-TxRx-2

 

Буфера на интерфейсах минимальны, т.к. процца хватает, а мелкий пинг дорог:

# ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX:		4096
RX Mini:	0
RX Jumbo:	0
TX:		4096
Current hardware settings:
RX:		256
RX Mini:	0
RX Jumbo:	0
TX:		256

 

Собрал accel-ppp из git'а, линейка 1.7, версия 98466f59d258d2079755d2a1808cd34631d9f230 (вечер 25 дек 2012 г.), thread-count=12

 

Было около 1250 pptp-сессий, трафик ~300 Mbits/sec, ~60 kpackets/sec на интерфейсе, смотрящщем к клиентам. Лагов не замечено, load average около 2,5.

 

Потому что не надо делать по 4 очереди на одном CPU.

Как закрепить 16 очередей на 4 процессора?

 

И, пожалуйста, подскажите, что за threads (thread-count), где он указывается?

Что сделать с очередями только написал, а thread-count - это опция accel-ppp.

Изменено 26 декабря, 2012 пользователем morfair

[MagMike]

Что сделать с очередями прочитайте в моем предыдущем посте, а thread-count - это опция accel-ppp.

А, теперь понятно. По-видимому, это в 1-й ветке. У меня же - 0.8.5. Пл

Поэтому у себя нигде не нашел.

Количество очередей, наверное, тоже в интеловом драйвере можно указать? У меня родное из исходников ядра.

[morfair]

Что сделать с очередями прочитайте в моем предыдущем посте, а thread-count - это опция accel-ppp.

А, теперь понятно. По-видимому, это в 1-й ветке. У меня же - 0.8.5. Пл

Поэтому у себя нигде не нашел.

Количество очередей, наверное, тоже в интеловом драйвере можно указать? У меня родное из исходников ядра.

thread-count ока в accel-ppp, к accel-pptp он никакого отношения не имеет. К родному модулю думаю эти опции так же пойдут. Попробуйте загрузить его с этими параметрами.

[MagMike]

Ок. Спасибо!

[mrsaygo]

Наконец то нашел полезную тему (правда уже поспешил создать другую).

Хочу попросить совета для таких задач:

 

Около 800 чел. за натом и 400 с реальными адресами.

(BGP quagga временно потушили, но будет, шейпер на tc тоже - ибо прыгает пинг)

lighttpd+php-fastcgi dhcp-server

 

iptables 50-80 правил (около того) ибо есть ipset

Ubuntu 12.04 x64 3.5.0-23-generic

 

2 процессора Intel® Xeon® CPU E5-2640 0 @ 2.50GHz по 6 ядер

 

На входе Intel Corporation 82599EB 10-Gigabit SFI/SFP+

На 3 выхода на которых Nat + alias (для real IP)

1-й Intel Corporation 82599EB 10-Gigabit SFI/SFP+ (самая крупная подсеть) (10.0....)

2-й Intel Corporation I350 Gigabit (172.16...)

3-й Intel Corporation I350 Gigabit (192.168....)

 

Дрова последние от Интела.

Трафика 1.5Гб на CPU0 si лезет в 99%

Все модули грузятся по дефолту.

 

Как следует раскидать прерывания в этом случае? Hyper Threading выключили, может есть смысл включить?

[mrsaygo]

До чего додумал - у меня 350 интела грузятся по дефолту с 1-й гибридной очередью

 

может есть смысл загрузить ixgbe с

options ixigbe InterruptThrottleRate=8,8 RSS=8,8 QueuePairs=1,1

а igb с

options igb InterruptThrottleRate=4,4 RSS=4,4 QueuePairs=1,1

включить Hyper Threading

 

получим 24 гибридных очереди на 24 логических ядра (2 проца по 6 ядер + Hyper Threading)

 

Поправьте если что не так пожалуйста.

[Zaqwr]

Hyper Threading в данном случае зло, прироста не получите, одни проблемы и удивлнеие, при загрузке системы в 50% начнёте удивляться(реально это будет 100%, но вы это увидете отключив HT)