Ar jūsų VPN šliuzas ribojamas CPU? Pirmiausia skaitykite apkrovą pagal branduolius
Vidurkiai slepia svarbų srautą. Skaitykite apkrovą pagal branduolius kontroliuojamo perdavimo metu, pašalinkite kelią, tada keiskite vieną dokumentuotą nustatymą per bandymą.
Nustatykite, kurią iš trijų ribų pasiekėte, prieš pirkdami didesnę instanciją. Vienas branduolys apkrautas, o kiti neveikia – tai rodo šifravimo darbą vienam srautui. Visi branduoliai prisotinti perdavimo metu – tai rodo bendrą pajėgumą. Mažas CPU ir augantis pakartotinių perdavimų skaičius rodo kelią. Kiekviena turi kitą pirmą žingsnį, ir tik vieną jų išsprendžia didesnė instancija.
Trys ribos, viena lentelė, trys pataisos
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
Skaitykite eilutes kaip diagnozes, ne kaip etapus. Vienas srautas 100%, o kiti neveikia – tai dažniausias rezultatas šliuze, kuris neša vieną didelį tunelį, nes to srauto šifravimas vyksta viename branduolyje. Visi branduoliai užimti perdavimo metu reiškia, kad mašina jau dirba tiek, kiek gali. Mažas CPU ir augantys pakartotiniai perdavimai reiškia, kad procesorius laukia tinklo, kuris nuolat meta duomenis.
Taisykite juos ta įrodymų tvarka. Srautų paskirstymas darbininkams padeda pirmuoju atveju ir nieko neduoda antrajam. Didesnė instancija padeda antruoju ir švaisto pinigus pirmuoju. MTU arba nuostolių pataisa yra vienintelė, kuri liečia trečiąjį. Pirkti pajėgumą prieš žinant, kurioje eilutėje esate yra brangi spėliojimo versija.
Atskirkite prisegtą srautą nuo užimto serverio
Pradėkite nuo naudojimo pagal branduolius, kad vienas prisegtas branduolys negalėtų pasislėpti vidurkyje. Vienas bandymas perdavimo metu parodo, ar apkrova tolygi, ar su šuoliais. Abi formos informatyvios, o su šuoliais profilis dažnai reiškia, kad atrankos langas pagavo planuotojo veiklą, o ne šifravimą.
mpstat -P ALL 1 5Priskirkite užimtą branduolį procesui, tada srautui. Tolesnis bandymas žemiau išlaiko tėvinius ir vaikinius srautus kartu, kas svarbu, kai demonas šakojasi kiekvienam ryšiui:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10Branduolio šifravimas niekada nerodomas vartotojo erdvės proceso skaitiklyje. Imkite srautų pavyzdžius atskirai ir palyginkite tą vaizdą su proceso apskaita:
top -H -b -n 1 | head -20Soketų skaitiklius skaitykite paskutinius, nes jie nusprendžia, ar daugiau CPU apskritai padėtų. Pakartotiniai perdavimai auga, o CPU tolygus – tai ne procesoriaus problema. Laikykite perdavimą veikiantį atrankos metu, kitaip skaičiai apibūdins nenaudojamą mašiną:
ss -ti | grep -E 'retrans|cwnd|rtt'Kontroliuojamas perdavimas, atliktas du kartus
Nenaudojami skaitikliai nieko neįrodo, o bandymas prieš atsitiktinį galinį tašką įrodo labai mažai. Pasirinkite vieną klientą, vieną paskirties vietą ir vieną reprezentatyvų perdavimą, kurį leidžiama atlikti, tada tame pačiame lange užfiksuokite pralaidumą ir sąveikos vėlavimą. Šliuzas gali prisisotinti, kol didelis kopijavimas dar baigiasi, o vėlavimo kreivė yra tai, ką naudotojai tikrai jaučia. Užrašykite perdavimą, klientų skaičių ir demono versiją šalia skaičių.
Pakartokite bandymą su keliais lygiagrečiais srautais. Augimas per srautus rodo langus vienam srautui; likimas tolygus su prisegtu branduoliu rodo apdorojimą.
Tada pakartokite dar kartą sustabdę pasirenkamus darbo krūvius. Atsarginė kopija, žurnalų siuntėjas ar duomenų bazė tame pačiame serveryje gali sukurti užimtą vidurkį, kuris neturi nieko bendra su tuneliais. Jei CPU vis dar prisegtas, o serveris kitaip tylus, įrodymai rodo VPN procesą. Jei jis krenta, matavote kaimyną, ir šliuzas niekada nebuvo problema.
Pašalinkite kelią prieš pirkdami techninę įrangą
Augantys pakartotiniai perdavimai, mažėjantis perkrovos langas ir augantis kelionės pirmyn ir atgal laikas visi rodo toli nuo procesoriaus. Palyginkite tunelio MTU su kelio MTU, patikrinkite pagrindinę jungtį dėl nuostolių ir patvirtinkite, kad kliento savas išsiuntimo kanalas nėra riba. Didesnis šliuzas neremontuoja jungties, kuri meta paketus, o naudotojai abi gedimus apibūdina tais pačiais žodžiais. Pakartotinių perdavimų skaitiklis juos atskiria per minutes.
Virtualiame serveryje pridėkite tiekėjo metrikas prie svečio savųjų. Pavogtas laikas yra tai, kaip perpardavimas tampa matomas svečio viduje, ir joks derinimas svečio viduje to nepašalina. Svečio skaitikliai nemato serverio, todėl švarus svečio grafikas nėra sveiko serverio įrodymas.
Vienas pakeitimas, vienas matavimas
Pasirinkite hipotezę, kurią palaiko įrodymai, tada pakeiskite tiksliai vieną palaikomą nustatymą: darbininkų skaičių, dokumentuotą iškrovimo parinktį arba instancijos dydį. OpenVPN skelbia našumo trikčių šalinimo vadovą apie tą patį atskyrimą tarp apdorojimo ir transportavimo: OpenVPN našumo trikčių šalinimas.
Patvirtinkite, kad iškrovimo parinktis tikrai aktyvi, o ne pasitikėkite vėliavėle, tada pakartokite tą patį perdavimą ir palyginkite panašų su panašiu. Tai vienintelis būdas atskirti tikrą pagerėjimą nuo tylios popietės. Išsaugokite kontrolinį tašką, kurį galite atkurti, nes prie antro pakeitimo žmonės pameta, kuris padėjo. Vienas kintamasis per bandymą yra lėtas dienai ir greitas mėnesiui.
Nesilpninkite autentifikavimo ar šifrų rinkinio, kad grafikas atrodytų geriau. Jei CPU vis dar neseka simptomo, grįžkite prie kelio ir programos patikrų, o ne atnaujinkite spėliodami.