VPN-serveri koormus selgitatud: kasutajad, CPU või ühendus?

Lüüs, mille koormus on 0.4, võib ikkagi iga taga oleva kasutaja jaoks roomata. Koormuse keskmine loeb ülesandeid, mida saab käivitada või mis on kinni jäänud katkematusse unne, ja neljatuumalisel hostil piisab ühest küllastunud protsessist, et suruda see 1.0 poole, samal ajal kui kolm tuuma istuvad jõude. Selle numbri lugemine varuks on lõpp-punkti valimisel kõige tavalisem viga. Tunnelit piirab tegelikult tavaliselt üks neljast asjast: üks hõivatud tuum, ühendus, selle ees olev järjekord või seansipõhine poliitika, mida keegi ei dokumenteerinud.

Koormuse keskmine loeb ülesandeid, mitte läbilaskevõimet

Kernel võtab proove jooksujärjekorrast ja sisendit-väljundit ootavate ülesannete arvust ning silub seejärel mõlemat ühe, viie ja viieteistkümne minuti jooksul. Selles määratluses ei mainita baite, pakette ega tunneleid. Host, mille salvestusruum on kinni jäänud, võib teatada kõrgest koormusest peaaegu ilma liikluseta, ja host, mis lükkab gigabiti läbi kerneli andmetee, võib teatada mugavast.

Seetõttu nõuab koormuse seostamine tunneli jõudlusega vaadet tuuma kaupa. Kui üks tuum on täis koormatud, näeb koondprotsent armatuurlaual ikkagi korralik välja:

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

Kolmas käsk on see, mis VPN-hostidel kõige rohkem loeb. Paketitöötlus kasutajaruumis OpenVPN 2.x puhul on suures osas protsessi kaupa järjestatud, nii et üks hõivatud lõim võib saada ülempiiriks, samal ajal kui armatuurlaud teatab ohtrast vabast võimsusest. Kui üks lõim hoiab aeglase perioodi ajal suuremat osa tuumast, ei ole host tervikuna alavarustatud; see on piiratud mõõtmes, mis juhtumisi loeb.

Pöörake tähelepanu ka ajastusele. Viieteistkümne minuti keskmised varjavad puhangut, mis kõne rikkus, seega pärast kaebust tehtud ekraanipilt on nõrk tõend. Võtke proove probleemi ajal ja hoidke ajatempel väljundi juures.

Ühendus ja selle ees olev järjekord

Liidese loendurid vastavad ribalaiuse küsimusele, millele CPU numbrid ei suuda. Need eristavad ka võimsust kaost, mis on erinevad tõrked erinevate lahendustega:

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

Lüli, mis on testi ajal oma määratud kiiruse lähedal, ongi seletus, ja ükski vaba CPU kogus ei muuda seda. qdisc rida lisab detaili, mis loeb interaktiivse liikluse jaoks: mahajäämus ja kaod ütlevad, kas paketid ootavad enne lahkumist järjekorras. Järjekord, mis täitub suure üleslaadimise ajal, tekitab täpselt selle sümptomi, mille eest inimesed süüdistavad kaugserverit, nimelt loidud kõned ühendusel, mis võrdlustestis ikka hästi esineb.

Kordussaadetiste loendurid püüavad juhtumi, kus paketid lahkuvad, aga ei jõua kunagi puhtalt kohale. Kui kordussaadetised aeglasel aknal kasvavad ja liides pole võimsusele lähedalgi, on probleem teel, mitte hostil, ja kolimine teise lõpp-punkti samas linnas ei aita.

Seansside arv kirjeldab nõudlust, mitte varu

Iga avalik kataloog näitab mingit arvu ühendatud kasutajaid ja peaaegu ükski ei ütle, mida need kasutajad teevad. Kakskümmend interaktiivset tööd tegevat seanssi ja neli suuri faile tõmbavat seanssi tekitavad samal riistvaral väga erinevaid koormusi. Teine muster on kasutajate arvus nähtamatu ja just see rikub õhtu. Seega loetakse seansside arvu kõige paremini vihjena nõudluse kohta, mitte kunagi väitena vaba võimsuse kohta.

Hostil, mida te kontrollite, annab olekufail puuduva mõõtme. OpenVPN kirjutab perioodilise hetktõmmise, mis sisaldab baidiloendureid kliendi kohta, ja sellest piisab, et näha, kas üks seanss vastutab kogu ühenduse eest:

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

Kaks proovi kümne sekundi vahega muudavad need kumulatiivsed loendurid kliendipõhiseks kiiruseks. See on mõõtmine, mida kasutajate arv asendab, ja nii avastate ka, et üks valesti seadistatud klient küllastab lüli igal ööl samal tunnil.

Seansipõhised piirangud peituvad poliitikas

Server võib olla jõude ja ikkagi keelduda teile ribalaiust andmast. Kiiruspiirangud, kliendipõhised ribalaiuse ülempiirid ja liikluse kujundamine rakenduvad sageli ühise nime või basseini kaupa, nii et kaks kasutajat samal lüüsil võivad saada täiesti erinevaid tulemusi. Mehhanism ei ole peen, kuid see on väljast nähtamatu, sest tunnel tõuseb mõlemal juhul tavaliselt.

Otsige kujundamist tunneli liideselt, mitte füüsiliselt. Kontrollige, kas piirang järgib kasutajat, sertifikaati või aadressibasseini. Kui teie testkonto satub piiramatusse basseini, järeldate, et server on korras ja kaebav kasutaja eksib. See järeldus on hullem kui järelduse puudumine, sest see sulgeb pileti.

Võrrelge kahte lõpp-punkti ühe fikseeritud ülesandega

Kliendipoolset katset tasub ikka teha, kuid ainult siis, kui muutujad on fikseeritud. Kasutage sama seadet, sama juurdepääsuvõrku, sama protokolli ja sama sihtfaili, seejärel korrake teise lõpp-punkti vastu sarnasel kaugusel. Kõik, mis jooksude vahel muutub, sealhulgas kellaaeg, rikub tulemuse.

Kirjutage ebaõnnestumisi üles sama hoolega kui õnnestumisi. Sari, kus kolm lõpp-punkti töötavad ja üks läheb ajapiirini, on informatiivsem kui neli kiirusenumbrit, sest see viitab tee või poliitika probleemile, mitte võimsuse omale. Käivitage iga juhtumit vähemalt kaks korda; üks aeglane proov ei tõesta jagatud võrgus midagi.

Lõpuks hoidke kogutud numbrid koos väitega, mida need toetavad. "See lõpp-punkt tegi ülekande samas aknas, kus teine takerdus" on kaitstav, samas kui "see lõpp-punkt on kiirem" kutsub esile vaidluse, mida ei võida avalehe hindega. OpenVPN 2.6 käsiraamat dokumenteerib olekufaili ja kujundusvalikud, kui vajate hostipoolseid täpseid direktiive.