Is je VPN-gateway CPU-gebonden? Lees eerst de belasting per kern

Bepaal welke van de drie limieten je hebt bereikt voordat je een grotere instantie koopt. Eén kern vol belast terwijl de rest niets doet wijst op cryptowerk per flow. Alle kernen verzadigd tijdens een overdracht wijst op totale capaciteit. Lage CPU met een stijgend aantal hertransmissies wijst op het pad. Elk heeft een andere eerste stap, en slechts één ervan wordt opgelost door een grotere instantie.

Drie limieten, één tabel, drie oplossingen

Lees de rijen als diagnoses, niet als fasen. Eén thread op 100% terwijl de andere niets doen is het meest voorkomende resultaat op een gateway met één grote tunnel, omdat de versleuteling van die flow op één kern draait. Alle kernen bezet tijdens de overdracht betekent dat de machine al zoveel werk doet als ze kan. Lage CPU met stijgende hertransmissies betekent dat de processor wacht op een netwerk dat steeds data laat vallen.

Los ze op in die volgorde van bewijs. Flows over workers verdelen helpt het eerste geval en doet niets voor het tweede. Een grotere instantie helpt het tweede en verspilt geld aan het eerste. Een MTU- of verliesoplossing is de enige die het derde raakt. Capaciteit kopen voordat je weet in welke rij je zit is de dure versie van gokken.

Een vastgepinde thread van een drukke host scheiden

Begin met gebruik per kern, zodat één vastgepinde kern zich niet in een gemiddelde kan verstoppen. Eén run tijdens de overdracht laat zien of de belasting vlak of piekerig is. Beide vormen zijn informatief, en een piekerig profiel betekent vaak dat het meetvenster scheduleractiviteit heeft gevangen in plaats van versleuteling.

mpstat -P ALL 1 5

Wijs de drukke kern toe aan een proces en daarna aan een thread. De vervolgmeting hieronder houdt ouder- en kindthreads bij elkaar, wat uitmaakt wanneer de daemon per verbinding fork:

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

Kernelcrypto verschijnt nooit in een processteller in de gebruikersruimte. Meet threads apart en vergelijk dat beeld met de procesadministratie:

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

Lees de sockettellers als laatste, want die bepalen of meer CPU überhaupt zou helpen. Hertransmissies die stijgen terwijl de CPU vlak blijft is geen processorprobleem. Houd de overdracht actief tijdens het meten, anders beschrijven de cijfers een stille machine:

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

Een gecontroleerde overdracht, twee keer uitgevoerd

Stille tellers bewijzen niets, en een benchmark tegen een willekeurig eindpunt bewijst heel weinig. Kies één client, één bestemming en één representatieve overdracht die je mag uitvoeren, en leg dan doorvoer en interactieve vertraging in hetzelfde venster vast. Een gateway kan verzadigen terwijl een bulkkopie nog voltooit, en de vertragingscurve is wat gebruikers echt voelen. Schrijf de overdracht, het aantal clients en de daemonversie naast de cijfers.

Herhaal de run met meerdere parallelle flows. Opschalen over flows wijst op vensters per flow; vlak blijven met één vastgepinde kern wijst op verwerking.

Herhaal daarna nog eens met optionele werkbelasting gestopt. Een back-up, een logverzender of een database op dezelfde host kunnen een druk gemiddelde veroorzaken dat niets met tunnels te maken heeft. Als de CPU nog steeds vastgepind is terwijl de host verder stil is, wijst het bewijs op het VPN-proces. Als het daalt, mat je de buurman, en de gateway was nooit het probleem.

Sluit het pad uit voordat je hardware koopt

Stijgende hertransmissies, een krimpend congestievenster en een groeiende round-triptijd wijzen allemaal weg van de processor. Vergelijk de tunnel-MTU met de pad-MTU, controleer de onderliggende link op verlies en bevestig dat de uplink van de client niet de limiet is. Een grotere gateway repareert geen link die pakketten laat vallen, en gebruikers beschrijven beide fouten met dezelfde woorden. De hertransmissieteller scheidt ze binnen enkele minuten.

Voeg op een virtuele server de metriek van de provider toe aan die van de gast. Gestolen tijd is hoe overboeking zichtbaar wordt in de gast, en geen enkele afstelling in de gast haalt die weg. Gasttellers kunnen de host niet zien, dus een schone gastgrafiek is geen bewijs van een gezonde host.

Eén wijziging, één meting

Kies de hypothese die het bewijs ondersteunt en wijzig dan precies één ondersteunde instelling: aantal workers, een gedocumenteerde offloadoptie of de grootte van de instantie. OpenVPN publiceert een gids voor prestatieproblemen over dezelfde splitsing tussen verwerking en transport: Probleemoplossing voor OpenVPN-prestaties.

Controleer of de offloadoptie echt actief is in plaats van op de vlag te vertrouwen, voer daarna dezelfde overdracht opnieuw uit en vergelijk gelijk met gelijk. Dat is de enige manier om een echte verbetering van een stille middag te onderscheiden. Bewaar een controlepunt dat je kunt herstellen, want bij de tweede wijziging raken mensen de tel kwijt welke hielp. Eén variabele per run is traag voor een dag en snel voor een maand.

Verzwak authenticatie of de ciphersuite niet om de grafiek er beter uit te laten zien. Als de CPU het symptoom nog steeds niet volgt, ga terug naar pad- en applicatiecontroles in plaats van te upgraden op een gok.