Zátěž serveru VPN vysvětlena: uživatelé, CPU, nebo uplink?

Brána se zátěží 0.4 může i tak každému uživateli za sebou lézt. Průměrná zátěž počítá úlohy, které lze spustit nebo které uvízly v nepřerušitelném spánku, a na čtyřjádrovém hostiteli stačí jeden nasycený proces, aby se přiblížila k 1.0, zatímco tři jádra zahálí. Číst toto číslo jako rezervu je nejčastější chyba při výběru koncového bodu. Tunel obvykle omezuje jedna ze čtyř věcí: jedno vytížené jádro, uplink, fronta před ním, nebo politika pro relaci, kterou nikdo nezdokumentoval.

Průměrná zátěž počítá úlohy, ne propustnost

Jádro vzorkuje frontu spustitelných úloh a počet úloh čekajících na vstup a výstup, a pak obojí vyhladí za jednu, pět a patnáct minut. Nic v této definici nezmiňuje bajty, pakety ani tunely. Hostitel se zaseknutým úložištěm může hlásit vysokou zátěž téměř bez provozu a hostitel, který protlačí gigabit přes jádrovou datovou cestu, může hlásit pohodovou.

Spojovat zátěž s výkonem tunelu proto vyžaduje pohled po jádrech. Je-li jedno jádro vytížené naplno, souhrnné procento na panelu bude stále vypadat dobře:

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

Třetí příkaz je ten, na kterém u hostitelů VPN záleží nejvíc. Zpracování paketů v uživatelském prostoru v OpenVPN 2.x je z velké části serializované po procesech, takže jedno vytížené vlákno se může stát stropem, zatímco panel hlásí spoustu volného výkonu. Pokud jedno vlákno drží většinu jádra během vašeho pomalého období, hostitel není jako celek poddimenzovaný; je omezený v rozměru, na kterém právě záleží.

Všímejte si i načasování. Patnáctiminutové průměry skrývají náraz, který zničil hovor, takže snímek obrazovky pořízený po stížnosti je slabý důkaz. Vzorkujte během problému a uchovejte časové razítko s výstupem.

Uplink a fronta před ním

Počítadla rozhraní odpovídají na otázku šířky pásma, kterou čísla CPU nedokážou. Oddělují také kapacitu od ztrát, což jsou různé poruchy s různými řešeními:

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

Spojení, které se během testu blíží své přidělené rychlosti, je vysvětlením a žádné množství volného výkonu to nezmění. Řádek qdisc přidává detail, který je důležitý pro interaktivní provoz: zpoždění a zahazování říkají, zda pakety čekají ve frontě, než odejdou. Fronta, která se plní při hromadném nahrávání, vytváří přesně ten příznak, který lidé svalují na vzdálený server, tedy pomalé hovory na spojení, které v měřeních stále vypadá dobře.

Počítadla opakovaných přenosů zachytí případ, kdy pakety odejdou, ale nikdy nedorazí čistě. Pokud opakované přenosy během pomalého okna rostou a rozhraní zdaleka není na hranici kapacity, problém je v cestě, nikoli na hostiteli, a přesun na jiný koncový bod ve stejném městě nepomůže.

Počty relací popisují poptávku, ne rezervu

Každý veřejný adresář ukazuje nějaký počet připojených uživatelů a téměř žádný neříká, co tito uživatelé dělají. Dvacet relací s interaktivní prací a čtyři relace stahující velké soubory vytvářejí na stejném hardwaru velmi odlišnou zátěž. Druhý vzorec je v počtu uživatelů neviditelný a právě on kazí večer. Číslo relací je proto nejlepší číst jako nápovědu o poptávce, nikdy jako tvrzení o volné kapacitě.

Na hostiteli, který ovládáte, dává stavový soubor chybějící rozměr. OpenVPN zapisuje pravidelný snímek, který zahrnuje počítadla bajtů pro každého klienta, a to stačí k tomu, abyste viděli, zda je za celý uplink odpovědná jedna relace:

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

Dva vzorky deset sekund od sebe promění tato kumulativní čísla v rychlost na klienta. To je měření, které počet uživatelů zastupuje, a zároveň tak zjistíte, že jeden špatně nastavený klient každou noc ve stejnou hodinu zahlcuje spojení.

Limity pro relaci se skrývají v politice

Server může být nečinný a přesto vám odmítat šířku pásma. Rychlostní limity, stropy šířky pásma pro klienta a tvarování provozu se často uplatňují podle společného jména nebo podle poolu, takže dva uživatelé na stejné bráně mohou dostat velmi odlišné výsledky. Mechanismus není jemný, ale zvenčí je neviditelný, protože tunel v obou případech normálně naskočí.

Hledejte tvarování na rozhraní tunelu, ne na fyzickém. Zkontrolujte, zda limit sleduje uživatele, certifikát, nebo pool adres. Pokud váš testovací účet spadne do neomezeného poolu, dojdete k závěru, že server je v pořádku a stěžující si uživatel se mýlí. Takový závěr je horší než žádný, protože zavírá tiket.

Porovnejte dva koncové body jedním pevným úkolem

Experiment na straně klienta stojí stále za to provést, ale jen když jsou proměnné zafixované. Použijte stejné zařízení, stejnou přístupovou síť, stejný protokol a stejný cílový soubor, pak to zopakujte proti druhému koncovému bodu v podobné vzdálenosti. Cokoli se mezi běhy změní, včetně denní doby, znehodnocuje výsledek.

Zaznamenávejte selhání stejně pečlivě jako úspěchy. Série, kde tři koncové body fungují a jeden vyprší, je informativnější než čtyři čísla rychlosti, protože ukazuje na problém cesty nebo politiky, ne kapacity. Každý případ spusťte alespoň dvakrát; jediný pomalý vzorek ve sdílené síti nic nedokazuje.

Nakonec si nechte čísla, která jste nasbírali, spolu s tvrzením, které podporují. "Tento koncový bod zvládl přenos ve stejném okně, ve kterém se druhý zasekl" je obhajitelné, zatímco "tento koncový bod je rychlejší" vyvolává hádku, kterou skóre z domovské stránky nevyhrajete. Manuál OpenVPN 2.6 dokumentuje stavový soubor a možnosti tvarování, pokud potřebujete přesné direktivy pro stranu hostitele.