Jump to content

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


Recommended Posts

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

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

 

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

 

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

 

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

Edited by SBogdan
Link to post
Share on other sites

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

Link to post
Share on other sites

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


 

Link to post
Share on other sites

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

 

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

Edited by NiTr0
Link to post
Share on other sites

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

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

Link to post
Share on other sites
  • 4 weeks later...

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

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

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

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

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

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

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

Link to post
Share on other sites

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

Это неотключенный intel idle.
  • Thanks 1
Link to post
Share on other sites

 

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

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

 

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

nAy8ZVMsYXv5n2.jpg

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

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

 

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

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

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

 

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...