Last på VPN-tenarar forklart: brukarar, CPU eller uplink?

Ein gateway med last på 0.4 kan framleis krype for kvar brukar bak han. Gjennomsnittslasten tel oppgåver som kan køyrast eller som står fast i uavbrote søvn, og på ein vert med fire kjernar er éin metta prosess nok til å skyve han mot 1.0 medan tre kjernar sit ledige. Å lese det talet som ledig kapasitet er den vanlegaste feilen ved val av endepunkt. Det som faktisk avgrensar ein tunnel, er som regel éin av fire ting: éin opptatt kjerne, uplinken, køen framfor han eller ein policy per økt som ingen har dokumentert.

Gjennomsnittslasten tel oppgåver, ikkje gjennomstrøyming

Kjernen samplar køen av køyrbare oppgåver og talet på oppgåver som ventar på inn- og utdata, og glattar deretter begge over eitt, fem og femten minutt. Ingenting i den definisjonen nemner byte, pakkar eller tunnelar. Ein vert med fastlåst lagring kan rapportere høg last nesten utan trafikk, og ein vert som pressar ein gigabit gjennom datastien til kjernen kan rapportere ein komfortabel.

Å korrelere last med tunnelyting krev difor eit blikk per kjerne. Viss éin kjerne er fullt belasta, vil den samla prosenten på eit dashbord framleis sjå fin ut:

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

Den tredje kommandoen er den som tyder mest på VPN-vertar. Pakkehandsaming i brukarland i OpenVPN 2.x er i stor grad serialisert per prosess, så éin travel tråd kan bli taket medan dashbordet rapporterer rikeleg ledig kapasitet. Viss éin tråd held mesteparten av ein kjerne i den langsame perioden din, er verten ikkje underdimensjonert samla sett; han er avgrensa i den dimensjonen som tilfeldigvis tyder noko.

Legg merke til tidspunktet òg. Femtenminuttsgjennomsnitt skjuler utbrotet som øydela ein samtale, så eit skjermbilete teke etter klaga er svakt prov. Ta prøvar medan problemet pågår, og ta vare på tidsstempelet saman med utdataa.

Uplinken og køen framfor han

Grensesnittleiarane svarar på bandbreiddespørsmålet som CPU-tal ikkje kan. Dei skil òg kapasitet frå tap, som er ulike feil med ulike løysingar:

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

Ein lenke som under testen er nær den tildelte hastigheita si, er forklaringa, og inga mengd ledig CPU endrar det. qdisc-linja legg til detaljen som tyder noko for interaktiv trafikk: etterslep og tap fortel om pakkar ventar i ein kø før dei forlèt verten. Ein kø som fyllest under ein stor opplasting, gjev nøyaktig det symptomet folk gjev den eksterne tenaren skulda for, altså trege samtalar på ei tilkopling som framleis måler godt.

Vidaresendingstejlarar fangar tilfellet der pakkar forlèt verten, men aldri kjem fram reint. Viss vidaresendingane aukar i det langsame vindauget og grensesnittet er langt frå kapasitet, ligg problemet i banen og ikkje på verten, og det hjelper ikkje å flytte til eit anna endepunkt i same by.

Sesjonstal skildrar etterspurnad, ikkje ledig kapasitet

Kvar offentleg katalog viser eit visst tal på tilkopla brukarar, og nesten ingen av dei fortel kva desse brukarane gjer. Tjue økter med interaktivt arbeid og fire økter som hentar store filer gjev svært ulike laster på same maskinvare. Det andre mønsteret er usynleg i eit brukartal, og det er nettopp det som øydelegg ein kveld. Difor blir eit sesjonstal lese best som eit hint om etterspurnad, aldri som ei utsegn om ledig kapasitet.

På ein vert du kontrollerer, gjev statusfila den manglande dimensjonen. OpenVPN skriv eit regelmessig augeblinksbilete med byteteljarar per klient, og det er nok til å sjå om éi økt er ansvarleg for heile uplinken:

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

To prøvar ti sekund frå kvarandre gjer dei kumulative tala om til ein hastigheit per klient. Det er målinga eit brukartal står i staden for, og det er òg slik du oppdagar at éin feilkonfigurert klient mettar lenka kvar natt på same tid.

Grenser per økt gøymer seg i policyen

Ein tenar kan vere ledig og likevel nekte å gje deg bandbreidde. Hastigheitsgrenser, bandbreiddetak per klient og trafikkforming blir ofte brukte per felles namn eller per pool, så to brukarar på same gateway kan få svært ulike resultat. Mekanismen er ikkje subtil, men han er usynleg utanfrå fordi tunnelen kjem opp normalt i begge tilfelle.

Sjå etter forming på tunnelgrensesnittet og ikkje på det fysiske. Sjekk om grensa følgjer brukaren, sertifikatet eller adressepoolen. Viss testkontoen din hamnar i poolen utan tak, vil du konkludere med at tenaren er fin og at brukaren som klagar tar feil. Den konklusjonen er verre enn ingen konklusjon, fordi han lukkar saka.

Samanlikn to endepunkt med éi fast oppgåve

Forsøket på klientsida er framleis verdt å køyre, men berre viss variablane er låste. Bruk same eining, same aksessnett, same protokoll og same målfil, og gjer det så om att mot eit andre endepunkt i liknande avstand. Alt som endrar seg mellom køyringane, inkludert tida på døgnet, forureinar resultatet.

Noter feil like nøye som suksessar. Ein serie der tre endepunkt verkar og eitt går ut på tid, er meir informativ enn fire hastigheitstal, fordi han peikar på eit bane- eller policyproblem framfor eit kapasitetsproblem. Køyr kvart tilfelle minst to gonger; éin enkelt treg prøve provar ingenting på eit delt nettverk.

Til slutt: Ta vare på tala du samla inn saman med påstanden dei støttar. "Dette endepunktet fullførte overføringa i same vindauge som det andre stoppa opp" er forsvarleg, medan "dette endepunktet er raskare" inviterer til ein diskusjon du ikkje kan vinne med ein skår frå ei heimeside. OpenVPN 2.6-handboka dokumenterer statusfila og formingsvala viss du treng dei nøyaktige direktiva for vertssida.