Är din VPN-gateway CPU-bunden? Läs belastningen per kärna först

Avgör vilken av de tre gränserna du har nått innan du köper en större instans. En kärna fullbelastad medan resten är ledig pekar på kryptoarbete per flöde. Alla kärnor mättade under en överföring pekar på samlad kapacitet. Låg CPU med ett stigande antal omsändningar pekar på vägen. Var och en har ett annat första drag, och bara en av dem löses av en större instans.

Tre gränser, en tabell, tre åtgärder

Läs raderna som diagnoser, inte som steg. En enda tråd på 100% medan de andra är lediga är det vanligaste resultatet på en gateway med en stor tunnel, eftersom krypteringen av det flödet körs på en kärna. Alla kärnor upptagna under överföringen betyder att maskinen redan gör så mycket arbete den kan. Låg CPU med stigande omsändningar betyder att processorn väntar på ett nätverk som fortsätter tappa data.

Åtgärda dem i den ordningen av bevis. Att sprida flöden över arbetare hjälper det första fallet och gör inget för det andra. En större instans hjälper det andra och slösar pengar på det första. En MTU- eller förluståtgärd är den enda som rör det tredje. Att köpa kapacitet innan du vet vilken rad du är i är den dyra versionen av att gissa.

Skilj en fastlåst tråd från en upptagen värd

Börja med utnyttjande per kärna, så att en fastlåst kärna inte kan gömma sig i ett medelvärde. En enda körning under överföringen visar om belastningen är jämn eller spetsig. Båda formerna är informativa, och en spetsig profil betyder ofta att samplingsfönstret fångade schemaläggarens aktivitet i stället för kryptering.

mpstat -P ALL 1 5

Tilldela den upptagna kärnan en process och sedan en tråd. Uppföljningskörningen nedan håller föräldra- och barntrådar tillsammans, vilket spelar roll när daemonen forgrenar sig per anslutning:

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

Kärnkrypto syns aldrig i en räknare för användarrymdsprocess. Sampla trådar separat och jämför den bilden med processredovisningen:

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

Läs socketräknarna sist, eftersom de avgör om mer CPU alls skulle hjälpa. Omsändningar som ökar medan CPU är jämn är inte ett processorproblem. Håll överföringen igång medan du samplar, annars beskriver siffrorna en ledig maskin:

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

En kontrollerad överföring, körd två gånger

Lediga räknare bevisar inget, och en benchmark mot en slumpmässig ändpunkt bevisar väldigt lite. Välj en klient, en destination och en representativ överföring du får köra, och registrera sedan genomströmning och interaktiv fördröjning i samma fönster. En gateway kan mättas medan en masskopia fortfarande slutförs, och fördröjningskurvan är det användarna faktiskt känner. Skriv överföringen, antalet klienter och daemonversionen bredvid siffrorna.

Upprepa körningen med flera parallella flöden. Skalning över flöden antyder fönster per flöde; att förbli jämn med en fastlåst kärna antyder bearbetning.

Upprepa sedan en gång till med valfria arbetsbelastningar stoppade. En säkerhetskopia, en loggsändare eller en databas på samma värd kan ge ett upptaget medelvärde som inte har något med tunnlar att göra. Om CPU fortfarande är fastlåst medan värden i övrigt är tyst, pekar bevisen på VPN-processen. Om den faller mätte du grannen, och gatewayen var aldrig problemet.

Uteslut vägen innan du köper hårdvara

Stigande omsändningar, ett krympande överbelastningsfönster och ökande rundturstid pekar alla bort från processorn. Jämför tunnelns MTU med vägens MTU, kontrollera den underliggande länken för förluster och bekräfta att klientens egen upplänk inte är gränsen. En större gateway reparerar inte en länk som tappar paket, och användare beskriver båda felen med samma ord. Omsändningsräknaren skiljer dem på minuter.

På en virtuell server, lägg till leverantörens mätvärden till gästens egna. Stulen tid är hur överbokning blir synlig inne i gästen, och ingen trimning inne i gästen tar bort den. Gästens räknare kan inte se värden, så en ren gästgraf är inte bevis på en frisk värd.

En ändring, en mätning

Välj hypotesen som bevisen stöder och ändra sedan exakt en stödd inställning: antal arbetare, ett dokumenterat offload-alternativ eller instansens storlek. OpenVPN publicerar en felsökningsguide för prestanda om samma uppdelning mellan bearbetning och transport: Felsökning av OpenVPN-prestanda.

Bekräfta att offload-alternativet faktiskt är aktivt i stället för att lita på flaggan, kör sedan om den identiska överföringen och jämför lika med lika. Det är det enda sättet att skilja en verklig förbättring från en tyst eftermiddag. Behåll en kontrollpunkt du kan återställa, för vid den andra ändringen tappar folk räkningen på vilken som hjälpte. En variabel per körning är långsam i en dag och snabb i en månad.

Försvaga inte autentisering eller chiffersviten för att få grafen att se bättre ut. Om CPU fortfarande inte följer symptomet, gå tillbaka till väg- och applikationskontroller i stället för att uppgradera på en gissning.