Ngarkesa e serverit VPN e shpjeguar: përdorues, CPU apo lidhja lart?

Një portë me ngarkesë 0.4 mund të zvarritet ende për çdo përdorues pas saj. Ngarkesa mesatare numëron detyrat që mund të ekzekutohen ose që janë bllokuar në një gjumë të pandërprerë, dhe në një host me katër bërthama mjafton një proces i ngopur për ta shtyrë drejt 1.0 ndërsa tre bërthama rrinë pa punë. Të lexosh atë numër si rezervë është gabimi më i zakonshëm në zgjedhjen e pikës fundore. Ajo që kufizon vërtet një tunel është zakonisht një nga katër gjëra: një bërthamë e zënë, lidhja lart, radha përpara saj ose një politikë për sesion që askush nuk e dokumentoi.

Ngarkesa mesatare numëron detyra, jo xhiron

Bërthama merr mostra nga radha e ekzekutimit dhe numri i detyrave që presin hyrje dhe dalje, pastaj i zbut të dyja gjatë një, pesë dhe pesëmbëdhjetë minutash. Asgjë në atë përkufizim nuk përmend bajt, paketa ose tunele. Një host me ruajtje të bllokuar mund të raportojë ngarkesë të lartë pothuajse pa trafik, dhe një host që shtyn një gigabit nëpër rrugën e të dhënave të bërthamës mund të raportojë një të rehatshme.

Prandaj, lidhja e ngarkesës me performancën e tunelit kërkon një pamje për çdo bërthamë. Nëse një bërthamë është plot, përqindja e përgjithshme në një panel do të duket ende mirë:

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

Komanda e tretë është ajo që ka më shumë rëndësi në hostet VPN. Përpunimi i paketave në hapësirën e përdoruesit në OpenVPN 2.x është kryesisht serial për çdo proces, kështu që një fije e zënë mund të bëhet tavani ndërsa paneli raporton kapacitet të bollshëm të lirë. Nëse një fije mban pjesën më të madhe të një bërthame gjatë periudhës tuaj të ngadaltë, hosti nuk është i nëndimensionuar në tërësi; ai është i kufizuar në dimensionin që ndodh të ketë rëndësi.

Vini re edhe kohën. Mesataret e pesëmbëdhjetë minutave fshehin shpërthimin që prishi një telefonatë, prandaj një pamje ekrani e marrë pas ankesës është provë e dobët. Merrni mostra gjatë problemit dhe mbani vulën kohore me daljen.

Lidhja lart dhe radha përpara saj

Numëruesit e ndërfaqes i përgjigjen pyetjes së gjerësisë së brezit të cilës numrat e CPU nuk mund t'i përgjigjen. Ata gjithashtu ndajnë kapacitetin nga humbja, dhe këto janë dështime të ndryshme me zgjidhje të ndryshme:

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

Një lidhje afër shpejtësisë së caktuar gjatë testit tuaj është shpjegimi, dhe asnjë sasi CPU e lirë nuk e ndryshon atë. Rreshti qdisc shton detajin që ka rëndësi për trafikun interaktiv: vonesa dhe rëniet ju tregojnë nëse paketat presin në një radhë përpara se të nisen. Një radhë që mbushet nën një ngarkim të madh prodhon pikërisht simptomën që njerëzit ia hedhin serverit të largët, pra telefonata të ngadalta në një lidhje që ende ka rezultate të mira në matje.

Numëruesit e ritransmetimit kapin rastin kur paketat nisen por nuk arrijnë kurrë pastër. Nëse ritransmetimet rriten gjatë dritares së ngadaltë dhe ndërfaqja është larg kapacitetit, problemi është në rrugë dhe jo në host, dhe kalimi në një pikë tjetër fundore në të njëjtin qytet nuk do të ndihmojë.

Numri i sesioneve përshkruan kërkesën, jo rezervën

Çdo drejtori publike shfaq një numër të caktuar përdoruesish të lidhur, dhe pothuajse asnjë prej tyre nuk ju thotë çfarë po bëjnë ata përdorues. Njëzet sesione që bëjnë punë interaktive dhe katër sesione që shkarkojnë skedarë të mëdhenj prodhojnë ngarkesa shumë të ndryshme në të njëjtin harduer. Modeli i dytë është i padukshëm në një numër përdoruesish, dhe është ai që prish një mbrëmje. Prandaj një numër sesionesh lexohet më së miri si një aluzion për kërkesën, kurrë si një deklaratë për kapacitetin e lirë.

Në një host që ju kontrolloni, skedari i statusit jep dimensionin që mungon. OpenVPN shkruan pamje periodike që përfshijnë numërues bajtësh për çdo klient, dhe kjo mjafton për të parë nëse një sesion i vetëm është përgjegjës për të gjithë lidhjen lart:

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

Dy mostra dhjetë sekonda larg njëra-tjetrës i kthejnë ato numërime kumulative në një shpejtësi për klient. Ky është matja që zëvendëson një numër përdoruesish, dhe po kështu zbuloni se një klient i konfiguruar gabimisht e ngop lidhjen çdo natë në të njëjtën orë.

Kufijtë për çdo sesion fshihen brenda politikës

Një server mund të jetë joaktiv dhe prapë të refuzojë t'ju japë gjerësi brezi. Kufijtë e shpejtësisë, tavanet e gjerësisë së brezit për klient dhe formësimi i trafikut shpesh aplikohen për emër të përbashkët ose për grup, kështu që dy përdorues në të njëjtën portë mund të marrin rezultate krejt të ndryshme. Mekanizmi nuk është i hollë, por është i padukshëm nga jashtë sepse tuneli ngrihet normalisht në të dyja rastet.

Kërko formësimin në ndërfaqen e tunelit dhe jo në atë fizike. Kontrollo nëse kufiri ndjek përdoruesin, certifikatën apo grupin e adresave. Nëse llogaria juaj e testit bie në grupin pa tavan, do të arrini në përfundimin se serveri është në rregull dhe përdoruesi që ankohet gabon. Një përfundim i tillë është më i keq se asnjë përfundim, sepse e mbyll biletën.

Krahasoni dy pika fundore me një detyrë fikse

Eksperimenti nga ana e klientit ende ia vlen të bëhet, por vetëm nëse variablat janë të fiksuara. Përdorni të njëjtin pajisje, të njëjtin rrjet aksesi, të njëjtin protokoll dhe të njëjtin skedar destinacioni, pastaj përsëriteni kundrejt një pike të dytë fundore në një distancë të ngjashme. Çdo gjë që ndryshon midis ekzekutimeve, duke përfshirë orën e ditës, e ndot rezultatin.

Regjistroni dështimet po aq me kujdes sa sukseset. Një seri në të cilën tre pika fundore punojnë dhe një skadon është më informues se katër numra shpejtësie, sepse tregon një problem rruge ose politike dhe jo kapaciteti. Ekzekutoni çdo rast të paktën dy herë; një mostër e vetme e ngadaltë nuk dëshmon asgjë në një rrjet të përbashkët.

Së fundi, mbani numrat që keni mbledhur së bashku me pohimin që ata mbështesin. "Kjo pikë fundore e përfundoi transferimin në të njëjtën dritare në të cilën tjetra ngeci" është e mbrojtshme, ndërsa "kjo pikë fundore është më e shpejtë" fton një debat që nuk mund ta fitoni me një pikëzim faqeje kryesore. Manuali i OpenVPN 2.6 dokumenton skedarin e statusit dhe opsionet e formësimit nëse ju nevojiten direktivat e sakta për anën e hostit.