Er VPN-gatewayen din CPU-bunden? Les lasten per kjerne først

Avgjer kva av dei tre grensene du har nådd før du kjøper ein større instans. Éin kjerne fullasta medan dei andre er ledige peikar på kryptarbeid per flyt. Alle kjernar metta under ei overføring peikar på samla kapasitet. Låg CPU med eit stigande tal gjensendingar peikar på stien. Kvar har eit anna første trekk, og berre éin av dei blir løyst av ein større instans.

Tre grenser, éin tabell, tre rettingar

Les radene som diagnosar, ikkje som trinn. Éin tråd på 100% medan dei andre er ledige er det vanlegaste resultatet på ein gateway med éin stor tunnel, fordi krypteringa av den flyten køyrer på éin kjerne. Alle kjernar opptekne under overføringa betyr at maskinen allereie gjer så mykje arbeid han kan. Låg CPU med stigande gjensendingar betyr at prosessoren ventar på eit nettverk som fortset å miste data.

Rett dei i den rekkjefølgja av prov. Å spreie flytar over arbeidarar hjelper det første tilfellet og gjer ingenting for det andre. Ein større instans hjelper det andre og sløser pengar på det første. Ei MTU- eller tapretting er den einaste som rører det tredje. Å kjøpe kapasitet før du veit kva rad du er i er den dyre versjonen av å gjette.

Skil ein fastlåst tråd frå ein travel vert

Start med utnytting per kjerne, slik at éin fastlåst kjerne ikkje kan gøyme seg i eit gjennomsnitt. Éi køyring under overføringa viser om lasta er flat eller spiss. Begge formene er informative, og ein spiss profil betyr ofte at samplingsvindauget fanga planleggjaraktivitet i staden for kryptering.

mpstat -P ALL 1 5

Tildel den travle kjernen til ein prosess, deretter til ein tråd. Oppfølgingskøyringa nedanfor held foreldre- og barntrådar saman, noko som betyr noko når daemonen forgreinar seg per tilkopling:

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

Kjernes krypto visest aldri i ein teljar for brukarromsprosess. Ta prøvar av trådar kvar for seg og samanlikn det bilete med prosessrekneskapen:

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

Les socket-teljarane sist, fordi dei avgjer om meir CPU i det heile ville hjelpe. Gjensendingar som aukar medan CPU er flat er ikkje eit prosessorproblem. Hald overføringa i gang medan du samplar, elles skildrar tala ein ledig maskin:

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

Ei kontrollert overføring, køyrd to gonger

Ledige teljarar beviser ingenting, og ein benchmark mot eit tilfeldig endepunkt beviser svært lite. Vel éin klient, éin destinasjon og éi representativ overføring du har lov til å køyre, og registrer deretter gjennomstrøyming og interaktiv forseinking i same vindauge. Ein gateway kan mettast medan ein masskopi enno fullførast, og forseinkingskurva er det brukarane faktisk kjenner. Skriv overføringa, talet på klientar og daemonversjonen ved sida av tala.

Gjenta køyringa med fleire parallelle flytar. Skalering opp over flytar tyder på vindauge per flyt; å halde seg flat med éin fastlåst kjerne tyder på handsaming.

Gjenta deretter éin gong til med valfrie arbeidslaster stoppa. Ein sikkerheitskopi, ein loggsendar eller ein database på same vert kan gje eit travelt gjennomsnitt som ikkje har noko med tunnelar å gjere. Viss CPU framleis er fastlåst medan verten elles er stille, peikar prova på VPN-prosessen. Viss han fell, målte du naboen, og gatewayen var aldri problemet.

Utelukk stien før du kjøper maskinvare

Stigande gjensendingar, eit krympande overbelastningsvindauge og aukande rundturistid peikar alle bort frå prosessoren. Samanlikn tunnel-MTU med sti-MTU, kontroller den underliggjande lenkja for tap, og stadfest at klienten si eiga opplastingslenkje ikkje er grensa. Ein større gateway reparerer ikkje ei lenkje som slepp pakkar, og brukarar skildrar begge feila med dei same orda. Gjensendingsteljaren skil dei på minutt.

På ein virtuell server, legg til målingane til leverandøren til dei gjesten har sjølv. Stolen tid er korleis oversal blir synleg inne i gjesten, og inga tuning inne i gjesten fjernar han. Gjesteteljarar kan ikkje sjå verten, så ein rein gjestegraf er ikkje prov på ein sunn vert.

Éi endring, éi måling

Vel hypotesen prova støttar, og endre deretter nøyaktig éi støtta innstilling: talet på arbeidarar, eit dokumentert offload-alternativ eller storleiken på instansen. OpenVPN publiserer ei feilsøkingsrettleiing for yting om den same delinga mellom handsaming og transport: Feilsøking av OpenVPN-yting.

Stadfest at offload-alternativet faktisk er aktivt i staden for å stole på flagget, og køyr deretter den identiske overføringa på nytt og samanlikn likt med likt. Det er den einaste måten å skilje ei reell betring frå ein stille ettermiddag. Hald eit kontrollpunkt du kan gjenopprette, for ved den andre endringa mistar folk oversynet over kva som hjelpte. Éin variabel per køyring er langsam for ein dag og rask for ein månad.

Ikkje svekk autentisering eller ciphersuiten for å få grafen til å sjå betre ut. Viss CPU framleis ikkje følgjer symptomet, gå tilbake til sti- og applikasjonskontrollar i staden for å oppgradere på gjetting.