Zaťaženie servera VPN vysvetlené: používatelia, CPU alebo uplink?

Brána so zaťažením 0.4 sa stále môže pre každého používateľa za ňou plaziť. Priemerné zaťaženie počíta úlohy, ktoré možno spustiť alebo ktoré uviazli v neprerušiteľnom spánku, a na hostiteľovi so štyrmi jadrami stačí jeden nasýtený proces, aby sa priblížilo k 1.0, kým tri jadrá zaháľajú. Čítať toto číslo ako rezervu je najčastejšia chyba pri výbere koncového bodu. Tunel zvyčajne obmedzuje jedna zo štyroch vecí: jedno vyťažené jadro, uplink, front pred ním alebo politika pre reláciu, ktorú nikto nezdokumentoval.

Priemerné zaťaženie počíta úlohy, nie priepustnosť

Jadro vzorkuje front spustiteľných úloh a počet úloh čakajúcich na vstup a výstup, potom oboje vyhladí za jednu, päť a pätnásť minút. Nič v tejto definícii nespomína bajty, pakety ani tunely. Hostiteľ so zaseknutým úložiskom môže hlásiť vysoké zaťaženie takmer bez prevádzky a hostiteľ, ktorý pretlačí gigabit cez dátovú cestu jadra, môže hlásiť pohodové.

Prepojiť zaťaženie s výkonom tunela preto vyžaduje pohľad po jadrách. Ak je jedno jadro plne vyťažené, súhrnné percento na paneli bude stále vyzerať dobre:

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

Tretí príkaz je ten, na ktorom u hostiteľov VPN záleží najviac. Spracovanie paketov v používateľskom priestore v OpenVPN 2.x je z veľkej časti serializované po procesoch, takže jedno vyťažené vlákno sa môže stať stropom, kým panel hlási množstvo voľného výkonu. Ak jedno vlákno drží väčšinu jadra počas vášho pomalého obdobia, hostiteľ nie je ako celok poddimenzovaný; je obmedzený v dimenzii, na ktorej práve záleží.

Všímajte si aj časovanie. Pätnásťminútové priemery skrývajú náraz, ktorý pokazil hovor, takže snímka obrazovky urobená po sťažnosti je slabý dôkaz. Vzorkujte počas problému a uchovajte časovú pečiatku s výstupom.

Uplink a front pred ním

Počítadlá rozhrania odpovedajú na otázku o šírke pásma, na ktorú čísla CPU nedokážu. Oddeľujú aj kapacitu od strát, a to sú rôzne poruchy s rôznymi riešeniami:

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

Spojenie, ktoré sa počas testu blíži svojej pridanej rýchlosti, je vysvetlením a žiadne množstvo voľného CPU to nezmení. Riadok qdisc pridáva detail, ktorý je dôležitý pre interaktívnu prevádzku: zdržanie a zahadzovanie hovoria, či pakety čakajú vo fronte pred odchodom. Front, ktorý sa plní pri veľkom nahrávaní, vytvára presne ten príznak, ktorý ľudia zvaľujú na vzdialený server, teda pomalé hovory na spojení, ktoré v meraniach stále vyzerá dobre.

Počítadlá opakovaných prenosov zachytia prípad, keď pakety odídu, ale nikdy nedorazia čisto. Ak opakované prenosy v pomalom okne rastú a rozhranie ani zďaleka nie je na hranici kapacity, problém je v ceste, nie na hostiteľovi, a presun na iný koncový bod v tom istom meste nepomôže.

Počty relácií opisujú dopyt, nie rezervu

Každý verejný adresár zobrazuje nejaký počet pripojených používateľov a takmer žiadny nehovorí, čo títo používatelia robia. Dvadsať relácií s interaktívnou prácou a štyri relácie sťahujúce veľké súbory vytvárajú na tom istom hardvéri veľmi odlišné zaťaženie. Druhý vzor je v počte používateľov neviditeľný a práve on kazí večer. Preto je počet relácií najlepšie čítať ako náznak dopytu, nikdy ako tvrdenie o voľnej kapacite.

Na hostiteľovi, ktorý ovládate, dáva stavový súbor chýbajúci rozmer. OpenVPN zapisuje pravidelnú snímku, ktorá obsahuje počítadlá bajtov pre každého klienta, a to stačí na to, aby ste videli, či je za celý uplink zodpovedná jedna relácia:

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

Dve vzorky desať sekúnd od seba premenia tieto kumulatívne čísla na rýchlosť na klienta. To je meranie, ktoré počet používateľov zastupuje, a zároveň tak zistíte, že jeden nesprávne nastavený klient každú noc v rovnakú hodinu zahlcuje spojenie.

Limity pre reláciu sa skrývajú v politike

Server môže byť nečinný a napriek tomu vám odmietať šírku pásma. Rýchlostné limity, stropy šírky pásma pre klienta a tvarovanie prevádzky sa často uplatňujú podľa spoločného mena alebo podľa poolu, takže dvaja používatelia na tej istej bráne môžu dostať veľmi odlišné výsledky. Mechanizmus nie je jemný, ale zvonku je neviditeľný, pretože tunel v oboch prípadoch normálne naskočí.

Hľadajte tvarovanie na rozhraní tunela, nie na fyzickom. Skontrolujte, či limit nasleduje používateľa, certifikát alebo pool adries. Ak váš testovací účet spadne do poolu bez stropu, dospejete k záveru, že server je v poriadku a sťažujúci sa používateľ sa mýli. Takýto záver je horší než žiadny, pretože zatvára tiket.

Porovnajte dva koncové body jednou pevnou úlohou

Experiment na strane klienta sa stále oplatí urobiť, ale len ak sú premenné zafixované. Použite to isté zariadenie, tú istú prístupovú sieť, ten istý protokol a ten istý cieľový súbor, potom to zopakujte proti druhému koncovému bodu v podobnej vzdialenosti. Čokoľvek sa medzi behmi zmení, vrátane dennej doby, znehodnocuje výsledok.

Zaznamenávajte zlyhania rovnako starostlivo ako úspechy. Séria, v ktorej tri koncové body fungujú a jeden vyprší, je informatívnejšia než štyri čísla rýchlosti, pretože ukazuje na problém cesty alebo politiky, nie kapacity. Každý prípad spustite aspoň dvakrát; jediná pomalá vzorka v zdieľanej sieti nič nedokazuje.

Napokon si nechajte čísla, ktoré ste nazbierali, spolu s tvrdením, ktoré podporujú. "Tento koncový bod zvládol prenos v tom istom okne, v ktorom sa druhý zasekol" je obhájiteľné, zatiaľ čo "tento koncový bod je rýchlejší" vyvoláva hádku, ktorú skóre z domovskej stránky nevyhráte. Manuál OpenVPN 2.6 dokumentuje stavový súbor a možnosti tvarovania, ak potrebujete presné direktívy pre stranu hostiteľa.