Er VPN-gatewayen din CPU-bundet? Les belastningen per kjerne først
Gjennomsnitt skjuler tråden som betyr noe. Les belastningen per kjerne mot en kontrollert overføring, utelukk stien, og endre deretter én dokumentert innstilling per kjøring.
Avgjør hvilken av de tre grensene du har nådd før du kjøper en større instans. Én kjerne fullastet mens de andre er ledige peker på kryptarbeid per flyt. Alle kjerner mettet under en overføring peker på samlet kapasitet. Lav CPU med et stigende antall gjensendinger peker på stien. Hver har et annet første trekk, og bare én av dem løses av en større instans.
Tre grenser, én tabell, tre rettelser
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
Les radene som diagnoser, ikke som trinn. Én tråd på 100% mens de andre er ledige er det vanligste resultatet på en gateway med én stor tunnel, fordi krypteringen av den flyten kjører på én kjerne. Alle kjerner opptatt under overføringen betyr at maskinen allerede gjør så mye arbeid den kan. Lav CPU med stigende gjensendinger betyr at prosessoren venter på et nettverk som fortsetter å miste data.
Rett dem i den rekkefølgen av bevis. Å spre flyter over arbeidere hjelper det første tilfellet og gjør ingenting for det andre. En større instans hjelper det andre og sløser penger på det første. En MTU- eller taprettelse er den eneste som berører det tredje. Å kjøpe kapasitet før du vet hvilken rad du er i er den dyre versjonen av å gjette.
Skill en fastlåst tråd fra en travel vert
Start med utnyttelse per kjerne, slik at én fastlåst kjerne ikke kan gjemme seg i et gjennomsnitt. Én kjøring under overføringen viser om belastningen er flat eller spiss. Begge formene er informative, og en spiss profil betyr ofte at samplingsvinduet fanget planleggeraktivitet i stedet for kryptering.
mpstat -P ALL 1 5Tilordne den travle kjernen til en prosess, deretter til en tråd. Oppfølgingskjøringen nedenfor holder foreldre- og barntråder sammen, noe som betyr noe når daemonen forgrener seg per tilkobling:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10Kjernekrypto vises aldri i en teller for brukerromsprosess. Ta prøver av tråder hver for seg og sammenlign det bildet med prosessregnskapet:
top -H -b -n 1 | head -20Les socket-tellerne sist, fordi de avgjør om mer CPU i det hele tatt ville hjelpe. Gjensendinger som øker mens CPU er flat er ikke et prosessorproblem. Hold overføringen i gang mens du sampler, ellers beskriver tallene en ledig maskin:
ss -ti | grep -E 'retrans|cwnd|rtt'En kontrollert overføring, kjørt to ganger
Ledige tellere beviser ingenting, og en benchmark mot et tilfeldig endepunkt beviser svært lite. Velg én klient, én destinasjon og én representativ overføring du har lov til å kjøre, og registrer deretter gjennomstrømning og interaktiv forsinkelse i samme vindu. En gateway kan mettes mens en masskopi fortsatt fullføres, og forsinkelseskurven er det brukerne faktisk føler. Skriv overføringen, antall klienter og daemonversjonen ved siden av tallene.
Gjenta kjøringen med flere parallelle flyter. Skalering opp over flyter antyder vinduer per flyt; å holde seg flat med én fastlåst kjerne antyder behandling.
Gjenta deretter én gang til med valgfrie arbeidsbelastninger stoppet. En sikkerhetskopi, en loggsender eller en database på samme vert kan gi et travelt gjennomsnitt som ikke har noe med tunneler å gjøre. Hvis CPU fortsatt er fastlåst mens verten ellers er stille, peker bevisene på VPN-prosessen. Hvis den faller, målte du naboen, og gatewayen var aldri problemet.
Utelukk stien før du kjøper maskinvare
Stigende gjensendinger, et krympende overbelastningsvindu og økende rundturistid peker alle bort fra prosessoren. Sammenlign tunnel-MTU med sti-MTU, kontroller den underliggende lenken for tap, og bekreft at klientens egen opplastingslenke ikke er grensen. En større gateway reparerer ikke en lenke som slipper pakker, og brukere beskriver begge feilene med de samme ordene. Gjensendingstelleren skiller dem på minutter.
På en virtuell server, legg til leverandørens målinger til gjestens egne. Stjålet tid er hvordan overbooking blir synlig inne i gjesten, og ingen tuning inne i gjesten fjerner den. Gjeste tellere kan ikke se verten, så en ren gjestegraf er ikke bevis på en sunn vert.
Én endring, én måling
Velg hypotesen bevisene støtter, og endre deretter nøyaktig én støttet innstilling: antall arbeidere, et dokumentert offload-alternativ eller instansstørrelsen. OpenVPN publiserer en feilsøkingsveiledning for ytelse om den samme delingen mellom behandling og transport: Feilsøking av OpenVPN-ytelse.
Bekreft at offload-alternativet faktisk er aktivt i stedet for å stole på flagget, og kjør deretter den identiske overføringen på nytt og sammenlign likt med likt. Det er den eneste måten å skille en reell forbedring fra en stille ettermiddag. Hold et kontrollpunkt du kan gjenopprette, for ved den andre endringen mister folk oversikten over hvilken som hjalp. Én variabel per kjøring er langsom for en dag og rask for en måned.
Ikke svekk autentisering eller ciphersuiten for å få grafen til å se bedre ut. Hvis CPU fortsatt ikke følger symptomet, gå tilbake til sti- og applikasjonskontroller i stedet for å oppgradere på gjetning.