Gateway-ul tău VPN este limitat de CPU? Citește mai întâi încărcarea pe nucleu

Decide care dintre cele trei limite a fost atinsă înainte de a cumpăra o instanță mai mare. Un nucleu plin în timp ce restul sunt inactive indică munca criptografică pe flux. Toate nucleele saturate în timpul unui transfer indică capacitatea totală. CPU scăzut cu un număr crescător de retransmisii indică calea. Fiecare are un prim pas diferit și doar unul este rezolvat de o instanță mai mare.

Trei limite, un tabel, trei corecturi

Citește rândurile ca diagnostice, nu ca etape. Un singur fir la 100% în timp ce celelalte sunt inactive este rezultatul cel mai frecvent pe un gateway cu un tunel mare, pentru că criptarea acelui flux rulează pe un singur nucleu. Toate nucleele ocupate în timpul transferului înseamnă că mașina face deja tot ce poate. CPU scăzut cu retransmisii în creștere înseamnă că procesorul așteaptă o rețea care pierde continuu date.

Corectează-le în acea ordine a dovezilor. Distribuirea fluxurilor pe workeri ajută primul caz și nu face nimic pentru al doilea. O instanță mai mare ajută al doilea și risipește bani pe primul. O corecție de MTU sau pierdere este singura care atinge al treilea. A cumpăra capacitate înainte de a ști pe ce rând ești este versiunea scumpă a ghicitului.

Separă un fir fixat de un host ocupat

Începe cu utilizarea pe nucleu, ca un nucleu fixat să nu se poată ascunde într-o medie. O singură rulare în timpul transferului arată dacă încărcarea este plană sau cu vârfuri. Ambele forme sunt informative, iar un profil cu vârfuri înseamnă adesea că fereastra de eșantionare a prins activitatea planificatorului, nu criptarea.

mpstat -P ALL 1 5

Atribuie nucleul ocupat unui proces, apoi unui fir. Rularea de urmărire de mai jos ține firele părinte și copil împreună, ceea ce contează când demonul se ramifică pentru fiecare conexiune:

pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10

Criptografia din nucleu nu apare niciodată într-un contor de proces din spațiul utilizator. Eșantionează firele separat și compară acea imagine cu evidența procesului:

top -H -b -n 1 | head -20

Citește contoarele de socket la final, pentru că ele decid dacă mai mult CPU ar ajuta măcar. Retransmisiile care cresc cu CPU plat nu sunt o problemă a procesorului. Ține transferul în funcțiune în timp ce eșantionezi, altfel cifrele descriu o mașină inactivă:

ss -ti | grep -E 'retrans|cwnd|rtt'

Un transfer controlat, rulat de două ori

Contoarele inactive nu dovedesc nimic, iar un benchmark împotriva unui punct final aleatoriu dovedește foarte puțin. Alege un client, o destinație și un transfer reprezentativ pe care ai voie să îl rulezi, apoi înregistrează debitul și latența interactivă în aceeași fereastră. Un gateway se poate satura în timp ce o copie masivă încă se termină, iar curba de latență este ceea ce simt cu adevărat utilizatorii. Scrie transferul, numărul de clienți și versiunea demonului lângă cifre.

Repetă rularea cu mai multe fluxuri paralele. Creșterea pe fluxuri sugerează ferestre pe flux; rămânerea plată cu un nucleu fixat sugerează procesare.

Apoi repetă încă o dată cu sarcinile opționale oprite. O copie de siguranță, un expeditor de jurnale sau o bază de date pe același host pot produce o medie ocupată care nu are nimic de-a face cu tunelurile. Dacă CPU este încă fixat în timp ce hostul este altfel liniștit, dovezile indică procesul VPN. Dacă scade, măsurai vecinul, iar gateway-ul nu a fost niciodată problema.

Exclude calea înainte de a cumpăra hardware

Retransmisii în creștere, o fereastră de congestie care se micșorează și un timp dus-întors în creștere indică toate departe de procesor. Compară MTU-ul tunelului cu MTU-ul căii, verifică legătura de bază pentru pierderi și confirmă că uplink-ul clientului nu este limita. Un gateway mai mare nu repară o legătură care pierde pachete, iar utilizatorii descriu ambele defecțiuni cu aceleași cuvinte. Contorul de retransmisii le separă în câteva minute.

Pe un server virtual, adaugă metricile furnizorului la cele ale oaspete. Timpul furat este modul în care supravânzarea devine vizibilă în oaspete, iar nicio reglare din oaspete nu îl elimină. Contoarele oaspetelui nu văd hostul, deci un grafic curat al oaspetelui nu este dovada unui host sănătos.

O schimbare, o măsurare

Alege ipoteza pe care o susțin dovezile, apoi schimbă exact o setare acceptată: numărul de workeri, o opțiune de descărcare documentată sau dimensiunea instanței. OpenVPN publică un ghid de depanare a performanței despre aceeași împărțire între procesare și transport: Depanarea performanței OpenVPN.

Confirmă că opțiunea de descărcare este într-adevăr activă în loc să te bazezi pe fanion, apoi rulează din nou transferul identic și compară comparabilul. Este singurul mod de a distinge o îmbunătățire reală de o după-amiază liniștită. Păstrează un punct de control pe care îl poți restaura, pentru că la a doua schimbare oamenii pierd urma a ceea ce a ajutat. O variabilă pe rulare este lentă pentru o zi și rapidă pentru o lună.

Nu slăbi autentificarea sau suita de cifruri ca să arate graficul mai bine. Dacă CPU nu urmărește încă simptomul, revino la verificările de cale și aplicație în loc să faci upgrade pe baza unei presupuneri.