Puncte:2

Cum să asigurați debitul de pe dispozitivul de rețea de 10 GbE pe ubuntu 20.04 sub sarcină mare

drapel jp

Întâmpin probleme în a asigura un flux de rețea necesar pe un server conectat la un analizor de spectru Signal Hound printr-o interfață de rețea de 10 GbE.Practic, pot obține un randament bun atunci când rulează numai procesul de captare radio, dar când rulez alte procese, debitul începe să scadă. Folosesc un adaptor Ethernet Aquantia PCIe cu un adaptor QNAP SFP+ 10GbE Thunderbolt 3.

Când rulez un program python simplu pentru a interoga din API-ul analizorului de spectru în modul streaming, totul funcționează excelent la lățimea de bandă maximă (~800 MB/s). Cand fac

$ stress --cpu 8 --io 8 --vm 8 --hdd 8

alăturat, coboară la aproximativ 600 MB/s și încep să scad o mulțime de date.

Lucruri pe care le-am incercat:

  1. Actualizarea driverelor
  2. Încurcă cu parametrii de coalescere și multe opțiuni de ethtool (MTU, etc)
  3. Dezactivarea hyperthreadingului și izolarea procesului la un singur nucleu (8 din 8) prin fixarea afinității CPU
    • Acest lucru a implicat, de asemenea, izolarea întreruperilor de rețea la propriul lor nucleu (7 din 8)
    • De asemenea, schimb regulatorul de bază pentru a fi „performanță”, astfel încât să fie întotdeauna la frecvența maximă
    • De asemenea, am încercat să dezactivez majoritatea celorlalte întreruperi pentru nucleele 7 și 8 pentru a preveni încetinirea lor, verificat de un tablou de bord netdata
    • Practic am încercat totul în Aici

În esență, știu că poate rula în timp real, deoarece funcționează bine atunci când este limitat la 2 nuclee. Dar dintr-un anumit motiv, chiar dacă celelalte nuclee nu interferează cu ciclurile CPU sau cu IRQ-urile rețelei, atunci când nucleele 1-6 sunt la încărcare mare, încetinesc foarte mult procesul principal.

Dacă ajută, constat că --vm 4 opțiune pentru stres provoacă cea mai mare încetinire, așa că bănuiesc că are ceva de-a face cu alocarea memoriei și poate cu interfața DRAM la placa de rețea.

Practic, îmi smulg părul încercând să iau fiecare pachet de la radio pe o mașină Ubuntu 20.04 (ce ar trebui să fie foarte puternică). Are cineva experiență cu astfel de aplicații?

EDIT: Am copiat câteva dintre curbele de performanță aici:

Iată efectul pe care îl văd

Deci, aici este utilizarea.Core 6 este la 100% cu softirq atât în ​​timpul perioadei de stres ridicat, cât și în perioada de „doar captură”. Am încercat să împart datele rețelei pe două nuclee (5 și 6), dar unul dintre ele rămâne întotdeauna încărcat, în timp ce celălalt pare clar, chiar dacă au cantități similare de întreruperi. sarcina procesorului

Din păcate, numărul real de softirq scade pe CPU 6 în perioada în care se execută testul de stres. Număr IRQ soft

Iată efectul pe care îl văd pe CPU6 softnet. CPU6 Softnet

De asemenea, întreruperile par să rămână relativ aceleași, deși devin puțin mai puțin consistente în perioada de stres ridicat. întreruperi

Iată viteza directă a rețelei și pare puțin inconsecventă și în ambele perioade. Informații de rețea

Am căutat destul de atent anomaliile (deși există o mulțime de diagrame în netstat) și se pare că nu există nicio memorie interproces în timpul perioadei de stres ridicat. Acest lucru ar putea duce la probleme? introduceți descrierea imaginii aici

Dacă cineva are nevoie de mai multe parcele, anunță-mă. Nu pot deduce problema din acestea, dar sper că sunt suficiente informații pentru a veni cu potențiale soluții.

Multumesc din nou!

drapel jp
Brendan Gregg te așteaptă. Începeți cu pagina sa web https://www.brendangregg.com/, începeți să colectați valori de performanță a sistemului, căutați blocajele.
Eric avatar
drapel jp
Mulțumesc Alex pentru sugestii! Am editat postarea inițială cu mai multe curbe de performanță, astfel încât să sperăm că cineva mai inteligent decât mine să mă ajute să înțeleg ce se întâmplă.
Puncte:0
drapel jp

Ok toate, cred că am găsit un răspuns la problema mea. Cred că graficul cheie aici a fost graficul „softirq”. În condiții normale de funcționare, nu cred că ar trebui să fie atât de mare.

Am avut un mic moment în timpul profilării: practic, din moment ce rulez CUDA și o grămadă de alte biblioteci cu instalare dificilă, rulam toate acestea într-un container docker (știu ce spuneți cu toții!) . Din moment ce nu m-am încurcat cu chestiile de rețea pentru radio în docker, nu m-am cam gândit la asta.Și da, ați ghicit, rețeaua docker a adăugat suficientă procesare pentru a mă împinge peste margine pentru a arunca pachete. Am ajuns să setez mod retea la gazdă să folosesc rețeaua gazdă și mi-a rezolvat problema. Sper că acest lucru poate fi de ajutor altcuiva!

Dar asta nu este tot - pentru a-mi da seama, am petrecut o bună perioadă de timp profilând pentru a-mi da seama exact de ce vedeam efectul pe care îl vedeam (mulțumesc lui @AlexD pentru resurse). Iată un grafic de flacără al procesorului 7 fixat care rula driverele API: introduceți descrierea imaginii aici

După cum puteți vedea, petrece mult timp în alocarea memoriei cu erori de pagină (care ar fi trebuit să fie un alt indiciu, deși nu l-am postat aici. Defecte minore de memorie au fost prin acoperiș în timpul capturii). Asta explică de ce alerga stres cu --vm 4 a dat cele mai proaste rezultate - a provocat o dispută pentru memorie care a încetinit semnificativ șoferul. De asemenea, după ce l-am testat puțin, cred că oricum are nevoie de mai mult de un nucleu (scăpa pachete fixate exclusiv la nucleul 7, dar a funcționat fixat la 6 și 7). Obțineam rezultate mai bune după overclocking (dar încă nu perfect) și asta explică de ce.

Așa că iată-l: o explicație a motivului pentru care totul s-a întâmplat așa cum a fost, cu grafice pentru a le susține. Am o utilizare de aproximativ 60% pe două nuclee pentru API-ul radio și este destul de stabil în obținerea tuturor pachetelor (un alt nucleu gestionează softirq-urile la aproximativ 10%, în scădere de la 95% pe care îl vedeți în graficul de mai sus). Mă simt puțin prost pentru că nu m-am gândit la docker să mă încetinească, dar mult mai bine că am înțeles toate astea. Sper că această postare ajută pe altcineva!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.