NiTr0 Опубликовано 16 июня, 2015 · Жалоба Забавно, что некоторые люди на полном серьезе считают центос энтерпрайзом, рассуждая при этом о некой высшей сути :) Не понимая при этом, что LTS дистр с отдельными свежими компонентами из сторонних репо банально удобнее и безгеморройнее по сравнению с rolling-release дистрами и дистрами с коротким временем поддержки. Особенно позабавил перл про ядро из федоры в elrepo... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 17 июня, 2015 · Жалоба Особенно позабавил перл про ядро из федоры в elrepo... Чем забавен? Тем что в вашем мире не укладывается что ядро это важная часть системы? Ну я знаю что у потребителей Визина свои взгляды на стабильность и мироустройство, но зачем это нам, нормальным людям? :) Я не сказал что центос энтерпрайз продукт, о вашем непонимании разности продукта и решения я уже не раз намекал. Но линукс-админам свойственно неглубоко копать, я это знал и все равно ввязался в спор! Ай-вэй, не буду больше кормить тролля :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 июня, 2015 · Жалоба Чем забавен? Тем что в вашем мире не укладывается что ядро это важная часть системы? Тем, что ядро из elrepo никакого отношения к федоре не имеет. И уж тем более не превращает весь дистрибутив в федору. Я не сказал что центос энтерпрайз продукт Тогда к чему это все газирование луж про Ынтерпрайз здесь? Или вас просто задело, что в стабильном дистрибутиве с поддержкой в 5+ лет, который не ломается от апдейтов, можно легко и непринужденно поиметь свежее актуальное ядро, а ваша БСД так не умеет? Другого объяснения вашим попыткам прикопаться к столбу я не вижу... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 29 июня, 2015 · Жалоба А так хорошо всё начиналось на первой странице темы, но почему-то обсуждение проблемы превратилось в бессмысленный спор. Тем не менее проблема осталась. Собственно у меня проблема такая же как и у автора темы. Есть 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 29 июня, 2015 · Жалоба Ну наблюдается перекос и пусть себе наблюдается, а проблема-то какая? Пакеты ведь не дропаются, правда? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 30 июня, 2015 · Жалоба Ну наблюдается перекос и пусть себе наблюдается, а проблема-то какая? Пакеты ведь не дропаются, правда? Боюсь что в моём случае на это не получится закрыть глаза. При трафике всего в 1.6G одно ядро 100% остальные 7 примерно 15%. А трафик должен быть в итоге до 10G. Естественно при достижении 100% начинаются проблемы с передачей пакетов. Ранее стояли карты E1G44ET2 Gigabit ET Quad Port (объединённые в bond). C ними всё было просто идеально. Возможно потому что одна физическая карта была привязана к одному ядру Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 30 июня, 2015 · Жалоба А версии драйверов пробовали менять? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 30 июня, 2015 · Жалоба Боюсь что в моём случае на это не получится закрыть глаза. Ну если сильно хочется повозиться, то начните изучать с этого: 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/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 30 июня, 2015 · Жалоба Спасибо попробую по результатам отпишу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 1 июля, 2015 · Жалоба Если я всё правильно понял из любезно подкинутых ссылок. 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й быть их вообще не должно. Подскажите как заставить сию карту работать. Неужели ни у кого не возникало подобных проблем с данными картами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 1 июля, 2015 · Жалоба Так, ну начнем с самого главного - опишите какой трафик ходит через сетевую, какие интерфейсы на сервере, топологию сети и роль сервера в ней. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 1 июля, 2015 (изменено) · Жалоба Можно попробовать уйти от аппаратного RSS, т.е. отключить multiqueue и включить вместо него софтовый RPS. Если с загрузкой станет лучше, то хоть будет ясно, что проблему искать в карте/драйверах. Изменено 1 июля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 1 июля, 2015 · Жалоба Или в трафике. Ведь если данные гоняются от одного IP/port к другому, то RSS тут особо не спасет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 1 июля, 2015 · Жалоба Так, ну начнем с самого главного - опишите какой трафик ходит через сетевую, какие интерфейсы на сервере, топологию сети и роль сервера в ней. Сервера в итоге должны работать в паре один станет шейпером, другой NATом. На данном этапе ни шейпинга ни NATа нет просто стоят друг за другом перекладывая пакеты с одного интерфейса на другой. В каждом сервере стоит по одной двухголовой 10G карте. Vlanов тоже пока нет. L3коммутатор---->сервер1--->сервер2---L2 ... Интернет Для тестирования пускаем через них часть клиентского трафика. Под клиентами понимаются обычные пользователи Интернет (серфинг, торрент и тп). Можно попробовать уйти от аппаратного RSS, т.е. отключить multiqueue и включить вместо него софтовый RPS. Если с загрузкой станет лучше, то хоть будет ясно, что проблему искать в карте/драйверах. Ранее пробовал так делать только при этом не выключал RSS. Результатом было то, что нагрузка на всех (в варианте чистого RSS) малонагруженных ядер просто подтягивалась до уровня самого загруженного. т.ё. толку особо небыло хоть и ровно всё становилось. Завтра попробую чистый RPS без RSS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 1 июля, 2015 · Жалоба А может клиентов тестовых просто мало? Оно ж "per ip" размазывает, если там 3-4 клиента то так и будет, в пару потоков криво разложит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 1 июля, 2015 · Жалоба А может клиентов тестовых просто мало? Оно ж "per ip" размазывает, если там 3-4 клиента то так и будет, в пару потоков криво разложит. нет там реальный трафик порядка 1000 абонентов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 1 июля, 2015 (изменено) · Жалоба В даташите на 82599 интел говорит, что в нулевую очередь ложится все, что не смогли распарсить. Выбор из таблицы по хэшу происходит только для того трафика, который смогли распарсить (TCP, UDP и нераспознанного IP, каждую функцию драйвер должен отдельно включать). Для IP это хэш из dst и src адресов, для TCP и UDP туда еще порты добавляются. Туннели парсятся как IP трафик. Может быть дело и в трафике. Изменено 1 июля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 3 июля, 2015 · Жалоба Комрады, хотел бы параллельно повторить вопрос заданный выше: Кто-то реально использует карты X520-DA2 (E10G42BTDA) для маршрутизации, шейпинга, ната обычного клиентского трафика (разные src и dst адреса)? Если да, то какая конфигурация серверов (CPU, память)? Какое ядро, какой драйвер? Какой трафик в пике проходит? Какая загрузка по ядрам? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 3 июля, 2015 · Жалоба Интересует именно интеловская карта или аналог от супермикро подойдёт? 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) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 3 июля, 2015 · Жалоба Это не аналог - это тот же чип =) Не важно кто собрал железку, главное что за чип внутри, а чип именно тот, что нужно - 82599. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 3 июля, 2015 · Жалоба Буквами в конце отличаются, там EN, а у меня ES. Я подумал, может это важно. Если lacost интересно, приведу свои данные. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 3 июля, 2015 · Жалоба Провел несколько тестов Все тесты проводил с включённым шейпереом 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 я уже не знаю куда смотреть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 3 июля, 2015 · Жалоба Как и в варианте 1 при достижении порога в 1.6G скачкообразно повышается загрузка ЦП до 100% clocksource hpet все так же юзаете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 3 июля, 2015 · Жалоба Как и в варианте 1 при достижении порога в 1.6G скачкообразно повышается загрузка ЦП до 100% clocksource hpet все так же юзаете? cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc А что порекомендуете почитать по данному вопросу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 3 июля, 2015 · Жалоба В таком варианте удалось прогнать 2.2G (больше не было), но что то говорит мне что 10G сервер не вытянет. т.к. загрузка ядер становится всё более неравномерной с ростом трафика и увеличивается нелинейно. А какая загрузка ядер была при таком трафике? Может покажите, что там профайлер говорит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...