Потери пакетов под нагрузкой

[mt6561 63]

Есть софтроутер, на нем либо 4x10G Intel, либо 1x40G меланокс, Линукс с ядрами 4.x.x разными.

Если на сетевухах бежит нагрузка >5 мегапакетов в секунду - начинает терять пакеты. И это при том, что загрузка ядер около 40-50%. Гипертрединг выключен. SoftIRQ не дергается.

 

Что может быть такое?

[SBogdan 5]

Китайские карточки на мусорник.

[mt6561 63]

В одном случае - НЕкитайски 82598EB, во втором - встроенный в сервер Supermicro родной Melanox.

 

В dmesg - ничего.

[SBogdan 5]

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

[KaYot 3 711]

По-твоему железо может просто так терять пакеты под нагрузкой? Ну чушь же.

Скорее уперлись в производительность, в скорость памяти/кешей или pci-e.

[mt6561 63]

Ну вот вопрос в производительность ЧЕГО упёрлись?

 

Две разных мамки - эффект тот же.

[SBogdan 5]

Ну вот вопрос в производительность ЧЕГО упёрлись?

 

Две разных мамки - эффект тот же.

 

Модули в карточках меняли? Память ОЗУ?

Відредаговано 2016-11-14 21:51:08 SBogdan

[KaYot 3 711]

Железо и задачи сервера озвучьте, может у вас трафик через conntrack гоняется? Тут никакое железо больше и не выдаст.

[mt6561 63]

Задача - роутинг, conntrack выключен (при включении сразу уприаемся в CPU, естесственно). В последнем эксперименте карточки две 82598EB в LACP (4x10 гигабит), медными шнурками воткнуты в свитч. Память DDR4 2100. Процы - E5-2683 v3, всего 28 голов, гипертрединг выключен. По htop'у загрузка каждой головы процентов 40 максимум. Ядро 4.8.6, драйвер с сайта Intel версии 4.4.0-k, параметры драйвера RSS=14,14,14,14 IntMode=2,2,2,2 InterruptThrottleRate=1,1,1,1.

В логах - ничего вообще.

По ifconfig наблюдаются ошибки:

        RX errors 0  dropped 760  overruns 0  frame 0
        TX errors 0  dropped 2175299037 overruns 0  carrier 0  collisions 0
на некоторых(!) вланах, причем от загрузки влана количество дропов не зависит. на физических интерфейсах:

        RX errors 0  dropped 6059887750  overruns 0  frame 0
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethtool -S enp2s0f0 говорит:

     rx_dropped: 41990
     tx_dropped: 0
     multicast: 668190
     broadcast: 7808882
     rx_no_buffer_count: 251
     rx_missed_errors: 6063866755
     rx_long_length_errors: 10169
     rx_csum_offload_errors: 428897


 

[NiTr0 584]

ИМХО - либо буфферы слишком мелкие (увеличить через ethtool), либо грабля в том что прерывания обрабатываются не тем камнем, к которому подключен собссно pci-e слот, а другим, и данные выгребаются через межпроцессорную шину, со всеми вытекающими...

 

https://communities.intel.com/community/wired/blog/2009/11/04/how-the-kitchen-sink-and-statistics-explain-and-treat-dropped-packetsнеплохо описано что какая ошибка значит.

Відредаговано 2016-11-15 09:30:42 NiTr0

[KaYot 3 711]

Помню в подобной ситуации помогло снятие одного физического камня, очень много заморочек именно с NUMA-нодами и контоллером pci. Если есть возможность, попробуйте.

Очень похоже на то, что обработка прерываний идет не на том камне, к которому физически подключен данный pcie порт.

[mt6561 63]

Вылечилось сменой сетевушки на другую аналогичную, кстати Спасибо откликнувшимся!

[rtrt 53]

а может не в сетевой было дело? плохие контакты, не дожали и т.д.?

[walertos 3]

Реально не верю что в сетевой было дело!

Реально у меня много серверов с 82599 картами.

Если прерывания на два камня раскладую то есть дропы, причём они при определённой нагрузке при высокой их нет и при низкой нет только при средней. Это на сервере с 6ти ядерными камнями.

Есть сервер с двумя 4 ядерными камнями на нём дропов нет, правда там ещё мать двухпроцовая Intel, может дело именно и в мамке.

В общем я до конца пока не разгадал загадку.

C отключенным conntrack можно через один Xeon E5 100Г прогнать, откуда у вас 40% не понимаю это очень много!

Напишите пожалуйста по подробнее какая карта была и на какую поменяли.

[KaYot 3 711]

Если прерывания на два камня раскладую то есть дропы, причём они при определённой нагрузке при высокой их нет и при низкой нет только при средней

Это неотключенный intel idle.

[walertos 3]

 

Если прерывания на два камня раскладую то есть дропы, причём они при определённой нагрузке при высокой их нет и при низкой нет только при средней

Это неотключенный intel idle.

 

Вот этот функционал отключаю всегда везде на всех серверах.

[KaYot 3 711]

Вот только это не оно.

И вообще, нынче отключение сберегаек в биосе обычно не имеет смысла.

[walertos 3]

А что тогда оно?

 

C-STATE технология от Intel это именно оно!

Відредаговано 2016-12-17 18:15:24 walertos

[KaYot 3 711]

Есть одно НО. Линуксовому модулю intel_idle похоже фиолетовы настройки биоса, он управляет этими самыми cstate самостоятельно.

Гарантированно можно его отключить передавая параметры ядру processor.max_cstate=1 intel_idle.max_cstate=0, или =0, =0 для экстрималов.

[walertos 3]

Debian ядро 3.16 не одно из вышеперечисленных параметров не имеет, значит они не были включены при сборке ядра.

Следовательно проблема дропов так и остаётся загадкой.

[KaYot 3 711]

Как же все печально.

По умолчанию модуль собран и работает.

Никаких параметров ядра и не должно быть.

 

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

[walertos 3]

Передал параметры через GRUB!

Посмотрим даст это что-то или нет.

[walertos 3]

Ну что скажу как бы это не было абсурдно но в целом картина поменялась.

Почти двое суток аптайма дропов на 10Г картах нет.

eth0      Link encap:Ethernet  HWaddr 00:e0:ed:2d:24:df  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15957275847 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11421240421 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000 
          RX bytes:18474953778844 (16.8 TiB)  TX bytes:4628151133263 (4.2 TiB)


eth1      Link encap:Ethernet  HWaddr 00:e0:ed:2d:24:de  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15137879918 errors:0 dropped:2 overruns:0 frame:0
          TX packets:21714833251 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000 
          RX bytes:6476504278016 (5.8 TiB)  TX bytes:25579612539245 (23.2 TiB)

А вот на гиговых 82576 иногда проскакивает, но они в LACP грешу на это.

eth2      Link encap:Ethernet  HWaddr 00:1b:21:a1:05:92  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:2845846981 errors:0 dropped:4151392 overruns:4083152 frame:0
          TX packets:1614361900 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3250606086892 (2.9 TiB)  TX bytes:670467192799 (624.4 GiB)


eth3      Link encap:Ethernet  HWaddr 00:1b:21:a1:05:92  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:2797697363 errors:0 dropped:17 overruns:0 frame:0
          TX packets:1735436790 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3244647234965 (2.9 TiB)  TX bytes:773658264536 (720.5 GiB)

[KaYot 3 711]

Почему же абсурдно, все логично и понятно.

При низкой нагрузке потерь нет само собой, пофиг на сбережение.

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

При большой загрузке система не спит вообще и проблем нет.

 

Эти параметры в любом мануале идут первым делом, странно что вы с ними не столкнулись на просторах интернета.