VPN-palvelimen kuormitus selitettynä: käyttäjät, CPU vai uplink?

Yhdyskäytävä, jonka kuormitus on 0.4, voi silti ryömiä jokaisen takanaan olevan käyttäjän osalta. Kuormituksen keskiarvo laskee tehtäviä, jotka ovat ajettavissa tai jumissa keskeytymättömässä unessa, ja neliytimisellä isännällä yksi kyllästynyt prosessi riittää työntämään sen kohti 1.0, kun kolme ydintä istuu toimettomana. Tuon luvun lukeminen varaan on yleisin virhe päätepisteen valinnassa. Tunnelista todella rajoittaa yleensä yksi neljästä asiasta: yksi kiireinen ydin, uplink-yhteys, sen edessä oleva jono tai istuntokohtainen käytäntö, jota kukaan ei dokumentoinut.

Kuormituksen keskiarvo laskee tehtäviä, ei läpimenoa

Ydin ottaa näytteitä suoritusjonosta ja syöttöä sekä tulostetta odottavien tehtävien määrästä ja tasoittaa sitten molemmat yhden, viiden ja viidentoista minuutin yli. Mikään tuossa määritelmässä ei mainitse tavuja, paketteja tai tunneleita. Isäntä, jonka tallennustila on jumissa, voi raportoida korkean kuormituksen lähes ilman liikennettä, ja isäntä, joka työntää gigabitin ytimen datapolun läpi, voi raportoida mukavan.

Siksi kuormituksen korreloiminen tunnelin suorituskykyyn vaatii näkymän ydintä kohden. Jos yksi ydin on kiinni täydessä kuormassa, koontinäytön kokonaisprosentti näyttää silti hyvältä:

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

Kolmas komento on se, jolla on eniten merkitystä VPN-isännillä. Käyttäjäavaruuden paketinkäsittely OpenVPN 2.x:ssä on pitkälti sarjallistettu prosessia kohden, joten yksi kiireinen säie voi nousta katoksi, kun koontinäyttö raportoi runsaasti joutilasta kapasiteettia. Jos yksi säie pitää suurimman osan ytimestä hitaan jakson aikana, isäntä ei ole kokonaisuutena alimitoitettu; se on rajoittunut siinä ulottuvuudessa, jolla sattuu olemaan merkitystä.

Kiinnitä huomiota myös ajoitukseen. Viidentoista minuutin keskiarvot kätkevät purskeen, joka pilasi puhelun, joten valituksen jälkeen otettu kuvakaappaus on heikko todiste. Ota näytteitä ongelman aikana ja säilytä aikaleima tulosteen mukana.

Uplink-yhteys ja sen edessä oleva jono

Liitäntälaskurit vastaavat kaistanleveyskysymykseen, johon CPU-luvut eivät pysty. Ne erottavat myös kapasiteetin häviöstä, ja nämä ovat eri vikoja, joilla on eri korjaukset:

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

Linkki, joka on testisi aikana lähellä sille varattua nopeutta, on selitys, eikä mikään määrä vapaata CPU:ta muuta sitä. qdisc-rivi lisää yksityiskohdan, jolla on merkitystä interaktiiviselle liikenteelle: ruuhkautuminen ja pudotukset kertovat, odottavatko paketit jonossa ennen lähtöä. Jono, joka täyttyy suuren latauksen alla, tuottaa juuri sen oireen, jonka ihmiset laittavat etäpalvelimen syyksi, eli hitaat puhelut yhteydellä, joka vielä testissä suoriutuu hyvin.

Uudelleenlähetyslaskurit nappaavat tapauksen, jossa paketit lähtevät mutta eivät koskaan saavu puhtaasti. Jos uudelleenlähetykset kasvavat hitaassa ikkunassa eikä liitäntä ole lähelläkään kapasiteettiaan, ongelma on polussa eikä isännällä, eikä siirtyminen toiseen päätepisteeseen samassa kaupungissa auta.

Istuntojen määrä kuvaa kysyntää, ei varaa

Jokainen julkinen hakemisto näyttää jonkin määrän yhdistettyjä käyttäjiä, eikä juuri mikään niistä kerro, mitä nuo käyttäjät tekevät. Kaksikymmentä interaktiivista työtä tekevää istuntoa ja neljä suuria tiedostoja imevää istuntoa tuottavat hyvin erilaiset kuormitukset samalla laitteistolla. Toinen kuvio on näkymätön käyttäjämäärässä, ja juuri se pilaa illan. Siksi istuntoluku kannattaa lukea vihjeenä kysynnästä, ei koskaan väitteenä vapaasta kapasiteetista.

Isännällä, jota hallitset, tilatiedosto antaa puuttuvan ulottuvuuden. OpenVPN kirjoittaa säännöllisen tilannekuvan, joka sisältää tavulaskurit asiakasta kohden, ja se riittää siihen, että näet, onko yksi istunto vastuussa koko uplink-yhteydestä:

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

Kaksi näytettä kymmenen sekunnin välein muuttaa nuo kumulatiiviset laskurit asiakaskohtaiseksi nopeudeksi. Se on mittaus, jota käyttäjämäärä korvaa, ja samalla tavalla huomaat, että yksi väärin määritetty asiakas kyllästää linkin joka yö samaan aikaan.

Istuntokohtaiset rajat piiloutuvat käytäntöön

Palvelin voi olla joutilas ja silti kieltäytyä antamasta sinulle kaistanleveyttä. Nopeusrajat, asiakaskohtaiset kaistanleveyskatot ja liikenteen muotoilu kohdistetaan usein yhteisen nimen tai altaan mukaan, joten kaksi käyttäjää samalla yhdyskäytävällä voivat saada täysin erilaisia tuloksia. Mekanismi ei ole hienovarainen, mutta se on näkymätön ulkopuolelta, koska tunneli nousee normaalisti molemmissa tapauksissa.

Etsi muotoilua tunnelin liitännästä, ei fyysisestä. Tarkista, seuraako raja käyttäjää, varmennetta vai osoiteallasta. Jos testitilisi osuu rajoittamattomaan altaaseen, päättelet, että palvelin on kunnossa ja valittava käyttäjä on väärässä. Se johtopäätös on huonompi kuin ei johtopäätöstä, koska se sulkee tiketin.

Vertaa kahta päätepistettä yhdellä kiinteällä tehtävällä

Asiakaspuolen koe kannattaa yhä tehdä, mutta vain jos muuttujat on kiinnitetty. Käytä samaa laitetta, samaa käyttöverkkoyhteyttä, samaa protokollaa ja samaa kohdetiedostoa ja toista sitten toista päätepistettä vastaan samankaltaisella etäisyydellä. Kaikki ajojen välillä muuttuva, mukaan lukien vuorokaudenaika, saastuttaa tuloksen.

Kirjaa epäonnistumiset yhtä huolellisesti kuin onnistumiset. Sarja, jossa kolme päätepistettä toimii ja yksi aikakatkaistaan, on informatiivisempi kuin neljä nopeuslukua, koska se osoittaa polun tai käytännön ongelmaan eikä kapasiteetin. Aja jokainen tapaus vähintään kahdesti; yksi hidas näyte ei todista jaetussa verkossa mitään.

Lopuksi, säilytä keräämäsi luvut yhdessä sen väitteen kanssa, jota ne tukevat. "Tämä päätepiste hoiti siirron samassa ikkunassa, jossa toinen jumittui" on puolustettavissa, kun taas "tämä päätepiste on nopeampi" kutsuu väittelyyn, jota et voi voittaa etusivun pisteillä. OpenVPN 2.6 -käsikirja dokumentoi tilatiedoston ja muotoiluvaihtoehdot, jos tarvitset tarkat direktiivit isäntäpuolelle.