Votre passerelle VPN est-elle limitée par le CPU ? Lisez d’abord la charge par cœur

Déterminez laquelle des trois limites vous avez atteinte avant d’acheter une instance plus grande. Un cœur à fond tandis que les autres restent inactifs indique un travail cryptographique par flux. Tous les cœurs saturés pendant un transfert indiquent une capacité globale. Un CPU faible avec un nombre croissant de retransmissions indique le chemin. Chacune a un premier geste différent, et une seule se résout avec une instance plus grande.

Trois limites, un tableau, trois correctifs

Lisez les lignes comme des diagnostics, pas comme des étapes. Un seul fil à 100 % pendant que les autres restent inactifs est le résultat le plus courant sur une passerelle portant un grand tunnel, car le chiffrement de ce flux tourne sur un seul cœur. Tous les cœurs occupés pendant le transfert signifie que la machine fait déjà tout le travail qu’elle peut. Un CPU faible avec des retransmissions en hausse signifie que le processeur attend un réseau qui ne cesse de perdre des données.

Corrigez-les dans cet ordre de preuves. Répartir les flux entre les workers aide le premier cas et ne fait rien pour le second. Une instance plus grande aide le second et gaspille de l’argent sur le premier. Un correctif de MTU ou de perte est le seul qui touche le troisième. Acheter de la capacité avant de savoir dans quelle ligne vous êtes est la version coûteuse de la devinette.

Séparer un fil épinglé d’un hôte occupé

Commencez par l’utilisation par cœur, afin qu’un cœur épinglé ne puisse pas se cacher dans une moyenne. Une seule exécution pendant le transfert montre si la charge est plate ou en pics. Les deux formes sont instructives, et un profil en pics signifie souvent que la fenêtre d’échantillonnage a capté l’activité de l’ordonnanceur plutôt que le chiffrement.

mpstat -P ALL 1 5

Attribuez le cœur occupé à un processus, puis à un fil. L’exécution de suivi ci-dessous garde les fils parent et enfant ensemble, ce qui compte quand le démon se fork par connexion :

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

La cryptographie du noyau n’apparaît jamais dans un compteur de processus en espace utilisateur. Échantillonnez les fils séparément et comparez cette vue à la comptabilité du processus :

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

Lisez les compteurs de sockets en dernier, car ils décident si davantage de CPU aiderait seulement. Des retransmissions qui montent avec un CPU plat ne sont pas un problème de processeur. Gardez le transfert en cours pendant l’échantillonnage, sinon les chiffres décrivent une machine inactive :

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

Un transfert contrôlé, exécuté deux fois

Les compteurs au repos ne prouvent rien, et un benchmark contre un point de terminaison aléatoire prouve très peu. Choisissez un client, une destination et un transfert représentatif que vous êtes autorisé à exécuter, puis capturez le débit et la latence interactive dans la même fenêtre. Une passerelle peut saturer pendant qu’une copie massive s’achève encore, et la courbe de latence est ce que les utilisateurs ressentent vraiment. Écrivez le transfert, le nombre de clients et la version du démon à côté des chiffres.

Répétez l’exécution avec plusieurs flux parallèles. La montée en charge avec les flux suggère une fenêtre par flux ; rester plat avec un cœur épinglé suggère du traitement.

Répétez ensuite une fois de plus avec les charges optionnelles arrêtées. Une sauvegarde, un expéditeur de journaux ou une base de données sur le même hôte peuvent produire une moyenne occupée qui n’a rien à voir avec les tunnels. Si le CPU reste épinglé alors que l’hôte est autrement calme, les preuves pointent vers le processus VPN. S’il baisse, vous mesuriez le voisin, et la passerelle n’a jamais été le problème.

Écarter le chemin avant d’acheter du matériel

Des retransmissions en hausse, une fenêtre de congestion qui rétrécit et un temps aller-retour croissant pointent tous loin du processeur. Comparez le MTU du tunnel au MTU du chemin, vérifiez la liaison sous-jacente pour les pertes et confirmez que l’uplink du client n’est pas la limite. Une passerelle plus grande ne répare pas une liaison qui perd des paquets, et les utilisateurs décrivent les deux pannes avec les mêmes mots. Le compteur de retransmissions les sépare en quelques minutes.

Sur un serveur virtuel, ajoutez les métriques du fournisseur à celles de l’invité. Le temps volé est la façon dont la sursouscription devient visible dans l’invité, et aucun réglage dans l’invité ne le supprime. Les compteurs de l’invité ne voient pas l’hôte, donc un graphe d’invité propre n’est pas la preuve d’un hôte sain.

Un changement, une mesure

Choisissez l’hypothèse que les preuves soutiennent, puis changez exactement un réglage pris en charge : nombre de workers, une option de déchargement documentée ou la taille de l’instance. OpenVPN publie un guide de dépannage des performances sur la même séparation entre traitement et transport : Dépannage des performances OpenVPN.

Confirmez que l’option de déchargement est réellement active au lieu de faire confiance au drapeau, puis relancez le transfert identique et comparez ce qui est comparable. C’est le seul moyen de distinguer une amélioration réelle d’un après-midi calme. Gardez un point de contrôle que vous pouvez restaurer, car c’est au second changement que les gens perdent la trace de celui qui a aidé. Une variable par exécution est lent pour un jour et rapide pour un mois.

N’affaiblissez pas l’authentification ni la suite de chiffrement pour faire paraître le graphe meilleur. Si le CPU ne suit toujours pas le symptôme, revenez aux vérifications du chemin et de l’application au lieu de mettre à niveau sur une supposition.