CPU-hoz kötött a VPN-átjárója? Először a magonkénti terhelést olvassa
Az átlagok elrejtik a fontos szálat. Olvassa a magonkénti terhelést egy ellenőrzött átvitel mellett, zárja ki az útvonalat, majd futásonként egy dokumentált beállítást változtasson.
Döntse el, melyik három korlátot érte el, mielőtt nagyobb példányt vásárol. Egy mag teljes terhelése, míg a többi tétlen, folyamonkénti kriptomunkára utal. Ha átvitel közben minden mag telített, az összkapacitásra utal. Alacsony CPU növekvő újraküldésszámmal az útvonalra utal. Mindegyiknek más az első lépése, és csak az egyiket oldja meg egy nagyobb példány.
Három korlát, egy táblázat, három javítás
| 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 |
A sorokat diagnózisként olvassa, nem szakaszként. Egyetlen szál 100%-on, míg a többi tétlen, a leggyakoribb eredmény egy nagy alagutat szállító átjárón, mert annak a folyamnak a titkosítása egy magon fut. Ha átvitel közben minden mag foglalt, a gép már annyi munkát végez, amennyit tud. Az alacsony CPU növekvő újraküldésekkel azt jelenti, hogy a processzor olyan hálózatra vár, amely folyamatosan adatot veszít.
Ebben a bizonyítékok szerinti sorrendben javítsa őket. A folyamok munkások közötti szétosztása az első esetnek segít, a másodiknak semmit. A nagyobb példány a másodiknak segít, az elsőn pénzt pazarol. Az MTU vagy veszteség javítása az egyetlen, amely a harmadikat érinti. Kapacitást vásárolni, mielőtt tudná, melyik sorban van a találgatás drága változata.
Válassza külön a rögzített szálat a foglalt gazdagéptől
Kezdje a magonkénti kihasználtsággal, hogy egy rögzített mag ne rejtőzhessen el egy átlagban. Egyetlen futás az átvitel alatt megmutatja, lapos-e a terhelés vagy csúcsos. Mindkét forma tanulságos, és a csúcsos profil gyakran azt jelenti, hogy a mintavételi ablak az ütemező tevékenységét kapta el a titkosítás helyett.
mpstat -P ALL 1 5Rendelje a foglalt magot egy folyamathoz, majd egy szálhoz. Az alábbi követő futás együtt tartja a szülő- és gyermekszálakat, ami számít, amikor a démon kapcsolatonként elágazik:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10A kernel kriptográfia soha nem jelenik meg felhasználói térbeli folyamatszámlálóban. Mintavételezze a szálakat külön, és hasonlítsa össze ezt a nézetet a folyamat elszámolásával:
top -H -b -n 1 | head -20A socket-számlálókat utoljára olvassa, mert azok döntik el, hogy egyáltalán segítene-e több CPU. Az újraküldések növekedése lapos CPU mellett nem processzorprobléma. Tartsa futva az átvitelt a mintavétel alatt, különben a számok egy tétlen gépet írnak le:
ss -ti | grep -E 'retrans|cwnd|rtt'Egy ellenőrzött átvitel, kétszer futtatva
A tétlen számlálók semmit sem bizonyítanak, és egy véletlenszerű végpont elleni mérés nagyon keveset. Válasszon egy klienst, egy célt és egy reprezentatív átvitelt, amelyet futtathat, majd rögzítse az áteresztőképességet és az interaktív késleltetést ugyanabban az ablakban. Az átjáró telítődhet, miközben egy tömeges másolás még befejeződik, és a késleltetési görbe az, amit a felhasználók valóban éreznek. Írja fel az átvitelt, az ügyfélszámot és a démon verzióját a számok mellé.
Ismételje meg a futást több párhuzamos folyammal. A folyamok közötti növekedés folyamonkénti ablakozásra utal; a lapos maradás egy rögzített mag mellett feldolgozásra utal.
Utána ismételje meg még egyszer, a választható munkaterhelések leállításával. Egy biztonsági mentés, egy naplóküldő vagy egy adatbázis ugyanazon a gazdagépen olyan foglalt átlagot hozhat, amelynek semmi köze az alagutakhoz. Ha a CPU továbbra is rögzített, miközben a gazdagép egyébként csendes, a bizonyítékok a VPN-folyamatra mutatnak. Ha leesik, a szomszédot mérte, és az átjáró soha nem volt a probléma.
Zárja ki az útvonalat, mielőtt hardvert vásárol
A növekvő újraküldések, a zsugorodó torlódási ablak és a növekvő oda-vissza idő mind a processzortól távolra mutatnak. Hasonlítsa össze az alagút MTU-ját az útvonal MTU-jával, ellenőrizze az alapul szolgáló kapcsolatot veszteségre, és erősítse meg, hogy az ügyfél saját feltöltési kapcsolata nem a korlát. A nagyobb átjáró nem javít meg egy kapcsolatot, amely csomagokat ejt, és a felhasználók mindkét hibát ugyanazokkal a szavakkal írják le. Az újraküldésszámláló percek alatt elválasztja őket.
Virtuális szerveren adja hozzá a szolgáltató mérőszámait a vendég sajátjaihoz. A lopott idő az, ahogy a túlértékesítés láthatóvá válik a vendégen belül, és semmilyen hangolás a vendégen belül nem szünteti meg. A vendég számlálói nem látják a gazdagépet, ezért a tiszta vendéggrafikon nem bizonyíték az egészséges gazdagépre.
Egy változtatás, egy mérés
Válassza ki a bizonyítékok által támogatott hipotézist, majd pontosan egy támogatott beállítást változtasson: a munkások számát, egy dokumentált offload-beállítást vagy a példány méretét. Az OpenVPN teljesítmény-hibaelhárítási útmutatót tesz közzé a feldolgozás és a szállítás ugyanazon felosztásáról: OpenVPN teljesítmény-hibaelhárítás.
Ellenőrizze, hogy az offload-beállítás valóban aktív, ahelyett hogy a jelzőben bízna, majd futtassa újra ugyanazt az átvitelt, és hasonlítsa össze a hasonlót a hasonlóval. Ez az egyetlen módja annak, hogy megkülönböztessen egy valódi javulást egy csendes délutántól. Tartson egy visszaállítható ellenőrzőpontot, mert a második változtatásnál az emberek elveszítik a fonalat, hogy melyik segített. Futásonként egy változó egy napra lassú és egy hónapra gyors.
Ne gyengítse a hitelesítést vagy a titkosítási készletet, hogy a grafikon jobban nézzen ki. Ha a CPU továbbra sem követi a tünetet, térjen vissza az útvonal- és alkalmazásellenőrzésekhez, ahelyett hogy találgatásra frissítene.