El vostre gateway VPN està limitat per la CPU? Llegiu primer la càrrega per nucli
Les mitjanes amaguen el fil que importa. Llegiu la càrrega per nucli davant d’una transferència controlada, descarteu el camí i després canvieu un paràmetre documentat per execució.
Decidiu quin dels tres límits heu assolit abans de comprar una instància més gran. Un nucli al màxim amb la resta inactius apunta a feina criptogràfica per flux. Tots els nuclis saturats durant una transferència apunten a capacitat agregada. Una CPU baixa amb un recompte creixent de retransmissions apunta al camí. Cada cas té un primer moviment diferent, i només un es resol amb una instància més gran.
Tres límits, una taula, tres solucions
| 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 |
Llegiu les files com a diagnòstics, no com a etapes. Un sol fil al 100% mentre els altres estan inactius és el resultat més habitual en una passarel·la que porta un túnel gran, perquè el xifratge d’aquell flux va en un nucli. Tots els nuclis ocupats durant la transferència vol dir que la màquina ja fa tanta feina com pot. CPU baixa amb retransmissions creixents vol dir que el processador espera una xarxa que no deixa de perdre dades.
Solucioneu-los en aquest ordre d’evidència. Repartir fluxos entre treballadors ajuda el primer cas i no fa res pel segon. Una instància més gran ajuda el segon i malbarata diners en el primer. Una correcció d’MTU o de pèrdua és l’única que toca el tercer. Comprar capacitat abans de saber en quina fila esteu és la versió cara d’endevinar.
Separeu un fil fixat d’un amfitrió ocupat
Comenceu per la utilització per nucli, perquè un nucli fixat no pugui amagar-se dins d’una mitjana. Una sola execució durant la transferència mostra si la càrrega és plana o amb pics. Totes dues formes són informatives, i un perfil amb pics sovint vol dir que la finestra de mostreig va capturar activitat del planificador en lloc del xifratge.
mpstat -P ALL 1 5Atribuïu el nucli ocupat a un procés i després a un fil. L’execució de seguiment de sota manté junts els fils pare i fill, cosa que importa quan el dimoni es bifurca per connexió:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10La criptografia del nucli no apareix mai en un comptador de procés d’espai d’usuari. Mostregeu els fils per separat i compareu aquesta vista amb la comptabilitat del procés:
top -H -b -n 1 | head -20Llegiu els comptadors de sockets al final, perquè decideixen si més CPU ajudaria de bon grat. Retransmissions que pugen amb la CPU plana no és un problema del processador. Mantingueu la transferència en marxa mentre mostregeu, o els números descriuran una màquina inactiva:
ss -ti | grep -E 'retrans|cwnd|rtt'Una transferència controlada, executada dues vegades
Els comptadors en repòs no proven res, i una prova contra un extrem aleatori prova molt poc. Trieu un client, una destinació i una transferència representativa que pugueu executar, i després captureu el cabal i el retard interactiu a la mateixa finestra. Una passarel·la es pot saturar mentre una còpia massiva encara acaba, i la corba de retard és el que els usuaris senten de debò. Escriviu la transferència, el nombre de clients i la versió del dimoni al costat dels números.
Repetiu l’execució amb diversos fluxos en paral·lel. Escalar amunt amb els fluxos suggereix finestres per flux; quedar-se pla amb un nucli fixat suggereix processament.
Després repetiu una vegada més amb les càrregues opcionals aturades. Una còpia de seguretat, un enviador de registres o una base de dades al mateix amfitrió poden produir una mitjana ocupada que no té res a veure amb els túnels. Si la CPU continua fixada amb l’amfitrió d’altra banda tranquil, l’evidència apunta al procés VPN. Si baixa, estàveu mesurant el veí, i la passarel·la mai no va ser el problema.
Descarteu el camí abans de comprar maquinari
Retransmissions creixents, una finestra de congestió que s’encongeix i un temps d’anada i tornada creixent apunten lluny del processador. Compareu l’MTU del túnel amb l’MTU del camí, reviseu l’enllaç subjacent per pèrdues i confirmeu que l’enllaç ascendent del client no és el límit. Una passarel·la més gran no repara un enllaç que perd paquets, i els usuaris descriuen les dues falles amb les mateixes paraules. El comptador de retransmissions les separa en minuts.
En un servidor virtual, afegiu les mètriques del proveïdor a les del convidat. El temps robat és com la sobrevenda es fa visible dins del convidat, i cap ajustament dins del convidat no l’elimina. Els comptadors del convidat no veuen l’amfitrió, així que un gràfic net del convidat no és prova d’un amfitrió sa.
Un canvi, una mesura
Trieu la hipòtesi que l’evidència sosté i canvieu exactament un paràmetre suportat: nombre de treballadors, una opció de descàrrega documentada o la mida de la instància. OpenVPN publica una guia per resoldre problemes de rendiment sobre la mateixa separació entre processament i transport: Resolució de problemes de rendiment d’OpenVPN.
Confirmeu que l’opció de descàrrega és realment activa en lloc de confiar en el senyalador, i després repetiu la transferència idèntica i compareu el que és comparable. És l’única manera de distingir una millora real d’una tarda tranquil·la. Mantingueu un punt de control que pugueu restaurar, perquè al segon canvi la gent perd el rastre de quin va ajudar. Una variable per execució és lent per a un dia i ràpid per a un mes.
No debiliteu l’autenticació ni el conjunt de xifratges perquè el gràfic sembli millor. Si la CPU encara no segueix el símptoma, torneu a les comprovacions de camí i aplicació en lloc d’actualitzar a cegues.