Назад | Перейти на главную страницу

Отбрасывание пакетов на HP ProLiant DL360 G9 под управлением RHEL 6.10

У нас есть HP ProLiant DL360 G9 под управлением RHEL 6.10 с 2 X Intel 82599ES 10-Gigabit SFI/SFP+. Название продукта HP HP Ethernet 10Gb 2-port 560SFP+ Adapter

eth5 и eth6 показывает большое количество отбрасываемых пакетов (rx_missed_errors) Я отключил управление потоком на уровне сетевой карты, затем rx_missed_errors перестал увеличиваться, но rx_no_dma_resources начал увеличивать ежедневно.

Оба они являются автономными интерфейсами, не связанными друг с другом.
Eth5 и eth6 находятся на разных картах
Обе карты установлены в слот PCIe 3.0 X16
irqbalance работает на сервере

Обновление 1

Параметры звонка для eth5 и eth6 такие же и уже на макс.

Pre-set maximums:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096
Current hardware settings:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096

Я заметил следующее за eth6 в /proc/interrupts

 Sun Jun  2 19:39:42 EDT 2019

            CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       CPU8       CPU9       CPU10      CPU11      CPU12      CPU13      CPU14      CPU15      CPU16      CPU17      CPU18      CPU19
 165:          0          0          0          0          0     484430     111744     333783     458868     577617          0          0          0          0          0      17978     402211      84832     183482   10567190   PCI-MSI-edge      eth6-TxRx-0
 166:          0          0          0          0          0      92569    2522312      36248      19459       1970          0          0          0          0          0      10140      33710      10180    1071214     651534   PCI-MSI-edge      eth6-TxRx-1
 167:          0          0          0          0          0      41060    2532170      37345      10970      92570          0          0          0          0          0       3055      22158      12485    1203344     494179   PCI-MSI-edge      eth6-TxRx-2
 168:          0          0          0          0          0     218925       8555    2312817     115650     126113          0          0          0          0          0      14575       3965     114145     995924     538667   PCI-MSI-edge      eth6-TxRx-3
 169:          0          0          0          0          0       7354       7781     199591    2262057      45221          0          0          0          0          0      34813     176350     105008     649389     962393   PCI-MSI-edge      eth6-TxRx-4
 170:          0          0          0          0          0      27982      23890      44703     162340    2597754          0          0          0          0          0      25991      22873      11846     885511     943057   PCI-MSI-edge      eth6-TxRx-5
 171:          0          0          0          0          0      16710        370        155   17725587    7504781          0          0          0          0          0 1054801625    1644839      14655  583745291  266971465   PCI-MSI-edge      eth6-TxRx-6
 172:          0          0          0          0          0       9823       6688     407394      11207      44103          0          0          0          0          0      88057    2496075       9284      56799    1391075   PCI-MSI-edge      eth6-TxRx-7
 173:          0          0          0          0          0      21175       1995     125490     151465      27120          0          0          0          0          0      19960     177195    2288457     787724     848755   PCI-MSI-edge      eth6-TxRx-8
 174:          0          0          0          0          0       7835       2210       3990      56075     106870          0          0          0          0          0     109740      24135      27720    2599827    1510934   PCI-MSI-edge      eth6-TxRx-9
 175:          0          0          0          0          0      42450       2605      39545      54520     162830          0          0          0          0          0      56035      11380      33815      52905    3993251   PCI-MSI-edge      eth6-TxRx-10
 176:          0          0          0          0          0      92335      33470    2290862       7545     227035          0          0          0          0          0       7550      25460      17225      65205    1682649   PCI-MSI-edge      eth6-TxRx-11
 177:          0          0          0          0          0      81685      56468    2273033     264820     195585          0          0          0          0          0     120640      36250      29450     244895    1146510   PCI-MSI-edge      eth6-TxRx-12
 178:          0          0          0          0          0      39655      24693     703993    1680384      22325          0          0          0          0          0     147980      27170      41585      72085    1689466   PCI-MSI-edge      eth6-TxRx-13
 179:          0          0          0          0          0     108905       1335      48265    2415832      19985          0          0          0          0          0       3545      23360      12590      35185    1780334   PCI-MSI-edge      eth6-TxRx-14
 180:          0          0          0          0          0     134826     291569      98014       9159    2262093          0          0          0          0          0     128867      18499      20078      39858    1463678   PCI-MSI-edge      eth6-TxRx-15
 181:          0          0          0          0          0       3220      37430      39030     129550      11070          0          0          0          0          0    2382452      24840      10860     146795    1664089   PCI-MSI-edge      eth6-TxRx-16
 182:          0          0          0          0          0      23120      28700     134025      96455      31545          0          0          0          0          0      30340    2262857      24485     144620    1673189   PCI-MSI-edge      eth6-TxRx-17
 183:          0          0          0          0          0       8900      29070      22490     112785     186240          0          0          0          0          0      40690      31665    2274862      37160    1705474   PCI-MSI-edge      eth6-TxRx-18
 184:          0          0          0          0          0      77090      18270      68465      53235     142648          0          0          0          0          0      16295      33770      29175    2367462    1642926   PCI-MSI-edge      eth6-TxRx-19
 185:          0          0          0          0          0         11          0          0          0          0          0          0          0          0          0          0          0          0          0          4   PCI-MSI-edge      eth6

Итак, похоже, что CPU / Core 15/18/19 испытывают нагрузку на обработку трафика на eth6

В принципе, я не знаю, где искать дальше, я предполагаю, что это может иметь какое-то отношение к сродству irq, но не уверен. Я также думаю об отключении irqbalance, но не уверен, что это изменит ситуацию.

какие-либо предложения?

Обновление 2

Информация о драйвере NIC, и я не думаю, что у нас есть эта ошибка. Как это было в 2009 году.

driver: ixgbe
version: 4.2.1-k
firmware-version: 0x800008ea
bus-info: 0000:08:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

Данные, полученные на обоих eth5 / 6, являются данными многоадресной рассылки. Достаточно ли этого, чтобы настроить зеркалирование портов, нужен билет для группы сетевых инженеров и потребуется время. Я также не знаю, что им сказать.

Если я правильно понимаю ваши комментарии, есть способ сбалансировать очередь eth6-rxtx для более чем одного ядра процессора. Я сам немного поискал и собрал следующую информацию, надеюсь, что она будет вам полезна.

ethtool -x eth5 и eth6

RX flow hash indirection table for eth5 with 20 RX ring(s):
    0:      0     1     2     3     4     5     6     7
    8:      8     9    10    11    12    13    14    15
   16:      0     1     2     3     4     5     6     7
   24:      8     9    10    11    12    13    14    15
   32:      0     1     2     3     4     5     6     7
   40:      8     9    10    11    12    13    14    15
   48:      0     1     2     3     4     5     6     7
   56:      8     9    10    11    12    13    14    15
   64:      0     1     2     3     4     5     6     7
   72:      8     9    10    11    12    13    14    15
   80:      0     1     2     3     4     5     6     7
   88:      8     9    10    11    12    13    14    15
   96:      0     1     2     3     4     5     6     7
  104:      8     9    10    11    12    13    14    15
  112:      0     1     2     3     4     5     6     7
  120:      8     9    10    11    12    13    14    15
RSS hash key:
3c:f9:4a:0e:fc:7e:cb:83:c2:2a:a4:1c:cf:59:38:1c:ca:54:38:b9:6b:e8:2b:63:6e:d2:9f:eb:fc:04:c2:86:6d:e3:54:f2:73:30:6a:65

ethtool -n eth5 rx-flow-hash udp4 и eth6

UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA

Я также бегу set_irq_affinity на обоих eth5 и eth6

sudo ./set_irq_affinity local eth5

IFACE CORE MASK -> FILE
=======================
eth5 0 1 -> /proc/irq/144/smp_affinity
eth5 1 2 -> /proc/irq/145/smp_affinity
eth5 2 4 -> /proc/irq/146/smp_affinity
eth5 3 8 -> /proc/irq/147/smp_affinity
eth5 4 10 -> /proc/irq/148/smp_affinity
eth5 10 400 -> /proc/irq/149/smp_affinity
eth5 11 800 -> /proc/irq/150/smp_affinity
eth5 12 1000 -> /proc/irq/151/smp_affinity
eth5 13 2000 -> /proc/irq/152/smp_affinity
eth5 14 4000 -> /proc/irq/153/smp_affinity
eth5 0 1 -> /proc/irq/154/smp_affinity
eth5 1 2 -> /proc/irq/155/smp_affinity
eth5 2 4 -> /proc/irq/156/smp_affinity
eth5 3 8 -> /proc/irq/157/smp_affinity
eth5 4 10 -> /proc/irq/158/smp_affinity
eth5 10 400 -> /proc/irq/159/smp_affinity
eth5 11 800 -> /proc/irq/160/smp_affinity
eth5 12 1000 -> /proc/irq/161/smp_affinity
eth5 13 2000 -> /proc/irq/162/smp_affinity
eth5 14 4000 -> /proc/irq/163/smp_affinity

sudo ./set_irq_affinity local eth6

IFACE CORE MASK -> FILE
=======================
eth6 5 20 -> /proc/irq/165/smp_affinity
eth6 6 40 -> /proc/irq/166/smp_affinity
eth6 7 80 -> /proc/irq/167/smp_affinity
eth6 8 100 -> /proc/irq/168/smp_affinity
eth6 9 200 -> /proc/irq/169/smp_affinity
eth6 15 8000 -> /proc/irq/170/smp_affinity
eth6 16 10000 -> /proc/irq/171/smp_affinity
eth6 17 20000 -> /proc/irq/172/smp_affinity
eth6 18 40000 -> /proc/irq/173/smp_affinity
eth6 19 80000 -> /proc/irq/174/smp_affinity
eth6 5 20 -> /proc/irq/175/smp_affinity
eth6 6 40 -> /proc/irq/176/smp_affinity
eth6 7 80 -> /proc/irq/177/smp_affinity
eth6 8 100 -> /proc/irq/178/smp_affinity
eth6 9 200 -> /proc/irq/179/smp_affinity
eth6 15 8000 -> /proc/irq/180/smp_affinity
eth6 16 10000 -> /proc/irq/181/smp_affinity
eth6 17 20000 -> /proc/irq/182/smp_affinity
eth6 18 40000 -> /proc/irq/183/smp_affinity
eth6 19 80000 -> /proc/irq/184/smp_affinity

Обновление 3

Я модифицировал upd4 rx-flow-hash чтобы включить порт источника и назначения, но это не имело никакого значения.

ethtool -n eth5 rx-flow-hash udp4

UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

Отключено irqbalance и вручную обновить /proc/irq/171/smp_affinity_list чтобы включить все 10 «локальных» ядер ЦП.

cat /proc/irq/171smp_affinity_list

5-9,15-19

Вот это grep 171: /proc/interrupts после того, как я сделал вышеуказанное изменение (добавьте порт src и dst в udp4 rx-flow-hash и добавил 5-9,15-19 к /proc/irq/171/smp_affinity_list) Назовем это раньше.

Вот это grep 171: from /proc/interrupts сегодня утром назовем это потом.

Before 171:          0          0          0          0          0      16840        390        155   17725587    7505131          0          0          0          0          0 1282081848  184961789      21430  583751571  266997575   PCI-MSI-edge      eth6-TxRx-6
After  171:          0          0          0          0          0      16840        390        155   17725587    7505131          0          0          0          0          0 1282085923  184961789      21430  583751571  267026844   PCI-MSI-edge      eth6-TxRx-6

Как видно сверху, irq 171 обрабатывается только CPU 19. Если irqbalance работает другой процессор будет обрабатывать irq 171, кажется почему-то irq 171 не может быть сбалансирован для более чем одного процессора.

Вот обновления сброса пакетов

Wed Jun 5 01:39:41 EDT 2019
ethtool -S eth6 | grep -E "rx_missed|no_buff|no_dma"
rx_no_buffer_count: 0
rx_missed_errors: 2578857
rx_no_dma_resources: 3456533

Thu Jun 6 05:43:34 EDT 2019
njia@c4z-ut-rttp-b19 $ sudo ethtool -S eth6 | grep -E "rx_missed|no_buff|no_dma"
rx_no_buffer_count: 0
rx_missed_errors: 2578857
rx_no_dma_resources: 3950904

Время здесь не имеет значения, поскольку многоадресная передача данных прекращается каждый день после 16:00.

Я нашел эту статью на сайте Red Hat Потеря пакетов, когда несколько процессов подписываются на одну и ту же группу многоадресной рассылки.

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

Вырос net.core.rmem_default из 4Mb к 16Mb

sysctl -w net.core.rmem_default=16777216
net.core.rmem_default = 16777216

Вот текущий Udp состояние стека, завтра еще раз проверю.

Fri Jun  7 00:40:10 EDT 2019
netstat -s | grep -A 4 Udp:

Udp:
    90579753493 packets received
    1052 packets to unknown port received.
    1264898431 packet receive errors
    1295021855 packets sent

Проверить версию драйвера. Там было ошибка при правильном учете rx_no_dma_resources, когда rx buffer полон. Так что проверьте длину кольцевых буферов (ethtool -g <iface>) и увеличиваем (ethtool -G <iface> rx <size> tx <size>, но это вызовет кратковременный перерыв в обработке пакета).

Примечание: После обновления вопроса вы знаете, что ошибки нет, но, думаю, проблемы следует решать в порядке важности. Итак, решим вопрос с missing ошибок и только потом пытайтесь решить rx_no_dma_resources ошибки.

В rx_missed_errors означает, что в системе недостаточно ресурсов процессора для обработки входящих пакетов. В большинстве случаев это происходит, когда ядро процессора, которое должно выполнять обработчик irq, находится под нагрузкой. Проверьте вывод cat /proc/interrupts команда. Изучите, как счетчики IRQ сетевой карты распределяются между ядрами ЦП. Отключить irqbalance и использовать set_irq_affinity скрипт для привязки обработчиков irq к ядрам. Если в вашей системе несколько доменов NUMA, вам следует использовать local или remote варианты этого скрипта.
Проверьте вывод perf top команда, чтобы выяснить, что вызывает загрузку процессора при обработке сетевых пакетов.

Обновление 1

Как вы можете видеть в /proc/interrupts, некоторые ядра ЦП (15, 18, 19) обрабатывают гораздо больше (в сотни раз) прерываний от eth6-TxRx-6 обработчик IRQ очереди, чем другие ядра. Проверьте загрузку этих ядер процессора. Скорее всего, они очень часто бывают перегружены.

Итак, за исключением неправильной привязки процессора и irqbalance, у вас другая проблема. Вам следует изучить преобладающий тип трафика, проходящего через очередь 6 eth6 NIC. Используйте зеркалирование портов коммутатора и wirehark (начните с Statistics - Protocol Hierarchy). После этого вы можете настроить хеширование RSS с помощью ethtool для разделения этого трафика между несколькими очередями сетевых адаптеров. Это позволит избежать перегрузки некоторых ядер.

Несколько замечаний о NUMA

Вы спрашивали подробности о local и remote варианты set_irq_affinity сценарий. Чтобы ответить на этот вопрос, я нарисовал упрощенную схему системы с двумя розетками.

Современные процессоры имеют встроенный контроллер памяти и контроллер PCI-express. В случае систем с несколькими сокетами существует межпроцессорная связь для обеспечения обмена данными между процессорами. Каждый процессор может получить доступ ко всей памяти. Но в случае, если процессор работает с данными в области памяти, которая управляется контроллером памяти другого процессора, это влечет за собой накладные расходы на запрос к этому удаленному контроллеру памяти и штраф за передачу данных по межпроцессорной связи.

Передача данных между устройством PCI-Express и системой осуществляется с помощью DMA (прямого доступа к памяти), что позволяет периферийному устройству читать / записывать данные в ОЗУ без явных запросов к ЦП. Очевидно, что он очень специфичен для реализации, но он также наследует те же ограничения доступа к памяти.

Итак, как же во всем этом повлияло сродство irq? Грубо говоря, когда сетевая карта PCI-Express получает данные извне, она сохраняет эти данные в системной оперативной памяти с DMA и генерирует прерывание для уведомления системы. Что произойдет, если обработчик прерывания будет выполняться на другом процессоре, а не локально? Естественно, обработчику прерывания нужны полученные данные для их обработки. И все накладные расходы и штрафы за удаленную память будут сняты. В худшем случае это может привести к перегрузке межпроцессорной связи.

Итак, как видите, правильная настройка сродства irq для систем NUMA очень важна. В set_irq_affinity сценарий автоматизирует привязку обработчиков irq очередей сетевых адаптеров к ядрам ЦП. В лучшем случае вы увидите «лестницу» ненулевых счетчиков в /proc/interrupts. Очевидно, что irqbalance пытается играть в свою игру и полностью убивает выгоды от этой привязанности к irq.

Обновление 2

Итак, какая информация у нас есть на данный момент:

Есть много многоадресного трафика, который обрабатывается eth6-TxRx-6 обработчик прерывания.
RSS-хэш UDP4: ip source address и ip destination address.
После запуска set_irq_affinity обработчик этой очереди привязан к 16-му ядру.

Что вы можете сделать сейчас:

Следите за статистикой и загрузкой ядра, особенно 16 ядра. Есть ли по-прежнему перегрузка и ошибки?
Этот многоадресный трафик - единственный поток или несколько? Если потоков несколько, можно настроить хеширование udp4 с участием ethtool. Если сетевая карта будет использовать не только IP-адреса для хэша, но и номера портов, вероятно, она сможет разделить обработку между несколькими очередями приема и, следовательно, между несколькими ядрами процессора. Если это единственный поток, вы можете попробовать привязать к соответствующему обработчику irq несколько ядер процессора.

Обновление 3

Итак, у вас одновременно возникает несколько проблем.

в netstat вывод у вас есть:

1264898431 ошибки приема пакетов

Но эти ошибки не относятся к отсутствующим ошибкам. Когда системе не хватает ресурсов процессора для обработки irq, пакет будет потерян до того, как будет выполнен какой-либо обработчик протокола. Если памяти для буферов сокета UDP недостаточно, вы увидите соответствующие ошибки в выводе nstat -az UdpRcvbufErrors команда. Следите за этим и увеличивайте лимит памяти с помощью переменных sysctl. Вы также можете контролировать очередь приема сокетов с помощью ss инструмент. Это тоже может быть полезно.

Выясните, какие процессы потребляют время процессора. После этого вы можете профилировать рабочую нагрузку с помощью perf record или perf top. Это правда softirq перегружает одноядерник? Этот процесс ядра поддерживает многие вещи, поэтому perf top будет полезно выяснить, что именно потребляет большую часть времени процессора.
Если у вас есть только одна группа многоадресной рассылки, для этого потока будет выполняться только один irq, потому что хэш n-кортежей всегда будет одинаковым. Я не знаю никакого обходного пути в этом случае. Единственный способ - использовать более быстрый процессор. Также вы можете проверить результаты i7z инструменты для отслеживания состояний сна процессора.
Я не знаю особенностей архитектуры вашего приложения, но, возможно, у вас также есть проблема с потерей многоадресных дейтаграмм udp при запуске нескольких экземпляров. Возможно, это тоже связано с некорректной привязкой экземпляров приложения к ядрам процессора. Попробуйте привязать процессы приложения к ядрам процессора.

P.S. Я расширю ответ, когда вы предоставите информацию о результатах описанных выше шагов.