Klarigo de la ŝarĝo de VPN-servilo: uzantoj, CPU aŭ suprenligo?

Pordego kun ŝarĝo de 0.4 povas ankoraŭ rampi por ĉiu uzanto malantaŭ ĝi. La averaĝa ŝarĝo kalkulas taskojn, kiuj estas ruleblaj aŭ blokitaj en neinterrompebla dormo, kaj sur gastiganto kun kvar kernoj unu sola saturita procezo sufiĉas por puŝi ĝin al 1.0 dum tri kernoj sidas senokupaj. Legi tiun nombron kiel rezervo estas la plej ofta eraro ĉe elektado de finpunkto. Tio, kio efektive limigas tunelon, estas kutime unu el kvar aferoj: unu okupata kerno, la suprenligo, la vico antaŭ ĝi, aŭ politiko por sesio, kiun neniu dokumentis.

La averaĝa ŝarĝo kalkulas taskojn, ne trafluon

La kerno provprenas la rulvicon kaj la nombron de taskoj atendantaj en- kaj eliron, poste glatigas ambaŭ dum unu, kvin kaj dek kvin minutoj. Nenio en tiu difino mencias bajtojn, pakaĵojn aŭ tunelojn. Gastiganto, kies stokado blokiĝis, povas raporti altan ŝarĝon kun preskaŭ nenia trafiko, kaj gastiganto, kiu puŝas gigabiton tra kernoretiro, povas raporti komfortan.

Kunrilati ŝarĝon kun tunela rendimento do postulas vidon laŭ kerno. Se unu kerno estas plene okupata, la suma procento sur panelo ankoraŭ aspektos bone:

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

La tria komando estas tiu, kiu plej gravas sur VPN-gastigantoj. Paketprilaborado en uzantomemoro en OpenVPN 2.x estas grandparte seria laŭ procezo, do unu sola okupata fadeno povas fariĝi la plafono dum la panelo raportas abundan senokupan kapablon. Se unu fadeno tenas la plej grandan parton de kerno dum via malrapida periodo, la gastiganto ne estas entute subtaksita; ĝi estas limigita en tiu dimensio, kiu hazarde gravas.

Rimarku ankaŭ la tempadon. Dekkvinminutaj averaĝoj kaŝas la eksplodon, kiu ruinigis vokon, do ekrankopio prenita post la plendo estas malforta pruvo. Prenu provojn dum la problemo, kaj konservu la tempomarkon kun la eligo.

La suprenligo kaj la vico antaŭ ĝi

Interfacaj nombriloj respondas la demandon pri bendolarĝo, kiun CPU-ciferoj ne povas. Ili ankaŭ apartigas kapablon disde perdo, kiuj estas malsamaj paneoj kun malsamaj solvoj:

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

Ligilo proksima al sia provizita rapideco dum via testo estas la klarigo, kaj neniu kvanto de libera CPU tion ŝanĝas. La qdisc-linio aldonas la detalon, kiu gravas por interaga trafiko: postrestaĵo kaj perdoj diras al vi, ĉu pakaĵoj atendas en vico antaŭ ol foriri. Vico pleniĝanta sub granda alŝuto produktas ĝuste tiun simptomon, kiun homoj kulpigas al la fora servilo, nome malviglajn vokojn sur konekto, kiu ankoraŭ bone mezuriĝas.

Nombriloj de resendoj kaptas la kazon, kiam pakaĵoj foriras sed neniam alvenas pure. Se resendoj kreskas dum la malrapida fenestro kaj la interfaco estas malproksime de sia kapablo, la problemo loĝas en la vojo, ne sur la gastiganto, kaj translokiĝo al alia finpunkto en la sama urbo ne helpos.

Sesinombroj priskribas mendadon, ne rezervon

Ĉiu publika dosierujo montras iun nombron de konektitaj uzantoj, kaj preskaŭ neniu el ili diras al vi, kion tiuj uzantoj faras. Dudek sesioj farantaj interagan laboron kaj kvar sesioj eltirantaj grandajn dosierojn produktas tre malsamajn ŝarĝojn sur la sama aparataro. La dua ŝablono estas nevidebla en uzantnombro, kaj ĝi estas tiu, kiu ruinigas vesperon. Do sesinombro plej bone legiĝas kiel aludo pri mendado, neniam kiel aserto pri libera kapablo.

Sur gastiganto, kiun vi kontrolas, la stata dosiero donas la mankan dimension. OpenVPN skribas periodan momenton, kiu inkluzivas bajtajn nombrilojn por kliento, kaj tio sufiĉas por vidi, ĉu unu sesio respondecas pri la tuta suprenligo:

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

Du provoj dek sekundojn dise transformas tiujn akumulitajn nombrilojn en rapidon por kliento. Tio estas la mezurado, kiun uzantnombro anstataŭas, kaj ankaŭ tiel vi malkovras, ke unu malĝuste agordita kliento saturigas la ligilon ĉiun nokton je la sama horo.

Limoj por sesio kaŝiĝas en la politiko

Servilo povas esti senokupa kaj tamen rifuzi doni al vi bendolarĝon. Rapidlimoj, bendolarĝaj plafonoj por kliento kaj trafika formado ofte aplikiĝas laŭ komuna nomo aŭ laŭ baseno, do du uzantoj sur la sama pordego povas ricevi tute malsamajn rezultojn. La mekanismo ne estas subtila, sed ĝi estas nevidebla de ekstere, ĉar la tunelo leviĝas normale en ambaŭ kazoj.

Serĉu formadon sur la tunela interfaco, ne sur la fizika. Kontrolu, ĉu la limo sekvas la uzanton, la atestilon aŭ la adresan basenon. Se via testa konto eniras la basenon sen limo, vi konkludos, ke la servilo estas en ordo kaj ke la plendanta uzanto malpravas. Tiu konkludo estas pli malbona ol neniu konkludo, ĉar ĝi fermas la bileton.

Komparu du finpunktojn per unu fiksa tasko

La eksperimento ĉe la klienta flanko ankoraŭ indas esti farita, sed nur se la variabloj estas fiksitaj. Uzu la saman aparaton, la saman alirreton, la saman protokolon kaj la saman celan dosieron, poste ripetu kontraŭ dua finpunkto je simila distanco. Ĉio, kio ŝanĝiĝas inter ruloj, inkluzive la horon de la tago, malpurigas la rezulton.

Registru malsukcesojn same zorgeme kiel sukcesojn. Serio, en kiu tri finpunktoj funkcias kaj unu finiĝas per tempolimo, estas pli informa ol kvar rapidciferoj, ĉar ĝi montras al voja aŭ politika problemo anstataŭ al kapabla. Rulu ĉiun kazon almenaŭ dufoje; unu sola malrapida provo pruvas nenion en dividita reto.

Fine, konservu la nombrojn, kiujn vi kolektis, kune kun la aserto, kiun ili subtenas. "Ĉi tiu finpunkto pritraktis la transigon en la sama fenestro, en kiu la alia blokiĝis" estas defendeble, dum "ĉi tiu finpunkto estas pli rapida" invitas disputon, kiun vi ne povas gajni per poentaro de ĉefpaĝo. La manlibro de OpenVPN 2.6 dokumentas la statan dosieron kaj la formadajn opciojn, se vi bezonas la precizajn instrukciojn por la gastiganta flanko.