Ist Ihr VPN-Gateway CPU-gebunden? Lesen Sie zuerst die Last pro Kern

Entscheiden Sie, welche der drei Grenzen Sie erreicht haben, bevor Sie eine größere Instanz kaufen. Ein Kern am Anschlag, während die übrigen untätig sind, deutet auf Kryptoarbeit pro Fluss hin. Sind während einer Übertragung alle Kerne gesättigt, deutet das auf Gesamtkapazität hin. Wenig CPU bei steigender Zahl an Neuübertragungen deutet auf den Pfad hin. Jede hat einen anderen ersten Schritt, und nur eine davon wird durch eine größere Instanz gelöst.

Drei Grenzen, eine Tabelle, drei Korrekturen

Lesen Sie die Zeilen als Diagnosen, nicht als Stufen. Ein einzelner Thread bei 100 %, während die anderen untätig sind, ist das häufigste Ergebnis auf einem Gateway mit einem großen Tunnel, weil die Verschlüsselung dieses Flusses auf einem Kern läuft. Sind während der Übertragung alle Kerne beschäftigt, leistet die Maschine bereits so viel Arbeit, wie sie kann. Wenig CPU bei steigenden Neuübertragungen bedeutet, dass der Prozessor auf ein Netzwerk wartet, das fortlaufend Daten verliert.

Beheben Sie sie in dieser Reihenfolge der Belege. Flüsse über Worker zu verteilen hilft dem ersten Fall und bewirkt nichts für den zweiten. Eine größere Instanz hilft dem zweiten und verschwendet Geld beim ersten. Eine MTU- oder Verlustkorrektur ist die einzige, die den dritten berührt. Kapazität kaufen, bevor Sie wissen, in welcher Zeile Sie stehen ist die teure Variante des Ratens.

Einen festgefahrenen Thread von einem beschäftigten Host trennen

Beginnen Sie mit der Auslastung pro Kern, damit sich ein festgefahrener Kern nicht in einem Durchschnitt verstecken kann. Ein einzelner Lauf während der Übertragung zeigt, ob die Last flach oder spitzig ist. Beide Formen sind aufschlussreich, und ein spitziges Profil bedeutet oft, dass das Abtastfenster Scheduler-Aktivität statt Verschlüsselung erfasst hat.

mpstat -P ALL 1 5

Ordnen Sie den beschäftigten Kern einem Prozess und dann einem Thread zu. Der folgende Nachlauf hält Eltern- und Kind-Threads zusammen, was zählt, wenn der Daemon pro Verbindung forkt:

pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10

Kernel-Krypto erscheint nie in einem Userspace-Prozesszähler. Tasten Sie Threads separat ab und vergleichen Sie diese Sicht mit der Prozessabrechnung:

top -H -b -n 1 | head -20

Lesen Sie die Socket-Zähler zuletzt, denn sie entscheiden, ob mehr CPU überhaupt helfen würde. Steigende Neuübertragungen bei flacher CPU sind kein Prozessorproblem. Halten Sie die Übertragung am Laufen, während Sie messen, sonst beschreiben die Zahlen eine untätige Maschine:

ss -ti | grep -E 'retrans|cwnd|rtt'

Eine kontrollierte Übertragung, zweimal ausgeführt

Untätige Zähler beweisen nichts, und ein Benchmark gegen einen zufälligen Endpunkt beweist sehr wenig. Wählen Sie einen Client, ein Ziel und eine repräsentative Übertragung, die Sie ausführen dürfen, und erfassen Sie dann Durchsatz und interaktive Verzögerung im selben Fenster. Ein Gateway kann gesättigt sein, während eine Massenkopie noch abschließt, und die Verzögerungskurve ist das, was Nutzer tatsächlich spüren. Schreiben Sie Übertragung, Clientanzahl und Daemon-Version neben die Zahlen.

Wiederholen Sie den Lauf mit mehreren parallelen Flüssen. Skalierung über Flüsse hinweg deutet auf Fensterung pro Fluss hin; flach zu bleiben, während ein Kern am Anschlag ist, deutet auf Verarbeitung hin.

Wiederholen Sie dann noch einmal mit gestoppten optionalen Arbeitslasten. Ein Backup, ein Log-Shipper oder eine Datenbank auf demselben Host können einen beschäftigten Durchschnitt erzeugen, der nichts mit Tunneln zu tun hat. Ist die CPU weiterhin am Anschlag, während der Host sonst ruhig ist, weisen die Belege auf den VPN-Prozess. Fällt sie, haben Sie den Nachbarn gemessen, und das Gateway war nie das Problem.

Den Pfad ausschließen, bevor Sie Hardware kaufen

Steigende Neuübertragungen, ein schrumpfendes Überlastfenster und wachsende Umlaufzeit weisen alle vom Prozessor weg. Vergleichen Sie die Tunnel-MTU mit der Pfad-MTU, prüfen Sie die zugrunde liegende Strecke auf Verluste und bestätigen Sie, dass der eigene Uplink des Clients nicht die Grenze ist. Ein größeres Gateway repariert keine Strecke, die Pakete verwirft, und Nutzer beschreiben beide Fehler mit denselben Worten. Der Neuübertragungszähler trennt sie in Minuten.

Fügen Sie auf einem virtuellen Server die Metriken des Anbieters denen des Gasts hinzu. Gestohlene Zeit ist der Weg, wie Überbuchung im Gast sichtbar wird, und kein Tuning im Gast beseitigt sie. Gastzähler können den Host nicht sehen, also ist ein sauberer Gastgraph kein Beweis für einen gesunden Host.

Eine Änderung, eine Messung

Wählen Sie die Hypothese, die die Belege stützen, und ändern Sie dann genau eine unterstützte Einstellung: Worker-Anzahl, eine dokumentierte Offload-Option oder die Instanzgröße. OpenVPN veröffentlicht eine Anleitung zur Fehlerbehebung bei der Leistung zu derselben Trennung zwischen Verarbeitung und Transport: OpenVPN-Leistungsfehlerbehebung.

Prüfen Sie, ob die Offload-Option tatsächlich aktiv ist, statt dem Flag zu vertrauen, führen Sie dann die identische Übertragung erneut aus und vergleichen Sie Gleiches mit Gleichem. Nur so lässt sich eine echte Verbesserung von einem ruhigen Nachmittag unterscheiden. Behalten Sie einen Kontrollpunkt, den Sie wiederherstellen können, denn bei der zweiten Änderung verlieren Leute den Überblick, welche geholfen hat. Eine Variable pro Lauf ist für einen Tag langsam und für einen Monat schnell.

Schwächen Sie Authentifizierung oder Cipher-Suite nicht, damit der Graph besser aussieht. Wenn die CPU dem Symptom weiterhin nicht folgt, kehren Sie zu Pfad- und Anwendungsprüfungen zurück, statt auf Verdacht aufzurüsten.