Belastning på VPN-servere forklaret: brugere, CPU eller uplink?

En gateway med en belastning på 0.4 kan stadig kravle for hver bruger bag den. Gennemsnitsbelastningen tæller opgaver, der kan køre eller hænger fast i uafbrydelig søvn, og på en vært med fire kerner er én mættet proces nok til at skubbe den mod 1.0, mens tre kerner sidder ledige. At læse det tal som frirum er den mest almindelige fejl ved valg af endepunkt. Det, der faktisk begrænser en tunnel, er som regel en af fire ting: én travl kerne, uplinken, køen foran den eller en politik pr. session, som ingen har dokumenteret.

Gennemsnitsbelastning tæller opgaver, ikke gennemstrømning

Kernen sampler køen af kørbare opgaver og antallet af opgaver, der venter på I/O, og glatter derefter begge over et, fem og femten minutter. Intet i den definition nævner bytes, pakker eller tunneler. En vært med fastlåst lager kan rapportere høj belastning næsten uden trafik, og en vært, der presser en gigabit gennem kernens datasti, kan rapportere en behagelig en.

At korrelere belastning med tunnelens ydeevne kræver derfor et blik pr. kerne. Hvis én kerne er spændt fast, vil den samlede procentdel på et dashboard stadig se fin ud:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

Den tredje kommando er den, der betyder mest på VPN-værter. Pakkebehandling i brugerland i OpenVPN 2.x er i vid udstrækning serialiseret pr. proces, så en enkelt travl tråd kan blive loftet, mens dashboardet rapporterer rigelig ledig kapacitet. Hvis én tråd holder det meste af en kerne i din langsomme periode, er værten ikke underdimensioneret samlet set; den er begrænset i den dimension, der tilfældigvis betyder noget.

Læg også mærke til timingen. Femtenminuttersgennemsnit skjuler det udbrud, der ødelagde et opkald, så et skærmbillede taget efter klagen er svagt bevis. Tag prøver under problemet, og gem tidsstemplet sammen med outputtet.

Uplinken og køen foran den

Grænsefladetællere besvarer båndbreddespørgsmålet, som CPU-tal ikke kan. De adskiller også kapacitet fra tab, som er forskellige fejl med forskellige løsninger:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Et link, der under din test er tæt på sin tildelte hastighed, er forklaringen, og ingen mængde ledig CPU ændrer det. qdisc-linjen tilføjer den detalje, der betyder noget for interaktiv trafik: efterslæb og tab fortæller, om pakker venter i en kø, før de forlader værten. En kø, der fyldes under en stor upload, producerer præcis det symptom, folk giver den fjernede server skylden for, altså sløve opkald på en forbindelse, der stadig måler fint.

Genforsendelsestællere fanger det tilfælde, hvor pakker forlader værten, men aldrig ankommer rent. Hvis genforsendelser stiger i det langsomme vindue, og grænsefladen slet ikke er tæt på kapacitet, ligger problemet i stien og ikke på værten, og det hjælper ikke at flytte til et andet endepunkt i samme by.

Sessionsantal beskriver efterspørgsel, ikke frirum

Hvert offentligt katalog viser et eller andet antal tilsluttede brugere, og næsten ingen af dem fortæller, hvad disse brugere laver. Tyve sessioner med interaktivt arbejde og fire sessioner, der henter store filer, giver meget forskellige belastninger på den samme hardware. Det andet mønster er usynligt i et brugertal, og det er netop det, der ødelægger en aften. Et sessionsnummer læses derfor bedst som et vink om efterspørgsel, aldrig som en udtalelse om ledig kapacitet.

På en vært, du kontrollerer, giver statusfilen den manglende dimension. OpenVPN skriver et regelmæssigt øjebliksbillede med bytetællere pr. klient, og det er nok til at se, om én session er ansvarlig for hele uplinken:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

To prøver ti sekunder fra hinanden forvandler de kumulative tal til en hastighed pr. klient. Det er den måling, et brugertal står i stedet for, og det er også sådan, du opdager, at én fejlkonfigureret klient mætter linket hver nat på samme tid.

Grænser pr. session gemmer sig i politikken

En server kan være ledig og alligevel nægte at give dig båndbredde. Hastighedsgrænser, båndbreddeloft pr. klient og trafikformning anvendes ofte pr. fælles navn eller pr. pulje, så to brugere på samme gateway kan få vidt forskellige resultater. Mekanismen er ikke subtil, men den er usynlig udefra, fordi tunnelen kommer op normalt i begge tilfælde.

Led efter formning på tunnelgrænsefladen og ikke på den fysiske. Tjek, om grænsen følger brugeren, certifikatet eller adressepuljen. Hvis din testkonto lander i den ubegrænsede pulje, vil du konkludere, at serveren er fin, og at den klagende bruger tager fejl. Den konklusion er værre end ingen konklusion, fordi den lukker sagen.

Sammenlign to endepunkter med én fast opgave

Forsøget på klientsiden er stadig værd at køre, men kun hvis variablerne er låst. Brug samme enhed, samme adgangsnetværk, samme protokol og samme destinationsfil, og gentag derefter mod et andet endepunkt i lignende afstand. Alt, der ændrer sig mellem kørsler, inklusive tidspunktet på dagen, forurener resultatet.

Noter fejl lige så omhyggeligt som succeser. En serie, hvor tre endepunkter virker og et timer ud, er mere informativ end fire hastighedstal, fordi den peger på et sti- eller politikproblem frem for et kapacitetsproblem. Kør hvert tilfælde mindst to gange; en enkelt langsom prøve beviser intet på et delt netværk.

Til sidst: gem de tal, du har samlet, sammen med den påstand, de understøtter. "Dette endepunkt klarede overførslen i samme vindue, hvor det andet gik i stå" er forsvarligt, mens "dette endepunkt er hurtigere" indbyder til en diskussion, du ikke kan vinde med en score fra en hjemmeside. OpenVPN 2.6-manualen dokumenterer statusfilen og formningsmulighederne, hvis du har brug for de præcise direktiver til værtssiden.