Вопросы Теги

Отбрасывание пакетов на 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 10 Гбит 2-портовый адаптер 560SFP +

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

Информация о драйвере сетевой карты, и я не думаю, что у нас есть эта ошибка. Как и в 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

Update 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: из / 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 с 4 МБ до 16 МБ 

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
3
задан 7 June 2019 в 07:44
1 ответ

docker history image_name
docker logs container_id

. A existat eroarea cu contabilitatea corectă a rx_no_dma_resources , când tamponul rx este plin. Deci, verificați lungimea tampoanelor inelare ( ethtool -g ) și creșteți-o ( ethtool -G rx tx , dar va fi cauzează o scurtă pauză de timp în procesarea pachetelor).

Notă: După actualizarea întrebării știți că nu există o eroare, dar, cred, problemele ar trebui rezolvate în ordinea importanței . Deci, să rezolvăm problema cu erorile lipsă și abia apoi încercăm să rezolvăm erorile rx_no_dma_resources .

  1. rx_missed_errors înseamnă că sistemul nu are suficiente resurse cpu pentru procesarea pachetelor primite. În cele mai multe cazuri se întâmplă când nucleul procesorului, care ar trebui să execute handler-ul irq, este sub o încărcare. Verificați ieșirea comenzii cat / proc / interrupts . Investigați modul în care contorul NIC irq distribuie între nucleele procesorului. Dezactivați irqbalance și utilizați scriptul set_irq_affinity pentru a lega handlerele irq la nuclee. Dacă sistemul dvs. are mai multe domenii NUMA, ar trebui să utilizați opțiunile locale sau la distanță ale acestui script.

  2. Verificați ieșirea comenzii perf top pentru a investiga ce cauzează încărcarea procesorului la procesarea pachetelor de rețea.

Actualizare 1

După cum puteți vedea în / proc / interrupts , unele nuclee CPU (15, 18, 19) gestionează mult mai mult (în sute times) întrerupe de la eth6-TxRx-6 coada irq handler, decât alte nuclee. Verificați încărcarea acestor nuclee CPU. Probabil, acestea sunt supraîncărcate foarte des.

Deci, cu excepția afinității incorecte a procesorului și irqbalance , aveți o altă problemă. Ar trebui să investigați tipul de trafic preponderent care trece prin coada 6 din eth6 NIC. Utilizați o oglindire a portului de comutare și wireshark (începeți de la Statistici - Ierarhia protocolului ). După aceasta puteți regla hash-ul RSS cu ethtool pentru a partaja acest trafic între mai multe cozi NIC. Se va evita supraîncărcarea unor nuclee.

Câteva note despre NUMA

Ați cerut detalii despre local și la distanță opțiuni din set_irq_affinity script. Pentru a răspunde la această întrebare, am desenat schema simplificată a unui sistem cu socket dual.

A dual socket system diagram

CPU-urile moderne au controler de memorie integrat și controler PCI-express. În cazul sistemelor cu mai multe socketuri, există un link interprocesor pentru a asigura schimbul de date între procesoare. Fiecare procesor poate avea acces la toată memoria. Dar, în cazul în care un procesor funcționează cu date într-o zonă de memorie, care este gestionată de un controler de memorie al unui alt procesor, aceasta implică cheltuielile generale pentru a solicita acestui controler de memorie la distanță și penalizarea pentru transferul de date pe link-ul interprocesor.

Transferul de date între un dispozitiv PCI-Express și un sistem este implementat cu DMA (Direct Memory Access), ceea ce este capabil pentru un dispozitiv periferic să citească / scrie date în RAM fără solicitări explicite către CPU. Evident, este foarte specific implementării, dar moștenește și aceleași limite de acces la memorie.

Deci, cum a implicat afinitatea irq în toate acestea? Aproximativ, atunci când PCI-Express NIC primește date din exterior, stochează aceste date în memoria RAM a sistemului cu DMA și generează întreruperea pentru a notifica sistemul. Ce se întâmplă dacă tratamentul de întrerupere va fi executat pe celălalt procesor, nu local? Bineînțeles, gestionarul de întreruperi are nevoie de datele primite pentru a le prelucra. Și toate cheltuielile generale și penalitățile pentru memoria de la distanță vor fi obținute.În cel mai rău caz poate duce la supraîncărcarea legăturii interprocesor.

Deci, după cum puteți vedea, configurarea corectă a afinității irq pentru sistemele NUMA este foarte importantă. Scriptul set_irq_affinity automatizează legarea cozilor NIC handler irq la nucleele CPU. În cel mai bun caz, veți vedea „scara” contoarelor diferite de zero în / proc / interrupts . Evident, irqbalance încearcă să joace în propriul joc și distruge complet beneficiile acestei afinități irq.

Actualizare 2

Deci, ce informații avem în momentul actual:

  • Există o mult trafic multicast, care este procesat de eth6-TxRx-6 handler de întrerupere.
  • Hash-ul RSS al UDP4 : adresa sursei IP și adresă de destinație ip .
  • După executarea set_irq_affinity gestionarul acestei cozi este legat de nucleul 16.

Ce puteți face acum:

  • Monitorizați statisticile și încărcarea miezului, în special a celui de-al 16-lea miez. Există încă erori de suprasarcină și lipsă?

  • Este acest trafic multicast singurul flux sau mai multe? Dacă există mai multe fluxuri, puteți regla hashing-ul udp4 cu ethtool . Dacă NIC va utiliza nu numai adresele IP pentru hash, ci și numerele de port, probabil că poate împărți procesarea între mai multe cozi de primire și, în consecință, între mai multe nuclee CPU. Dacă acesta este singurul flux, atunci puteți încerca să legați mai multe nuclee de procesor de controler irq corespunzător.

Actualizare 3

Deci, aveți mai multe probleme simultan.

  1. În netstat ieșire pe care o aveți:

1264898431 pachetul primește erori

Dar aceste erori nu se referă la erori lipsă. Când sistemul nu are suficiente resurse CPU pentru a gestiona irq-ul, pachetul se va pierde înainte ca orice handler de protocol să fie executat. Dacă memoria pentru tampoanele de socket UDP nu este suficientă, veți vedea erori corespunzătoare la ieșirea comenzii nstat -az UdpRcvbufErrors . Monitorizați-l și măriți limita de memorie cu variabilele sysctl. De asemenea, puteți monitoriza o coadă de recepție a soclurilor cu instrumentul ss . Poate fi de ajutor.

  1. Investigați, ce procese consumă timpul procesorului. După aceasta puteți profila volumul de lucru cu perf record sau perf top . Este într-adevăr softirq suprasolicită un singur nucleu? Acest proces de kernel menține multe lucruri, astfel încât perf top va fi util pentru a investiga ce anume consumă cel mai mult timp CPU.

  2. Dacă aveți un singur grup multicast, va fi executat doar un singur irq pentru acest flux. , deoarece n-tuple-hash va fi întotdeauna același. Nu cunosc nicio soluție pentru acest caz. Singura modalitate este de a utiliza un procesor mai rapid. De asemenea, puteți verifica rezultatele instrumentelor i7z pentru a monitoriza stările de repaus ale procesorului.

  3. Nu știu specificul arhitecturii aplicației, dar este posibil să aveți probleme cu pierderea datagramelor udp multicast când sunt rulate mai multe instanțe. Poate că s-a legat și de legarea incorectă a instanțelor aplicației la nucleele procesorului. Încercați să legați procesele aplicației de nucleele CPU.

P.S. Voi extinde răspunsul atunci când furnizați informații despre rezultatele etapelor de mai sus.

5
ответ дан 3 December 2019 в 05:38

Теги

Похожие вопросы