Je váš VPN gateway omezený procesorem? Nejprve čtěte zátěž po jádrech
Průměry skrývají vlákno, na kterém záleží. Čtěte zátěž po jádrech při kontrolovaném přenosu, vylučte cestu a pak měňte jedno dokumentované nastavení na běh.
Určete, které ze tří omezení jste dosáhli, než koupíte větší instanci. Jedno jádro naplno a ostatní nečinná ukazují na krypto práci na tok. Všechna jádra nasycená během přenosu ukazují na celkovou kapacitu. Nízké CPU s rostoucím počtem opakovaných přenosů ukazuje na cestu. Každé má jiný první krok a jen jedno z nich řeší větší instance.
Tři omezení, jedna tabulka, tři opravy
| 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 |
Čtěte řádky jako diagnózy, ne jako fáze. Jedno vlákno na 100%, zatímco ostatní jsou nečinná, je nejčastější výsledek na bráně s jedním velkým tunelem, protože šifrování toho toku běží na jednom jádru. Všechna jádra zaneprázdněná během přenosu znamená, že stroj už dělá tolik práce, kolik může. Nízké CPU s rostoucími opakovanými přenosy znamená, že procesor čeká na síť, která neustále ztrácí data.
Opravte je v tomto pořadí podle důkazů. Rozložení toků mezi pracovníky pomáhá prvnímu případu a druhému neudělá nic. Větší instance pomáhá druhému a u prvního plýtvá penězi. Oprava MTU nebo ztrát je jediná, která se dotkne třetího. Kupovat kapacitu, než zjistíte, ve kterém řádku jste je drahá verze hádání.
Oddělte připnuté vlákno od zaneprázdněného hostitele
Začněte využitím po jádrech, aby se jedno připnuté jádro nemohlo schovat v průměru. Jeden běh během přenosu ukáže, zda je zátěž plochá, nebo špičkovaná. Oba tvary jsou informativní a špičkovaný profil často znamená, že okno vzorkování zachytilo činnost plánovače, a ne šifrování.
mpstat -P ALL 1 5
Přiřaďte zaneprázdněné jádro procesu a pak vláknu. Následující běh drží rodičovská a podřízená vlákna pohromadě, což je důležité, když se démon větví pro každé spojení:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10
Krypto v jádru se nikdy neobjeví v čítači uživatelského procesu. Vzorkujte vlákna samostatně a porovnejte tento pohled s účtováním procesu:
top -H -b -n 1 | head -20
Čítače socketů čtěte nakonec, protože rozhodují, zda by více CPU vůbec pomohlo. Rostoucí opakované přenosy při plochém CPU nejsou problém procesoru. Nechte přenos běžet, zatímco vzorkujete, jinak čísla popisují nečinný stroj:
ss -ti | grep -E 'retrans|cwnd|rtt'
Kontrolovaný přenos, spuštěný dvakrát
Nečinné čítače nic nedokazují a benchmark proti náhodnému koncovému bodu dokazuje velmi málo. Vyberte jednoho klienta, jeden cíl a jeden reprezentativní přenos, který smíte spustit, pak zachyťte propustnost a interaktivní zpoždění ve stejném okně. Brána se může nasytit, i když hromadná kopie ještě dokončuje, a křivka zpoždění je to, co uživatelé skutečně cítí. Napište přenos, počet klientů a verzi démona vedle čísel.
Běh zopakujte s několika paralelními toky. Zvyšování napříč toky naznačuje okna na tok; plochý průběh s jedním jádrem naplno naznačuje zpracování.
Pak zopakujte ještě jednou se zastavenými volitelnými zátěžemi. Záloha, odesílač logů nebo databáze na stejném hostiteli mohou vytvořit zaneprázdněný průměr, který s tunely nemá nic společného. Pokud je CPU stále naplno, zatímco hostitel je jinak tichý, důkazy ukazují na proces VPN. Pokud klesne, měřili jste souseda a brána nikdy nebyla problém.
Vylučte cestu, než koupíte hardware
Rostoucí opakované přenosy, zmenšující se okno přetížení a rostoucí doba odezvy ukazují pryč od procesoru. Porovnejte MTU tunelu s MTU cesty, zkontrolujte podkladové spojení na ztráty a potvrďte, že vlastní vzestupné spojení klienta není limitem. Větší brána neopraví spojení, které ztrácí pakety, a uživatelé obě závady popisují stejnými slovy. Čítač opakovaných přenosů je oddělí během minut.
Na virtuálním serveru přidejte metriky poskytovatele k těm hostovým. Ukradený čas je způsob, jakým se přeprodej stane viditelným uvnitř hosta, a žádné ladění uvnitř hosta ho neodstraní. Čítače hosta nevidí hostitele, takže čistý graf hosta není důkazem zdravého hostitele.
Jedna změna, jedno měření
Vyberte hypotézu, kterou důkazy podporují, a pak změňte přesně jedno podporované nastavení: počet pracovníků, dokumentovanou volbu odlehčení nebo velikost instance. OpenVPN publikuje průvodce řešením problémů s výkonem o stejném rozdělení mezi zpracováním a transportem: Řešení problémů s výkonem OpenVPN.
Ověřte, že volba odlehčení je skutečně aktivní, místo abyste věřili příznaku, pak zopakujte identický přenos a porovnejte srovnatelné. To je jediný způsob, jak rozeznat skutečné zlepšení od tichého odpoledne. Uchovejte kontrolní bod, který můžete obnovit, protože právě u druhé změny lidé ztrácejí přehled o tom, která pomohla. Jedna proměnná na běh je pomalá na den a rychlá na měsíc.
Nezeslabujte ověřování ani sadu šifer, aby graf vypadal lépe. Pokud CPU stále nesleduje příznak, vraťte se ke kontrolám cesty a aplikace, místo abyste upgradovali na základě dohadu.