Er din VPN-gateway CPU-begrænset? Læs belastningen pr. kerne først
Gennemsnit skjuler den tråd, der betyder noget. Læs belastningen pr. kerne mod en kontrolleret overførsel, udeluk stien, og skift derefter én dokumenteret indstilling pr. kørsel.
Afgør, hvilken af de tre grænser du har nået, før du køber en større instans. Én kerne på fuld belastning, mens resten er ledige, peger på kryptoarbejde pr. flow. Alle kerner mættede under en overførsel peger på samlet kapacitet. Lav CPU med et stigende antal genoverførsler peger på stien. Hver har et andet første træk, og kun én af dem løses af en større instans.
Tre grænser, én tabel, 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 |
Læs rækkerne som diagnoser snarere end faser. En enkelt tråd på 100%, mens de andre er ledige, er det mest almindelige resultat på en gateway med én stor tunnel, fordi krypteringen af det flow kører på én kerne. Alle kerner travle under overførslen betyder, at maskinen allerede yder så meget arbejde, den kan. Lav CPU med stigende genoverførsler betyder, at processoren venter på et netværk, der bliver ved med at tabe data.
Ret dem i den rækkefølge af beviser. Spredning af flows over arbejdere hjælper det første tilfælde og gør intet for det andet. En større instans hjælper det andet og spilder penge på det første. En MTU- eller tab-rettelse er den eneste, der rører det tredje. At købe kapacitet, før du ved, hvilken række du er i er den dyre version af at gætte.
Adskil en fastlåst tråd fra en travl vært
Start med udnyttelse pr. kerne, så én fastlåst kerne ikke kan skjule sig i et gennemsnit. En enkelt kørsel under overførslen viser, om belastningen er flad eller spids. Begge former er informative, og en spids profil betyder ofte, at samplingsvinduet fangede planlæggeraktivitet i stedet for kryptering.
mpstat -P ALL 1 5Tilknyt den travle kerne til en proces, derefter til en tråd. Den efterfølgende kørsel nedenfor holder forælder- og barntråde sammen, hvilket betyder noget, når daemonen forgrener sig pr. forbindelse:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10Kernel-krypto vises aldrig i en tæller for en brugerrumsproces. Sample tråde for sig og sammenlign det billede med processens regnskab:
top -H -b -n 1 | head -20Læs socket-tællerne sidst, fordi de afgør, om mere CPU overhovedet ville hjælpe. Stigende genoverførsler, mens CPU er flad, er ikke et processorproblem. Hold overførslen kørende, mens du sampler, ellers beskriver tallene en ledig maskine:
ss -ti | grep -E 'retrans|cwnd|rtt'En kontrolleret overførsel, kørt to gange
Ledige tællere beviser intet, og en benchmark mod et tilfældigt endepunkt beviser meget lidt. Vælg én klient, én destination og én repræsentativ overførsel, du har lov til at køre, og registrér derefter gennemstrømning og interaktiv forsinkelse i samme vindue. En gateway kan mættes, mens en bulk-kopiering stadig fuldføres, og forsinkelseskurven er det, brugerne faktisk mærker. Skriv overførslen, antallet af klienter og daemonversionen ved siden af tallene.
Gentag kørslen med flere parallelle flows. Skalering op over flows tyder på vinduesstyring pr. flow; at forblive flad med én fastlåst kerne tyder på behandling.
Gentag derefter endnu en gang med valgfrie arbejdsbelastninger stoppet. En backup, en logafsender eller en database på samme vært kan give et travlt gennemsnit, der intet har med tunneler at gøre. Hvis CPU stadig er fastlåst, mens værten ellers er stille, peger beviserne på VPN-processen. Hvis den falder, målte du naboen, og gatewayen var aldrig problemet.
Udeluk stien, før du køber hardware
Stigende genoverførsler, et skrumpende overbelastningsvindue og stigende rundturistid peger alle væk fra processoren. Sammenlign tunnel-MTU med sti-MTU, kontrollér det underliggende link for tab, og bekræft, at klientens egen uplink ikke er grænsen. En større gateway reparerer ikke et link, der taber pakker, og brugerne beskriver begge fejl med de samme ord. Genoverførselstælleren adskiller dem på få minutter.
På en virtuel server skal du føje udbyderens målinger til gæstens egne. Stjålet tid er, hvordan overbookning bliver synlig inde i gæsten, og ingen tuning inde i gæsten fjerner den. Gæstens tællere kan ikke se værten, så en ren gæstegraf er ikke bevis på en sund vært.
Én ændring, én måling
Vælg den hypotese, som beviserne støtter, og ændr derefter præcis én understøttet indstilling: antal arbejdere, en dokumenteret offload-indstilling eller instansstørrelsen. OpenVPN udgiver en fejlfindingsvejledning til ydeevne om den samme opdeling mellem behandling og transport: Fejlfinding af OpenVPN-ydeevne.
Bekræft, at offload-indstillingen faktisk er aktiv i stedet for at stole på flaget, og kør derefter den identiske overførsel igen og sammenlign ens med ens. Det er den eneste måde at skelne en reel forbedring fra en stille eftermiddag. Hold et kontrolpunkt, du kan gendanne, for det er ved den anden ændring, folk mister overblikket over, hvilken der hjalp. Én variabel pr. kørsel er langsom i en dag og hurtig i en måned.
Svæk ikke godkendelse eller ciphersuiten for at få grafen til at se bedre ud. Hvis CPU stadig ikke følger symptomet, vend tilbage til sti- og applikationskontroller i stedet for at opgradere på et gæt.