x86 Dual-Socket,MultiCore,Static IRQ balance

[Alex S. B.]

Имеем мать Intel s2600 + 2CPU XEON 

2NIC 82599 4-port  #1 и  #2

Три аплинка включены все в одну карту #1 каждый в своем порту и своем vlan

Три даунлинка в сторону pppoe серверов. Каждый сервер на своем vlan.

Трафика на аплинках по 5-6Г.

Сделана раскидка irq очередей карт по ядрам cpu, подобраны буфера карт, минимум правил фаервола и т.д.

Задача 3FW BGP + raw fw 30-40 правил

 

 

По сути имеем три порта с большим RX и три с большим TX

Вопрос, вернее мольба к коллегам))

Все работает прекрасно если всем сетевым картам(потокам на них) распределены ядра одного сокета(CPU\NUMA) 

все, все шесть портов! 

НО! Как только мы пытаемся перекинуть порты с большим TX ,выше чем 2-3Г на ядра другого сокета - получаем лютую просадку и деградацию трафика всей системы в целом! 

 

Понимаем что это происходит изза перекидки пакетов между сокетами(физическими CPU) но как побороть? и можно ли на routerOS?

Как вариант#1 протестировать на CHR+pci pass, дабы дать ему все ядра и раскидкой по CPU\NUMA пусть займется гипервизор?

Вариант#2 - перейти на linux\bsd с большими возможностями тюнинга стека.

Вариант#3 - перейти на циско\джун ,доширак и жить с одной почкой ))) 

 

В чем боль? где узкое место? Intel UPI? ядро linux? ROS? 

Сталкивался кто с двухкаменными системами и трафиком 15-20Г TX\RX ?

 

Edited January 21, 2021 by Alex S. B.

[Saab95]

Надо поставить еще один сетевой адаптер и разделить потоки, что бы одну сетевушку обслуживал первый процессор, вторую второй.

[jffulcrum]

16 часов назад, Alex S. B. сказал:

Имеем мать Intel s2600 + 2CPU XEON 

Модели неплохо бы указать поточнее. Если это древности уровня Саня-мост, то там да, лазить в чужой процессор было дорого.

 

В целом, надо взять мануал на мать и найти в нём схему (в примере - страница 11 по внутненней нумерации). Посмотреть, от какого CPU берутся линии PCIE в какой слот, и сравнить, в каких слотах стоят сетевые карты. Одна сетевая должна идти к одному процессору, вторая - ко второму, и IRQ распределяете аналогично, чтобы каждый CPU обрабатывал только свою NIC.

 

Но проблема обмена паямти между NUMA-доменами все равно остается. В вашем случае наиболее разумно все держать на одном процессоре, избегая перетеканий. Второй CPU пусть остается на всякие мелкие служебные расходы.

 

Судя по количеству потоков, включен HT. Его стоит попробовать выключить - 20G (а по факту 40 - считается обе стороны) это немало, врядли у вас CPU простаивает, чтобы извлекать пользу из HT, HT тут скорее помешать может.

[Alex S. B.]

Дополню тему. Весь сетап овер 1млн руб. Прошу не задавать глупых вопросов "нахера","я бы сделал дешевле" и т.д.

Есть такой сервер - курил на складе , почему не попробовать в формате факультатива поюзать. 

 

Мать s2600wf

Процы Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz 24 физ.ядра

Сетевухи Silicom PE310G4SPi9LA-XR SFP+, Intel 82599ES

 

В мануале на мать есть описание какой порт подключен к какому CPU

Ну и блоксхема мамки

 

По тюнингу биоса

Выключен HT

Убраны всякие C-state, оптимизировано все на max-performance и никаких энергосберегающих дел.

Отключено все что связано с вирутализацией.

NUMA - включена. ECC включена.

 

 

[Alex S. B.]

2 часа назад, Saab95 сказал:

Надо поставить еще один сетевой адаптер и разделить потоки, что бы одну сетевушку обслуживал первый процессор, вторую второй.

Делали так, результат тот-же. Есть мнение что это проблема с linux-rss

 

Написали простенький скрипт для раскидки по ядрам.. который генерирует скрипт для ROS вида..

/system resource irq set [find users ="eth13-TxRx-0"] cpu="0"
/system resource irq set [find users ="eth13-TxRx-1"] cpu="1"
/system resource irq set [find users ="eth13-TxRx-2"] cpu="2"
/system resource irq set [find users ="eth13-TxRx-3"] cpu="3"
/system resource irq set [find users ="eth13-TxRx-4"] cpu="4"
/system resource irq set [find users ="eth13-TxRx-5"] cpu="5"
/system resource irq set [find users ="eth13-TxRx-6"] cpu="6"
/system resource irq set [find users ="eth13-TxRx-7"] cpu="7"
/system resource irq set [find users ="eth13-TxRx-8"] cpu="8"
/system resource irq set [find users ="eth13-TxRx-9"] cpu="9"

 

Цитата

1. Нагрузка ложится только на 8 первых ядер, если у нас всего 8 очередей, или нагрузка ложится только на 16 ядер, даже если очередей больше.
   Эээ?.. Об этом расскажу подробнее.

Для начала разберёмся с ограничением в 16 ядер и с тем, почему Intel позволяет делать много очередей (на 10 Гбит), а загружает, в основном, первые 16.

Волшебная цифра 16 — это максимальное количество очередей, на которое может распределить трафик RSS. Длина хеша RSS-индекса нормальная, но используются только последние 4 бита, поэтому максимальное количество очередей, которое он может выдать — 16. Это ограничение самой технологии и с ним ничего сделать нельзя.

Источник

 

Edited January 22, 2021 by Alex S. B.

[Alex S. B.]

А вот еще магия!

Раскинули на каждый порт 8 CPU одного камня и 8 от второго.. И так для всех портов всех сетевух независимо от райзера.

Никакой деградации, все работает отлично. Что подсказывает нам что проблема не в NUMA, шине и т.д.

Трафика 15RX ну и столько же TX

 

Edited January 22, 2021 by Alex S. B.

[Alex S. B.]

В итоге пришли к тому что раскину все на один проц.

И еще про включение RPS на всех интерфейсах, начинает грузить все процы но дело в том что от этого первому камню не легчает никак.

 

[starik-i-more]

Было бы очень познавательно узнать было ли продолжение у этой истории.

 

[Saab95]

Цитата

Было бы очень познавательно узнать было ли продолжение у этой истории.

Про эту историю не известно, но сколько тут тем не было, часто после 10Г скорости с серверов уходят на просто несколько CCR и все работает стабильно без потерь, постоянных перенастроек и с малым потреблением электричества.

 

Основная ошибка в том, что из-за малого количества портов в один физический порт начинают подавать несколько разных каналов провайдеров через вланы, тем самым забивая буфер сетевого адаптера. Если для сравнения взять CCR1072, то у него 10Г портов в достатке и можно каждого провайдера подключить в свой порт и никаких проблем не будет. Однако есть на том же CCR1072 всех провайдеров загнать в один порт, разбив на вланы - появятся проблемы.

[starik-i-more]

Слишком уж безумная цена сейчас у CCR1072. 

Mikrotik x86 на сервере получается в разы дешевле. Поэтому интересует вариант x86

[Saab95]

Цитата

Слишком уж безумная цена сейчас у CCR1072. 

Поищите б/у, вполне реально найти за 120 тыс. с документами.

 

Цитата

Mikrotik x86 на сервере получается в разы дешевле. Поэтому интересует вариант x86

Если уж надо дешевле то собирать надо на серверной материнской плате или десктопной под процессор с максимальной частотой ядер и размером кэша. Установить нужное количество сетевых адаптеров, что бы не использовать вланы на высоконагруженных портах.

[Negator]

Хм, а чем плохи вланы то?

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

А там речь не идет о сотнях вланов, а всего несколько штук.

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

И ладно бы речь шла о x86, там действительно могут быть проблемы как с производительностью, так и с сетевушками и прерываниями, но CCR должен нормально работать в рамках своей производительности.

 

[Saab95]

Цитата

Хм, а чем плохи вланы то?

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

Когда на микротике создается влан, он в Queues - Interface Queues появляется как интерфейс, и очередь проставляется no-queue. На основном интерфейсе используется стандартная очередь в виде аппаратного буфера и все. У основного интерфейса очереди нет, у влана очереди нет. Сам буфер адаптера мал, что бы вмещать в себя крупные всплески трафика. Ведь на том же 10Г интерфейсе данные могут поступать (образно) как в пределах секунды с медленной пиковой скоростью, так и выплевываться почти мгновенно на теоретическом потоке скорости 10Г, хотя сам объем трафика, допустим, 5Г.

 

И когда идет работа вида в один влан пришло, в другой влан ушло, то у интерфейса заняты и очередь приема, и очередь передачи, в этом-то и кроется проблема. Если через один физический порт данные приходят, через другой уходят, и это данные интернета, то есть в одну сторону, допустим 7Г, в другую 1Г, а на другом интерфейсе те же скорости наоборот.

[piratxx]

Quote

Когда на микротике создается влан, он в Queues - Interface Queues появляется как интерфейс, и очередь проставляется no-queue. На основном интерфейсе используется стандартная очередь в виде аппаратного буфера и все. У основного интерфейса очереди нет, у влана очереди нет. Сам буфер адаптера мал, что бы вмещать в себя крупные всплески трафика. Ведь на том же 10Г интерфейсе данные могут поступать (образно) как в пределах секунды с медленной пиковой скоростью, так и выплевываться почти мгновенно на теоретическом потоке скорости 10Г, хотя сам объем трафика, допустим, 5Г.

Добры день
Соглашусь отчасти, да виланы могут забыть очередь , но так же можно пользоваться несколькими портами как на "CCR 1072" у меня HP DL 360p 2 x e-2697 v4 с 4-я  портамы SFP+ цена машины примерно 600 $  можно добавить ещё 4 SFP+ работает как часики )