Перейти к содержимому
Калькуляторы

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

Есть 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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й быть их вообще не должно.

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем ttttt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

 

 

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

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

 

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем ttttt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

tsc

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.