Vendosni cilën nga tre kufijtë keni arritur përpara se të blini një instancë më të madhe. Një bërthamë plotësisht e zënë ndërsa të tjerat janë boshe tregon punë kriptografike për rrjedhë. Të gjitha bërthamave të ngopura gjatë transferimit tregon kapacitet të përgjithshëm. CPU e ulët me numër në rritje të ritransmetimeve tregon rrugën. Secili ka një hap të parë të ndryshëm, dhe vetëm njëri zgjidhet nga një instancë më e madhe.

Tre kufij, një tabelë, tre korrigjime

LimitReading during a transferFirst move
Single threadone core near 100%, siblings idlespread flows across workers
Aggregate CPUevery core busy, load average climbscapacity, or less work per byte
Path or providerlow CPU, retransmits or steal time highMTU, loss, host contention

Lexoni rreshtat si diagnoza, jo si faza. Një fill i vetëm në 100% ndërsa të tjerët janë boshe është rezultati më i zakonshëm në një gateway që mban një tunel të madh, sepse kriptimi i asaj rrjedhe ekzekutohet në një bërthamë. Të gjitha bërthamat të zëna gjatë transferimit do të thotë që makina po bën tashmë aq punë sa mundet. CPU e ulët me ritransmetime në rritje do të thotë që procesori pret një rrjet që vazhdimisht hedh të dhëna.

Korrigjini në atë rend dëshmish. Shpërndarja e rrjedhave mbi punëtorë ndihmon rastin e parë dhe nuk bën asgjë për të dytin. Një instancë më e madhe ndihmon të dytin dhe shpenzon kot para për të parin. Korrigjimi i MTU-së ose humbjes është i vetmi që prek të tretin. Blerja e kapacitetit përpara se të dini në cilën rresht jeni është versioni i shtrenjtë i hamendjes.

Ndani një fill të fiksuar nga një host i zënë

Filloni me përdorimin për bërthamë, që një bërthamë e fiksuar të mos fshihet brenda një mesatareje. Një ekzekutim gjatë transferimit tregon nëse ngarkesa është e rrafshët ose me maja. Të dyja format janë informuese, dhe një profil me maja shpesh do të thotë që dritarja e kampionimit kapi aktivitetin e planifikuesit dhe jo kriptimin.

mpstat -P ALL 1 5

Atribuoni bërthamën e zënë një procesi, pastaj një filli. Ekzekutimi pasues më poshtë mban bashkë fillin prind dhe fëmijë, gjë që ka rëndësi kur demoni degëzohet për çdo lidhje:

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

Kripto e kernelit nuk shfaqet kurrë në një numërues procesi në hapësirën e përdoruesit. Kampiononi fillit veçmas dhe krahasoni atë pamje me kontabilitetin e procesit:

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

Lexoni numëruesit e soketëve të fundit, sepse ata vendosin nëse më shumë CPU do të ndihmonte fare. Ritransmetimet që rriten ndërsa CPU është e rrafshët nuk është problem i procesorit. Mbani transferimin në punë ndërsa kampiononi, përndryshe numrat përshkruajnë një makinë boshe:

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

Një transferim i kontrolluar, ekzekutuar dy herë

Numëruesit boshe nuk provojnë asgjë, dhe një benchmark kundër një pike fundore të rastësishme provon shumë pak. Zgjidhni një klient, një destinacion dhe një transferim përfaqësues që ju lejohet të ekzekutoni, pastaj regjistroni xhiron dhe vonesën interaktive në të njëjtën dritare. Një gateway mund të ngopet ndërsa një kopje masive ende përfundon, dhe kurba e vonesës është ajo që përdoruesit ndjejnë vërtet. Shkruani transferimin, numrin e klientëve dhe versionin e demonit pranë numrave.

Përsëritni ekzekutimin me disa rrjedha paralele. Rritja përgjatë rrjedhave sugjeron dritare për rrjedhë; të qëndruarit i rrafshët me një bërthamë të fiksuar sugjeron përpunim.

Pastaj përsëritni edhe një herë me ngarkesat opsionale të ndaluara. Një kopje rezervë, një dërgues regjistrash ose një bazë të dhënash në të njëjtin host mund të prodhojnë një mesatare të zënë që nuk ka asnjë lidhje me tunelet. Nëse CPU është ende e fiksuar ndërsa hosti është ndryshe i qetë, dëshmitë tregojnë procesin VPN. Nëse bie, po matnit fqinjin, dhe gateway-i nuk ishte kurrë problemi.

Përjashtoni rrugën përpara se të blini harduer

Ritransmetimet në rritje, një dritare bllokimi që tkurret dhe një kohë vajtje-ardhje në rritje tregojnë të gjitha larg procesorit. Krahasoni MTU-në e tunelit me MTU-në e rrugës, kontrolloni lidhjen bazë për humbje dhe konfirmoni që uplink-u i vetë klientit nuk është kufiri. Një gateway më i madh nuk riparon një lidhje që hedh paketa, dhe përdoruesit përshkruajnë të dyja defektet me të njëjtat fjalë. Numëruesi i ritransmetimeve i ndan ato brenda minutash.

Në një server virtual, shtoni metrikat e ofruesit tek ato të mysafirit. Koha e vjedhur është mënyra se si mbishitja bëhet e dukshme brenda mysafirit, dhe asnjë rregullim brenda mysafirit nuk e heq atë. Numëruesit e mysafirit nuk e shohin hostin, prandaj një grafik i pastër i mysafirit nuk është provë e një hosti të shëndetshëm.

Një ndryshim, një matje

Zgjidhni hipotezën që dëshmitë mbështesin, pastaj ndryshoni saktësisht një cilësim të mbështetur: numrin e punëtorëve, një opsion të dokumentuar shkarkimi ose madhësinë e instancës. OpenVPN publikon një udhëzues për zgjidhjen e problemeve të performancës për të njëjtën ndarje midis përpunimit dhe transportit: Zgjidhja e problemeve të performancës së OpenVPN.

Konfirmoni që opsioni i shkarkimit është vërtet aktiv në vend që t'i besoni flamurit, pastaj riekzekutoni të njëjtin transferim dhe krahasoni të ngjashmen me të ngjashmen. Është mënyra e vetme për të dalluar një përmirësim të vërtetë nga një pasdite e qetë. Mbani një pikë kontrolli që mund të rikthehet, sepse në ndryshimin e dytë njerëzit humbin gjurmën se cili ndihmoi. Një variabël për ekzekutim është i ngadaltë për një ditë dhe i shpejtë për një muaj.

Mos dobësoni autentifikimin ose grupin e shifrave për ta bërë grafikun të duket më mirë. Nëse CPU ende nuk e ndjek simptomën, kthehuni te kontrollet e rrugës dhe aplikacionit në vend që të përmirësoni mbi një hamendje.

Artikuj të ngjashëm