Jump to content
Калькуляторы

Распределение нагрузки по ядрам в Debian Jessie Лезем вглубь! Интересный и развернутый спич

Забавно, что некоторые люди на полном серьезе считают центос энтерпрайзом, рассуждая при этом о некой высшей сути :) Не понимая при этом, что LTS дистр с отдельными свежими компонентами из сторонних репо банально удобнее и безгеморройнее по сравнению с rolling-release дистрами и дистрами с коротким временем поддержки.

 

Особенно позабавил перл про ядро из федоры в elrepo...

Share this post


Link to post
Share on other sites

Особенно позабавил перл про ядро из федоры в elrepo...

 

Чем забавен? Тем что в вашем мире не укладывается что ядро это важная часть системы? Ну я знаю что у потребителей Визина свои взгляды на стабильность и мироустройство, но зачем это нам, нормальным людям? :)

 

Я не сказал что центос энтерпрайз продукт, о вашем непонимании разности продукта и решения я уже не раз намекал. Но линукс-админам свойственно неглубоко копать, я это знал и все равно ввязался в спор! Ай-вэй, не буду больше кормить тролля :)

Share this post


Link to post
Share on other sites

Чем забавен? Тем что в вашем мире не укладывается что ядро это важная часть системы?

Тем, что ядро из elrepo никакого отношения к федоре не имеет. И уж тем более не превращает весь дистрибутив в федору.

 

Я не сказал что центос энтерпрайз продукт

Тогда к чему это все газирование луж про Ынтерпрайз здесь?

 

Или вас просто задело, что в стабильном дистрибутиве с поддержкой в 5+ лет, который не ломается от апдейтов, можно легко и непринужденно поиметь свежее актуальное ядро, а ваша БСД так не умеет? Другого объяснения вашим попыткам прикопаться к столбу я не вижу...

Share this post


Link to post
Share on other sites

А так хорошо всё начиналось на первой странице темы, но почему-то обсуждение проблемы превратилось в бессмысленный спор.

 

Тем не менее проблема осталась. Собственно у меня проблема такая же как и у автора темы.

 

Есть 2 сервера соединённые через 10G карты (2xSFP+, PCI-E x8 [E10G42BTDA])

На обоих серверах стоит Debian8 (пробовал и 7) и последние версии драйверов.

На этих интерфейсах нет ни NATа ни Шейпинга

И на обоих одинаковая проблема.

 

Как и у автора темы наблюдается сильный перекос загрузки по ядрам. Вызвано это неравномерным распределением пакетов по очередям карты

Настройки драйвера и привязки прерываний схожи с теми что привёл автор темы.

все рецепты которые были изложены выше не помогают.

 

 

ethtool -S eth3 | grep .x_queue_._packets
    tx_queue_0_packets: 277314
    tx_queue_1_packets: 1974
    tx_queue_2_packets: 109
    tx_queue_3_packets: 387
    tx_queue_4_packets: 0
    tx_queue_5_packets: 0
    tx_queue_6_packets: 0
    tx_queue_7_packets: 0
    tx_queue_8_packets: 0
    tx_queue_9_packets: 0
    rx_queue_0_packets: 161788
    rx_queue_1_packets: 98392
    rx_queue_2_packets: 71950
    rx_queue_3_packets: 76285
    rx_queue_4_packets: 0
    rx_queue_5_packets: 0
    rx_queue_6_packets: 0
    rx_queue_7_packets: 0
    rx_queue_8_packets: 0
    rx_queue_9_packets: 0

Share this post


Link to post
Share on other sites

Ну наблюдается перекос и пусть себе наблюдается, а проблема-то какая? Пакеты ведь не дропаются, правда?

Share this post


Link to post
Share on other sites

Ну наблюдается перекос и пусть себе наблюдается, а проблема-то какая? Пакеты ведь не дропаются, правда?

 

Боюсь что в моём случае на это не получится закрыть глаза.

При трафике всего в 1.6G одно ядро 100% остальные 7 примерно 15%.

А трафик должен быть в итоге до 10G.

Естественно при достижении 100% начинаются проблемы с передачей пакетов.

 

Ранее стояли карты E1G44ET2 Gigabit ET Quad Port (объединённые в bond). C ними всё было просто идеально.

Возможно потому что одна физическая карта была привязана к одному ядру

Share this post


Link to post
Share on other sites

Боюсь что в моём случае на это не получится закрыть глаза.

Ну если сильно хочется повозиться, то начните изучать с этого:

https://www.kernel.org/doc/Documentation/networking/scaling.txt

 

и сразу линк на патч для ixgbe, чтобы рулить indirection table с помощью ethtool

https://github.com/majek/ixgbe/commit/336d556cbada2974700f4d809b54ce472d11709d

 

Вот еще как раз статья близко к теме. Тут, например, сказано, что для 82599 надо отключить ntuple чтобы Flow Director (ARFS) заработал:

https://blog.cloudflare.com/how-to-achieve-low-latency/

Share this post


Link to post
Share on other sites

Спасибо попробую по результатам отпишу

Share this post


Link to post
Share on other sites

Если я всё правильно понял из любезно подкинутых ссылок.

RSS - аппаратная возможность карты создавать несколько очередей у каждой из которой своё прерывание.

Пакеты попадают в очередь пройдя через хеш фильтр который классифицирует пакеты по заголовкам.

Размер хеша = 128 и к каждой его ячейке привязана конкретная очередь, а очередь через прерывание к ядру процессора.

 

пропатчил дрова - возник небольшой затык с

/usr/src/linux-headers-3.16.0-4-common/include/linux/ethtool.h пришлось добавить туда

int (*get_rxfh_indir)(struct net_device *netdev, u32 *indir);

int (*set_rxfh_indir)(struct net_device *netdev, const u32 *indir);

без этого не собиралось

 

После обновления в ethtool появилась возможность смотреть и править indirection table

по умолчанию было вот так

ethtool -x eth3 
RX flow hash indirection table for eth3 with 4 RX ring(s):
   0:      0     1     2     3     0     1     2     3
   8:      0     1     2     3     0     1     2     3
  16:      0     1     2     3     0     1     2     3
  24:      0     1     2     3     0     1     2     3
  32:      0     1     2     3     0     1     2     3
  40:      0     1     2     3     0     1     2     3
  48:      0     1     2     3     0     1     2     3
  56:      0     1     2     3     0     1     2     3
  64:      0     1     2     3     0     1     2     3
  72:      0     1     2     3     0     1     2     3
  80:      0     1     2     3     0     1     2     3
  88:      0     1     2     3     0     1     2     3
  96:      0     1     2     3     0     1     2     3
 104:      0     1     2     3     0     1     2     3
 112:      0     1     2     3     0     1     2     3
 120:      0     1     2     3     0     1     2     3

 

Начал экспериментировать в итоге выяснилось что, вне зависимости от настроек indirection table

пакеты остальных очередей всё равно проходят через rx_queue_0_packets это видно из показаний ethtool -S eth3

 

Даже если сказать ethtool --set-rxfh-indir eth3 weight 0 0 0 1

то всё равно в 0й очереди будет в 2 раза больше пакетов чем в 3й. Хотя в 0й быть их вообще не должно.

 

 

Подскажите как заставить сию карту работать. Неужели ни у кого не возникало подобных проблем с данными картами.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Можно попробовать уйти от аппаратного RSS, т.е. отключить multiqueue и включить вместо него софтовый RPS. Если с загрузкой станет лучше, то хоть будет ясно, что проблему искать в карте/драйверах.

Edited by ttttt

Share this post


Link to post
Share on other sites

Или в трафике. Ведь если данные гоняются от одного IP/port к другому, то RSS тут особо не спасет.

Share this post


Link to post
Share on other sites

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

 

Сервера в итоге должны работать в паре один станет шейпером, другой NATом.

На данном этапе ни шейпинга ни NATа нет просто стоят друг за другом перекладывая пакеты с одного интерфейса на другой.

В каждом сервере стоит по одной двухголовой 10G карте. Vlanов тоже пока нет.

 

L3коммутатор---->сервер1--->сервер2---L2 ... Интернет

 

 

Для тестирования пускаем через них часть клиентского трафика.

Под клиентами понимаются обычные пользователи Интернет (серфинг, торрент и тп).

 

 

Можно попробовать уйти от аппаратного RSS, т.е. отключить multiqueue и включить вместо него софтовый RPS. Если с загрузкой станет лучше, то хоть будет ясно, что проблему искать в карте/драйверах.

Ранее пробовал так делать только при этом не выключал RSS. Результатом было то, что нагрузка на всех (в варианте чистого RSS) малонагруженных ядер просто подтягивалась до уровня самого загруженного. т.ё. толку особо небыло хоть и ровно всё становилось.

 

Завтра попробую чистый RPS без RSS

Share this post


Link to post
Share on other sites

А может клиентов тестовых просто мало? Оно ж "per ip" размазывает, если там 3-4 клиента то так и будет, в пару потоков криво разложит.

Share this post


Link to post
Share on other sites

А может клиентов тестовых просто мало? Оно ж "per ip" размазывает, если там 3-4 клиента то так и будет, в пару потоков криво разложит.

нет там реальный трафик порядка 1000 абонентов

Share this post


Link to post
Share on other sites

В даташите на 82599 интел говорит, что в нулевую очередь ложится все, что не смогли распарсить. Выбор из таблицы по хэшу происходит только для того трафика, который смогли распарсить (TCP, UDP и нераспознанного IP, каждую функцию драйвер должен отдельно включать). Для IP это хэш из dst и src адресов, для TCP и UDP туда еще порты добавляются. Туннели парсятся как IP трафик.

 

Может быть дело и в трафике.

Edited by ttttt

Share this post


Link to post
Share on other sites

Комрады, хотел бы параллельно повторить вопрос заданный выше:

Кто-то реально использует карты X520-DA2 (E10G42BTDA) для маршрутизации, шейпинга, ната обычного клиентского трафика (разные src и dst адреса)?

Если да, то какая конфигурация серверов (CPU, память)?

Какое ядро, какой драйвер?

Какой трафик в пике проходит? Какая загрузка по ядрам?

Share this post


Link to post
Share on other sites

Интересует именно интеловская карта или аналог от супермикро подойдёт?

83:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
83:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

Share this post


Link to post
Share on other sites

Это не аналог - это тот же чип =) Не важно кто собрал железку, главное что за чип внутри, а чип именно тот, что нужно - 82599.

Share this post


Link to post
Share on other sites

Буквами в конце отличаются, там EN, а у меня ES. Я подумал, может это важно. Если lacost интересно, приведу свои данные.

Share this post


Link to post
Share on other sites

Провел несколько тестов

Все тесты проводил с включённым шейпереом

 

1) только RSS

Результат не радует. в одну из очередей, причём как выяснилось не обязательно нулевую, прёт на порядок больше пакетов.

Манипуляции с ethtool --set-rxfh-indir eth2 weight 0 0 0 1 не помогают.

По непонятным причинам при достижении трафиком уровня в 1.6G скачкообразно повышается загрузка ЦП до 100%

 

2) только RPS

В принципе результат RPS лучше чем RSS, но есть ряд трудностей.

Например если сделать для нашей единственной очереди

echo ff >/sys/class/net/eth3/queues/rx-0/rps_cpus

то может возникает дисбаланс на одном из ядер. Результат лучше если не использовать это ядро.

В таком варианте удалось прогнать 2.2G (больше не было), но что то говорит мне что 10G сервер не вытянет. т.к. загрузка ядер становится всё более неравномерной с ростом трафика и увеличивается нелинейно.

 

3) RSS + RPS

Сделал 4 очереди для RSS и прибил их к ядрам, затем найдя перегруженную очередь сделал для не

echo ff >/sys/class/net/eth3/queues/rx-1/rps_cpus

В результате баланс загрузки ядер выровнялся. Что лучше вар 2 или 3 сказать не берусь.

Как и в варианте 1 при достижении порога в 1.6G скачкообразно повышается загрузка ЦП до 100%

такое ощущение что переполняется какой то буфер, но что крутить не знаю

 

Может кто подскажет как оптимизировать работу 10G карты для шейпинга и NATa

я уже не знаю куда смотреть.

Share this post


Link to post
Share on other sites

Как и в варианте 1 при достижении порога в 1.6G скачкообразно повышается загрузка ЦП до 100%

clocksource hpet все так же юзаете?

Share this post


Link to post
Share on other sites

Как и в варианте 1 при достижении порога в 1.6G скачкообразно повышается загрузка ЦП до 100%

clocksource hpet все так же юзаете?

 

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

tsc

 

А что порекомендуете почитать по данному вопросу

Share this post


Link to post
Share on other sites

В таком варианте удалось прогнать 2.2G (больше не было), но что то говорит мне что 10G сервер не вытянет. т.к. загрузка ядер становится всё более неравномерной с ростом трафика и увеличивается нелинейно.

А какая загрузка ядер была при таком трафике? Может покажите, что там профайлер говорит?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this