VPN servera slodze izskaidrota: lietotāji, CPU vai augšupielādes kanāls?

Vārteja ar slodzi 0.4 joprojām var līst katram lietotājam aiz tās. Vidējā slodze skaita uzdevumus, kurus var izpildīt vai kuri iesprūduši nepārtrauktā miegā, un četru kodolu resursdatorā ar vienu piesātinātu procesu pietiek, lai to virzītu pretī 1.0, kamēr trīs kodoli sēž dīkā. Šo skaitli lasīt kā rezervi ir visizplatītākā kļūda, izvēloties galapunktu. To, kas tuneli faktiski ierobežo, parasti nosaka viena no četrām lietām: viens aizņemts kodols, augšupielādes kanāls, rinda tā priekšā vai sesijas politika, kuru neviens nav dokumentējis.

Vidējā slodze skaita uzdevumus, nevis caurlaidspēju

Kodols ņem izpildes rindas un ievades-izvades gaidīšanā esošo uzdevumu skaita paraugus, pēc tam abus izlīdzina vienā, piecās un piecpadsmit minūtēs. Nekas šajā definīcijā nemin baitus, paketes vai tuneļus. Resursdators ar iesprūdušu krātuvi var ziņot par augstu slodzi gandrīz bez trafika, un resursdators, kas spiež gigabitu caur kodola datu ceļu, var ziņot par ērtu slodzi.

Tāpēc slodzes saistīšanai ar tuneļa veiktspēju vajadzīgs skats pa kodoliem. Ja viens kodols ir pilnībā noslogots, kopējais procents informācijas panelī joprojām izskatīsies labi:

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

Trešā komanda ir tā, kas VPN resursdatoros ir vissvarīgākā. Pakešu apstrāde lietotāja telpā OpenVPN 2.x lielākoties ir serializēta pa procesiem, tāpēc viens aizņemts pavediens var kļūt par griestiem, kamēr panelis ziņo par bagātīgu brīvu jaudu. Ja lēnajā periodā viens pavediens aizņem lielāko daļu kodola, resursdators kopumā nav nepietiekami nodrošināts; tas ir ierobežots tajā dimensijā, kura nejauši ir svarīga.

Pievērsiet uzmanību arī laikam. Piecpadsmit minūšu vidējie rādītāji slēpj uzliesmojumu, kas sabojāja zvanu, tāpēc pēc sūdzības uzņemts ekrānuzņēmums ir vājš pierādījums. Ņemiet paraugus problēmas laikā un saglabājiet laikatzīmi kopā ar izvadi.

Augšupielādes kanāls un rinda tā priekšā

Saskarnes skaitītāji atbild uz joslas platuma jautājumu, uz kuru CPU skaitļi nevar atbildēt. Tie arī atdala jaudu no zudumiem, un tie ir dažādi bojājumi ar dažādiem risinājumiem:

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

Saite, kas testa laikā ir tuvu tai piešķirtajam ātrumam, ir izskaidrojums, un nekāds brīvā CPU daudzums to nemaina. qdisc rinda pievieno detaļu, kas svarīga interaktīvajam trafikam: uzkrājums un zudumi pavēsta, vai paketes pirms aiziešanas gaida rindā. Rinda, kas piepildās lielas augšupielādes laikā, rada tieši to simptomu, kuru cilvēki vaino attālajā serverī, proti, lēnus zvanus savienojumā, kas mērījumos joprojām izskatās labi.

Atkārtotas pārsūtīšanas skaitītāji uztver gadījumu, kad paketes aiziet, bet nekad netiek tīri. Ja lēnajā logā atkārtotās pārsūtīšanas aug un saskarne ir tālu no jaudas, problēma ir ceļā, nevis resursdatorā, un pārcelšanās uz citu galapunktu tajā pašā pilsētā nepalīdzēs.

Sesiju skaits raksturo pieprasījumu, nevis rezervi

Katrs publiskais katalogs rāda zināmu skaitu pieslēgtu lietotāju, un gandrīz neviens no tiem nestāsta, ko šie lietotāji dara. Divdesmit sesijas ar interaktīvu darbu un četras sesijas, kas velk lielus failus, tajā pašā aparatūrā rada ļoti atšķirīgas slodzes. Otrais modelis lietotāju skaitā nav redzams, un tieši tas sabojā vakaru. Tāpēc sesiju skaitu vislabāk lasīt kā mājienu par pieprasījumu, nekad kā apgalvojumu par brīvu jaudu.

Resursdatorā, kuru kontrolējat, statusa fails dod trūkstošo dimensiju. OpenVPN raksta periodisku momentuzņēmumu, kas ietver baitu skaitītājus katram klientam, un ar to pietiek, lai redzētu, vai viena sesija ir atbildīga par visu augšupielādes kanālu:

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

Divi paraugi desmit sekunžu attālumā pārvērš šos kumulatīvos skaitītājus ātrumā katram klientam. Tas ir mērījums, kuru aizstāj lietotāju skaits, un tā arī atklājat, ka viens nepareizi konfigurēts klients katru nakti tajā pašā stundā piesātina saiti.

Sesiju ierobežojumi slēpjas politikā

Serveris var būt dīkstāvē un tomēr atteikties dot jums joslas platumu. Ātruma ierobežojumi, joslas platuma griesti katram klientam un trafika formēšana bieži tiek piemēroti pēc kopīga nosaukuma vai pēc pūla, tāpēc divi lietotāji vienā vārtejā var iegūt ļoti atšķirīgus rezultātus. Mehānisms nav smalks, bet no ārpuses nav redzams, jo tunelis abos gadījumos paceļas normāli.

Meklējiet formēšanu tuneļa saskarnē, nevis fiziskajā. Pārbaudiet, vai ierobežojums seko lietotājam, sertifikātam vai adrešu pūlam. Ja jūsu testa konts nonāk pūlā bez griestiem, jūs secināsiet, ka serveris ir kārtībā un sūdzības iesniedzējs kļūdās. Šāds secinājums ir sliktāks par nekādu, jo tas aizver biļeti.

Salīdziniet divus galapunktus ar vienu fiksētu uzdevumu

Eksperiments klienta pusē joprojām ir tā vērts, bet tikai tad, ja mainīgie ir fiksēti. Izmantojiet to pašu ierīci, to pašu piekļuves tīklu, to pašu protokolu un to pašu mērķa failu, pēc tam atkārtojiet pret otru galapunktu līdzīgā attālumā. Viss, kas mainās starp palaidieniem, tostarp diennakts laiks, piesārņo rezultātu.

Reģistrējiet neveiksmes tikpat rūpīgi kā panākumus. Sērija, kurā trīs galapunkti darbojas un viens beidzas ar taimautu, ir informatīvāka par četriem ātruma skaitļiem, jo tā norāda uz ceļa vai politikas problēmu, nevis jaudas. Palaidiet katru gadījumu vismaz divas reizes; viens lēns paraugs koplietotā tīklā neko nepierāda.

Visbeidzot, glabājiet savāktos skaitļus kopā ar apgalvojumu, ko tie atbalsta. "Šis galapunkts veica pārsūtīšanu tajā pašā logā, kurā otrs iesprūda" ir aizstāvams, savukārt "šis galapunkts ir ātrāks" aicina uz strīdu, kuru nevar uzvarēt ar sākumlapas vērtējumu. OpenVPN 2.6 rokasgrāmata dokumentē statusa failu un formēšanas opcijas, ja jums vajadzīgas precīzās direktīvas resursdatora pusei.