Перейти до

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


Рекомендованные сообщения

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

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

 

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

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

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

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

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

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

 

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

 

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

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

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

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

Задача - роутинг, 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


 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это неотключенный intel idle.
  • Thanks 1
Ссылка на сообщение
Поделиться на других сайтах

 

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

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

 

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

nAy8ZVMsYXv5n2.jpg

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Почти двое суток аптайма дропов на 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)

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

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

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

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

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

 

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

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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...