Ĉu via VPN-enirejo estas limigita de la CPU? Legu unue la ŝarĝon laŭ kerno
Averaĝoj kaŝas la fadenon, kiu gravas. Legu la ŝarĝon laŭ kerno dum kontrolita transigo, ekskludu la vojon, poste ŝanĝu unu dokumentitan agordon por ĉiu rulo.
Decidu, kiun el la tri limoj vi atingis, antaŭ ol aĉeti pli grandan instancon. Unu kerno plene ŝarĝita dum la aliaj estas senokupaj montras al kriptografia laboro po fluo. Ĉiuj kernoj saturitaj dum transigo montras al totala kapacito. Malalta CPU kun kreskanta nombro de resendoj montras al la vojo. Ĉiu havas malsaman unuan paŝon, kaj nur unu el ili solviĝas per pli granda instanco.
Tri limoj, unu tabelo, tri riparoj
| 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 |
Legu la vicojn kiel diagnozojn, ne kiel etapojn. Unuopa fadeno ĉe 100%, dum la aliaj estas senokupaj, estas la plej ofta rezulto sur enirejo portanta unu grandan tunelon, ĉar la ĉifrado de tiu fluo funkcias sur unu kerno. Ĉiuj kernoj okupitaj dum la transigo signifas, ke la maŝino jam faras tiom da laboro, kiom ĝi povas. Malalta CPU kun kreskantaj resendoj signifas, ke la procesoro atendas reton, kiu daŭre perdas datumojn.
Riparu ilin laŭ tiu ordo de pruvoj. Disigi fluojn inter laborantoj helpas la unuan kazon kaj faras nenion por la dua. Pli granda instanco helpas la duan kaj malŝparas monon ĉe la unua. Riparo de MTU aŭ perdo estas la sola, kiu tuŝas la trian. Aĉeti kapaciton antaŭ ol scii, en kiu vico vi estas estas la multekosta versio de divenado.
Apartigu fiksitan fadenon de okupita gastiganto
Komencu per uzado laŭ kerno, por ke unu fiksita kerno ne povu kaŝiĝi en averaĝo. Unuopa rulo dum la transigo montras, ĉu la ŝarĝo estas ebena aŭ pinta. Ambaŭ formoj estas informaj, kaj pinta profilo ofte signifas, ke la specimeniga fenestro kaptis agadon de la planilo anstataŭ ĉifradon.
mpstat -P ALL 1 5
Atribuu la okupitan kernon al procezo, poste al fadeno. La sekva rulo sube tenas gepatrojn kaj idojn kune, kio gravas, kiam la demono forkas po konekto:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10
Kerna kriptografio neniam aperas en nombrilo de uzantspaca procezo. Specimenigu fadenojn aparte kaj komparu tiun vidon kun la proceza kalkulado:
top -H -b -n 1 | head -20
Legu la ingajn nombrilojn laste, ĉar ili decidas, ĉu pli da CPU entute helpus. Kreskantaj resendoj dum ebena CPU ne estas procesora problemo. Tenu la transigon funkcianta dum vi specimenigas, alie la nombroj priskribas senokupan maŝinon:
ss -ti | grep -E 'retrans|cwnd|rtt'
Kontrolita transigo, rulita dufoje
Senokupaj nombriloj pruvas nenion, kaj kompara testo kontraŭ hazarda finpunkto pruvas tre malmulte. Elektu unu klienton, unu celon kaj unu reprezentan transigon, kiun vi rajtas ruli, poste registru trairon kaj interagan prokraston en la sama fenestro. Enirejo povas saturiĝi dum amasa kopio ankoraŭ finiĝas, kaj la prokrasta kurbo estas tio, kion uzantoj efektive sentas. Skribu la transigon, la nombron de klientoj kaj la demonan version apud la nombroj.
Ripetu la rulon kun pluraj paralelaj fluoj. Kresko trans fluoj sugestas fenestradon po fluo; resti ebena kun unu fiksita kerno sugestas prilaboradon.
Poste ripetu ankoraŭfoje kun haltigitaj laŭvolaj laborŝarĝoj. Sekurkopio, protokolsendilo aŭ datumbazo sur la sama gastiganto povas produkti okupitan averaĝon, kiu rilatas al nenio pri tuneloj. Se CPU ankoraŭ estas fiksita dum la gastiganto alie estas kvieta, la pruvoj montras al la VPN-procezo. Se ĝi falas, vi mezuris la najbaron, kaj la enirejo neniam estis la problemo.
Ekskludu la vojon antaŭ ol aĉeti aparataron
Kreskantaj resendoj, ŝrumpanta kongesta fenestro kaj kreskanta rondira tempo ĉiuj montras for de la procesoro. Komparu la tunelan MTU kun la voja MTU, kontrolu la suban ligon pri perdo, kaj konfirmu, ke la propra suprena ligo de la kliento ne estas la limo. Pli granda enirejo ne riparas ligon, kiu faligas pakaĵojn, kaj uzantoj priskribas ambaŭ difektojn per la samaj vortoj. La resenda nombrilo apartigas ilin en minutoj.
Sur virtuala servilo, aldonu la metrikojn de la provizanto al tiuj de la gasto. Ŝtelita tempo estas kiel troa vendado fariĝas videbla ene de la gasto, kaj neniu agordado ene de la gasto forigas ĝin. Nombriloj de la gasto ne povas vidi la gastiganton, do pura grafeo de la gasto ne estas pruvo de sana gastiganto.
Unu ŝanĝo, unu mezurado
Elektu la hipotezon, kiun la pruvoj subtenas, poste ŝanĝu ĝuste unu subtenatan agordon: nombron de laborantoj, dokumentitan malŝarĝan opcion aŭ la grandecon de la instanco. OpenVPN publikigas gvidilon pri solvado de agadproblemoj pri la sama disigo inter prilaborado kaj transporto: Solvado de agadproblemoj de OpenVPN.
Konfirmu, ke la malŝarĝa opcio efektive aktivas anstataŭ fidi la flagon, poste rerulu la identan transigon kaj komparu samon kun samo. Tio estas la sola maniero distingi realan plibonigon disde kvieta posttagmezo. Konservu kontrolpunkton, kiun vi povas restarigi, ĉar ĉe la dua ŝanĝo homoj perdas la spuron pri tio, kiu helpis. Unu variablo por rulo estas malrapida por tago kaj rapida por monato.
Ne malfortigu aŭtentikigon aŭ la ĉifran aron por igi la grafeon pli bona. Se CPU ankoraŭ ne sekvas la simptomon, revenu al kontroloj de vojo kaj aplikaĵo anstataŭ ĝisdatigi laŭ diveno.