Skýring á álagi VPN-þjóns: notendur, CPU eða uppstreymisrás?

Hlið á 0.4 álagi getur samt skrið fyrir hvern notanda bak við það. Meðalálag telur verk sem eru keyranleg eða föst í órofa svefni, og á fjögurra kjarna hýsli er eitt mettað ferli nóg til að ýta því í átt að 1.0 á meðan þrír kjarnar sitja aðgerðalausir. Að lesa þá tölu sem varasjóð er algengasta mistökið við val á endapunkti. Það sem takmarkar göng í raun er venjulega eitt af fjórum hlutum: einn upptekinn kjarni, uppstreymisrásin, biðröðin fyrir framan hana eða stefna fyrir hverja lotu sem enginn skjalfesti.

Meðalálag telur verk, ekki afköst

Kjarninn tekur sýnishorn af keyrslubiðröðinni og fjölda verka sem bíða inntaks og úttaks, og sléttir svo hvort tveggja yfir eina, fimm og fimmtán mínútur. Ekkert í þeirri skilgreiningu nefnir bæti, pakka eða göng. Hýsill með fastkeyrt geymslugetu getur tilkynnt hátt álag nánast án umferðar, og hýsill sem þrýstir gígabiti í gegnum gagnaleið kjarnans getur tilkynnt þægilegt.

Að tengja álag við afköst ganga krefst því sýn á hvern kjarna. Ef einn kjarni er fastur mun heildarhlutfallið á mælaborði samt líta vel út:

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

Þriðja skipunin er sú sem mestu skiptir á VPN-hýslum. Vinnsla pakka í notendarými í OpenVPN 2.x er að mestu raðgerð fyrir hvert ferli, svo einn upptekinn þráður getur orðið þakið á meðan mælaborðið tilkynnir næga lausa getu. Ef einn þráður heldur mestum hluta kjarna á hæga tímabilinu þínu er hýsillinn ekki vanmetinn í heild; hann er takmarkaður í þeirri vídd sem skyldi skipta máli.

Veittu tímasetningunni athygli líka. Meðaltöl fimmtán mínútna fela sprenginguna sem eyðilagði símtal, svo skjáskot sem tekið er eftir kvörtunina er veik sönnun. Taktu sýnishorn á meðan vandamálið varir og geymdu tímaritið með úttakinu.

Uppstreymisrásin og biðröðin fyrir framan hana

Teljarar viðmótsins svara bandvíddarspurningunni sem tölur CPU geta ekki svarað. Þeir aðskilja líka getu frá tapi, sem eru mismunandi bilanir með mismunandi lagfæringum:

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

Tenging sem er nálægt úthlutuðum hraða sínum í prófinu þínu er skýringin, og engin magn af lausu CPU breytir því. qdisc-línan bætir við smáatriðinu sem skiptir máli fyrir gagnvirka umferð: uppsöfnun og tap segja þér hvort pakkar bíða í biðröð áður en þeir fara. Biðröð sem fyllist undir stóru upphleðslu framleiðir nákvæmlega þau einkenni sem fólk kennir fjarlæga þjóninum um, það er hæg símtöl á tengingu sem stendur sig enn vel í mælingum.

Teljarar endursendinga grípa tilvikið þar sem pakkar fara en koma aldrei hreinir. Ef endursendingar aukast í hæga glugganum og viðmótið er hvergi nálægt getu býr vandamálið í leiðinni en ekki á hýslinum, og að flytja á annan endapunkt í sömu borg mun ekki hjálpa.

Lotutölur lýsa eftirspurn, ekki varasjóði

Sérhver opinber skrá sýnir einhvern fjölda tengdra notenda, og nánast enginn þeirra segir þér hvað þessir notendur eru að gera. Tuttugu lotur í gagnvirku starfi og fjórar lotur sem sækja stórar skrár framleiða mjög mismunandi álag á sama vélbúnaði. Annað mynstrið er ósýnilegt í notendatölu, og það er það sem eyðileggur kvöld. Því er best að lesa lotutölu sem vísbendingu um eftirspurn, aldrei sem fullyrðingu um lausa getu.

Á hýsli sem þú stýrir gefur stöðuskráin vantaða vídd. OpenVPN skrifar reglulegt skyndimynd sem inniheldur bætateljara fyrir hvern biðlara, og það nægir til að sjá hvort ein lota ber ábyrgð á allri uppstreymisrásinni:

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

Tvö sýnishorn tíu sekúndum síðan á milli snúa þessum uppsöfnuðu teljurum í hraða á hvern biðlara. Það er mælingin sem notendatala stendur í staðinn fyrir, og þannig uppgötvar þú líka að einn rangstilltur biðlari mettar tenginguna á hverju kvöldi á sama tíma.

Takmörk fyrir hverja lotu leynast í stefnunni

Þjónn getur verið aðgerðalaus og samt neitað að gefa þér bandvídd. Hraðatakmörk, bandvíddarþök fyrir hvern biðlara og umferðarmótun eru oft beitt fyrir sameiginlegt nafn eða fyrir laug, svo tveir notendur á sama hliði geta fengið mjög mismunandi niðurstöður. Aðferðin er ekki fíngerð, en hún er ósýnileg að utan því göngin koma upp eðlilega í báðum tilvikum.

Leitaðu að mótun á viðmóti ganganna en ekki á því líkamlega. Athugaðu hvort takmörkið fylgi notandanum, skírteininu eða vistfangalauginni. Ef prófunarinnskráningin þín lendir í lauginni án þaks munt þú álykta að þjónninn sé í lagi og notandinn sem kvartar hafi rangt fyrir sér. Sú ályktun er verri en engin ályktun, því hún lokar miðanum.

Berðu saman tvo endapunkta með einu föstu verki

Tilraunin á biðlarahliðinni er enn þess virði að framkvæma, en aðeins ef breyturnar eru festar. Notaðu sama tæki, sama aðgangsnet, sama samskiptareglur og sama áfangaskrá, endurtaktu svo gagnvart öðrum endapunkti á svipuðu færi. Allt sem breytist milli keyrslna, þar á meðal tími dagsins, mengar niðurstöðuna.

Skráðu mistök jafn vandlega og árangur. Röð þar sem þrír endapunktar virka og einn rennur út á tíma er upplýsandi en fjórar hraðatölur, því hún bendir á vandamál í leið eða stefnu en ekki í getu. Keyrðu hvert tilvik að minnsta kosti tvisvar; eitt hægt sýnishorn sannar ekkert á sameiginlegu neti.

Að lokum skaltu geyma tölurnar sem þú safnaðir með þeirri fullyrðingu sem þær styðja. "Þessi endapunktur kláraði flutninginn í sama glugga og hinn stöðvaðist í" er verjandi, á meðan "þessi endapunktur er hraðari" býður upp á rifrildi sem þú getur ekki unnið með stigum af forsíðu. Handbók OpenVPN 2.6 skjalfestir stöðuskrána og mótunarvalkostina ef þú þarft nákvæmu skipanirnar fyrir hýsilhliðina.