morfair Опубликовано 24 декабря, 2012 (изменено) · Жалоба Прочитал несколько тем на сим форуме, касаемо высокой нагрузке 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 24 декабря, 2012 · Жалоба morfair, 4) Это у Вас какой-то pptp? Почему не accel? Насколько я помню, там разграничение по очередям идет по destination ip. Т.е. если к Вам на сервер летит пачка пакетов с одинаковым destination (адрес сервера) - они и попадают в одну очередь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 24 декабря, 2012 · Жалоба morfair, 4) Это у Вас какой-то pptp? Почему не accel? Насколько я помню, там разграничение по очередям идет по destination ip. Т.е. если к Вам на сервер летит пачка пакетов с одинаковым destination (адрес сервера) - они и попадают в одну очередь. pptpd стандартный, модуль к ядру accel-pptp. Есть задумки полностью перейти на accel-ppp, но пока не получается. Клиенты VPN, не думаю что все прямо ломятся на один dst-ip... =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 25 декабря, 2012 · Жалоба pptpd стандартный, модуль к ядру accel-pptp. Есть задумки полностью перейти на accel-ppp, но пока не получается. Клиенты VPN, не думаю что все прямо ломятся на один dst-ip... =) Ээээ... Зачем модуль ядра из accel, если pptpd стандартный? dst ip у всех таки одинаковый - конечный адрес туннеля. Внутри ppp, конечно, разные уже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 25 декабря, 2012 (изменено) · Жалоба 6 ядер - 6 комбинированных RxTx очередей и не придумывайте себе головную боль с разделением Rx и Tx на разные ядра. Практика показывает что для задач vpn авторизации с обслуживанием туннелей комбинированные RxTx очереди в кол-ве равном кол-ву ядер - оптимальный вариант, обеспечивающий ровную нагрузку на все процессоры системы. При использовании accel-ppp еще более ровная нагрузка многоядерников достигается, когда число threads = число CPU*2, а не равное числу CPU. Изменено 25 декабря, 2012 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 25 декабря, 2012 · Жалоба 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 25 декабря, 2012 · Жалоба Т.е. по три очереди на оба интерфейса? Да. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 25 декабря, 2012 · Жалоба Без него процессор занимался pptpd и сервер коннектов держал совсем чуть чуть. Так, значит, у Вас всё-таки accel, но старый - 0.x? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 25 декабря, 2012 (изменено) · Жалоба Без него процессор занимался pptpd и сервер коннектов держал совсем чуть чуть. Так, значит, у Вас всё-таки accel, но старый - 0.x? accel-pptp и accel-ppp немного разные вещи. первый - это прсото модуль к ядру (что у нас), а второй - VPN-сервер. Изменено 25 декабря, 2012 пользователем morfair Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 25 декабря, 2012 · Жалоба accel-pptp и accel-ppp немного разные вещи. первый - это прсото модуль к ядру (что у нас), а второй - VPN-сервер. Модуль - он модуль. Используется и там, и там. accel-pptp - это модуль плюс модифицированный poptop. Обычный poptop (pptpd) о модуле ничего знать не знает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 26 декабря, 2012 · Жалоба При использовании accel-ppp еще более ровная нагрузка многоядерников достигается, когда число threads = число CPU*2, а не равное числу CPU. Как пришли к такому заключению?) Просо интерессно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 26 декабря, 2012 (изменено) · Жалоба Как пришли к такому заключению?) Просо интерессно. Сравнивал работу 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 26 декабря, 2012 · Жалоба При использовании 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 26 декабря, 2012 · Жалоба Но при высокой нагрузке все равно мог начать расти softirq на одном процессоре, обработка застревала на нем, softirq выростал до 100%, а загрузка на других оставалась низкой. Значительно помог RPS (receive packet steering). он доступен, правда, только начиная с 2.6.35. Потому что не надо делать по 4 очереди на одном CPU. Ядра 3.2.х в плане работы под адовой нагрузкой с выпадением ksoftirq ведут себя лучше. Быстро разгребают завал и выравниваются по показателям, но правила придерживаюсь одна гибридная очередь на одно ядро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 26 декабря, 2012 · Жалоба Потому что не надо делать по 4 очереди на одном CPU. Как закрепить 16 очередей на 4 процессора? И, пожалуйста, подскажите, что за threads (thread-count), где он указывается? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 26 декабря, 2012 (изменено) · Жалоба В общем, на данном этаме остановился данной конфигурации. 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 26 декабря, 2012 · Жалоба Что сделать с очередями прочитайте в моем предыдущем посте, а thread-count - это опция accel-ppp. А, теперь понятно. По-видимому, это в 1-й ветке. У меня же - 0.8.5. Пл Поэтому у себя нигде не нашел. Количество очередей, наверное, тоже в интеловом драйвере можно указать? У меня родное из исходников ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 26 декабря, 2012 · Жалоба Что сделать с очередями прочитайте в моем предыдущем посте, а thread-count - это опция accel-ppp. А, теперь понятно. По-видимому, это в 1-й ветке. У меня же - 0.8.5. Пл Поэтому у себя нигде не нашел. Количество очередей, наверное, тоже в интеловом драйвере можно указать? У меня родное из исходников ядра. thread-count ока в accel-ppp, к accel-pptp он никакого отношения не имеет. К родному модулю думаю эти опции так же пойдут. Попробуйте загрузить его с этими параметрами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 26 декабря, 2012 · Жалоба Ок. Спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 5 апреля, 2013 · Жалоба Наконец то нашел полезную тему (правда уже поспешил создать другую). Хочу попросить совета для таких задач: Около 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 выключили, может есть смысл включить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 5 апреля, 2013 · Жалоба До чего додумал - у меня 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) Поправьте если что не так пожалуйста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zaqwr Опубликовано 19 июля, 2013 · Жалоба Hyper Threading в данном случае зло, прироста не получите, одни проблемы и удивлнеие, при загрузке системы в 50% начнёте удивляться(реально это будет 100%, но вы это увидете отключив HT) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...