Vai jūsu VPN vārteja ir CPU ierobežota? Vispirms lasiet slodzi pa kodoliem

Pirms iegādājaties lielāku instanci, nosakiet, kuru no trim robežām esat sasniedzis. Viens kodols noslogots, pārējie dīkstāvē – tas norāda uz šifrēšanas darbu plūsmai. Visi kodoli piesātināti pārsūtīšanas laikā – tas norāda uz kopējo jaudu. Zems CPU ar augošu atkārtotu pārsūtīšanu skaitu norāda uz ceļu. Katram ir cits pirmais solis, un tikai vienu no tiem atrisina lielāka instance.

Trīs robežas, viena tabula, trīs labojumi

Lasiet rindas kā diagnozes, nevis posmus. Viens pavediens ar 100%, kamēr pārējie dīkstāvē, ir visbiežākais rezultāts vārtejā, kas nes vienu lielu tuneli, jo šīs plūsmas šifrēšana darbojas vienā kodolā. Visi kodoli aizņemti pārsūtīšanas laikā nozīmē, ka iekārta jau dara tik daudz, cik spēj. Zems CPU ar augošām atkārtotām pārsūtīšanām nozīmē, ka procesors gaida tīklu, kas pastāvīgi zaudē datus.

Labojiet tos šajā pierādījumu secībā. Plūsmu sadalīšana pa darbiniekiem palīdz pirmajā gadījumā un neko nedara otrajā. Lielāka instance palīdz otrajā un izšķiež naudu pirmajā. MTU vai zudumu labojums ir vienīgais, kas skar trešo. Pirkt jaudu pirms zināt, kurā rindā esat ir dārgā minēšanas versija.

Atdaliet piesprausto pavedienu no aizņemta resursdatora

Sāciet ar izmantojumu pa kodoliem, lai viens piesprausts kodols nevarētu paslēpties vidējā. Viena palaišana pārsūtīšanas laikā parāda, vai slodze ir vienmērīga vai ar lēcieniem. Abas formas ir informatīvas, un ar lēcieniem profils bieži nozīmē, ka paraugu ņemšanas logs uztvēra plānotāja darbību, nevis šifrēšanu.

mpstat -P ALL 1 5

Piešķiriet aizņemto kodolu procesam, pēc tam pavedienam. Turpmākā palaišana zemāk tur kopā vecāku un bērnu pavedienus, kas ir svarīgi, kad dēmons atzarojas katram savienojumam:

pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10

Kodola šifrēšana nekad neparādās lietotāja telpas procesa skaitītājā. Ņemiet pavedienu paraugus atsevišķi un salīdziniet šo skatu ar procesa uzskaiti:

top -H -b -n 1 | head -20

Ligzdu skaitītājus lasiet pēdējos, jo tie izlemj, vai vairāk CPU vispār palīdzētu. Atkārtotas pārsūtīšanas aug, kamēr CPU ir vienmērīgs – tā nav procesora problēma. Turiet pārsūtīšanu ieslēgtu paraugu ņemšanas laikā, citādi skaitļi apraksta dīkstāvē esošu iekārtu:

ss -ti | grep -E 'retrans|cwnd|rtt'

Kontrolēta pārsūtīšana, veikta divreiz

Dīkstāves skaitītāji neko nepierāda, un tests pret nejaušu galapunktu pierāda ļoti maz. Izvēlieties vienu klientu, vienu galamērķi un vienu reprezentatīvu pārsūtīšanu, ko drīkstat veikt, un pēc tam tajā pašā logā fiksējiet caurlaidspēju un interaktīvo aizkavi. Vārteja var piesātināties, kamēr liela kopēšana vēl beidzas, un aizkaves līkne ir tas, ko lietotāji patiešām jūt. Pierakstiet pārsūtīšanu, klientu skaitu un dēmona versiju blakus skaitļiem.

Atkārtojiet palaišanu ar vairākām paralēlām plūsmām. Pieaugums pāri plūsmām norāda uz logiem katrai plūsmai; palikšana vienmērīga ar piespraustu kodolu norāda uz apstrādi.

Pēc tam atkārtojiet vēlreiz, apturot neobligātās darba slodzes. Dublējums, žurnālu sūtītājs vai datubāze tajā pašā resursdatorā var radīt aizņemtu vidējo, kam nav nekāda sakara ar tuneļiem. Ja CPU joprojām ir piesprausts un resursdators citādi ir kluss, pierādījumi norāda uz VPN procesu. Ja tas krītas, jūs mērījāt kaimiņu, un vārteja nekad nebija problēma.

Izslēdziet ceļu pirms aparatūras iegādes

Augošas atkārtotas pārsūtīšanas, sarūkošs pārslodzes logs un augošs turp un atpakaļ laiks visi norāda prom no procesora. Salīdziniet tuneļa MTU ar ceļa MTU, pārbaudiet pamata saiti uz zudumiem un apstipriniet, ka klienta paša augšupielādes saite nav robeža. Lielāka vārteja nelabo saiti, kas met paketes, un lietotāji abus defektus apraksta ar tiem pašiem vārdiem. Atkārtoto pārsūtīšanu skaitītājs tos atdala minūtēs.

Virtuālajā serverī pievienojiet pakalpojumu sniedzēja metrikas viesa paša metrikām. Zagtais laiks ir veids, kā pārdošana virs jaudas kļūst redzama viesa iekšienē, un neviens regulējums viesa iekšienē to neizņem. Viesa skaitītāji neredz resursdatoru, tāpēc tīrs viesa grafiks nav vesela resursdatora pierādījums.

Viena izmaiņa, viens mērījums

Izvēlieties hipotēzi, ko atbalsta pierādījumi, un pēc tam mainiet tieši vienu atbalstītu iestatījumu: darbinieku skaitu, dokumentētu izkraušanas opciju vai instances izmēru. OpenVPN publicē veiktspējas problēmu novēršanas rokasgrāmatu par to pašu dalījumu starp apstrādi un transportēšanu: OpenVPN veiktspējas problēmu novēršana.

Pārbaudiet, vai izkraušanas opcija patiešām ir aktīva, nevis uzticieties karodziņam, pēc tam atkārtojiet identisku pārsūtīšanu un salīdziniet līdzīgu ar līdzīgu. Tas ir vienīgais veids, kā atšķirt reālu uzlabojumu no klusas pēcpusdienas. Saglabājiet kontrolpunktu, ko varat atjaunot, jo pie otrās izmaiņas cilvēki pazaudē, kura palīdzēja. Viens mainīgais katrā palaišanā ir lēns dienai un ātrs mēnesim.

Ne vājiniet autentifikāciju vai šifru komplektu, lai grafiks izskatītos labāk. Ja CPU joprojām neseko simptomam, atgriezieties pie ceļa un lietojumprogrammas pārbaudēm, nevis jauniniet uz minējuma pamata.