Il tuo gateway VPN è limitato dalla CPU? Leggi prima il carico per core

Decidi quale dei tre limiti hai raggiunto prima di comprare un’istanza più grande. Un core al massimo mentre gli altri restano inattivi indica lavoro crittografico per flusso. Tutti i core saturi durante un trasferimento indicano capacità aggregata. Una CPU bassa con un numero crescente di ritrasmissioni indica il percorso. Ognuno ha un primo passo diverso, e solo uno si risolve con un’istanza più grande.

Tre limiti, una tabella, tre correzioni

Leggi le righe come diagnosi, non come fasi. Un solo thread al 100% mentre gli altri sono inattivi è il risultato più comune su un gateway che porta un grande tunnel, perché la crittografia di quel flusso gira su un solo core. Tutti i core occupati durante il trasferimento significa che la macchina sta già facendo tutto il lavoro che può. Una CPU bassa con ritrasmissioni in aumento significa che il processore attende una rete che continua a perdere dati.

Correggili in quest’ordine di prove. Distribuire i flussi tra i worker aiuta il primo caso e non fa nulla per il secondo. Un’istanza più grande aiuta il secondo e spreca denaro sul primo. Una correzione di MTU o di perdita è l’unica che tocca il terzo. Comprare capacità prima di sapere in quale riga ti trovi è la versione costosa dell’indovinare.

Separa un thread fissato da un host occupato

Parti dall’utilizzo per core, così un core fissato non può nascondersi dentro una media. Una sola esecuzione durante il trasferimento mostra se il carico è piatto o a picchi. Entrambe le forme sono informative, e un profilo a picchi spesso significa che la finestra di campionamento ha colto l’attività dello scheduler invece della crittografia.

mpstat -P ALL 1 5

Attribuisci il core occupato a un processo, poi a un thread. L’esecuzione di follow-up qui sotto tiene insieme i thread padre e figlio, cosa che conta quando il demone fa fork per connessione:

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

La crittografia del kernel non compare mai in un contatore di processo in spazio utente. Campiona i thread separatamente e confronta quella vista con la contabilità del processo:

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

Leggi i contatori dei socket per ultimi, perché decidono se più CPU aiuterebbe davvero. Ritrasmissioni che salgono con la CPU piatta non sono un problema del processore. Mantieni il trasferimento in corso mentre campioni, altrimenti i numeri descrivono una macchina inattiva:

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

Un trasferimento controllato, eseguito due volte

I contatori a riposo non provano nulla, e un benchmark contro un endpoint casuale prova molto poco. Scegli un client, una destinazione e un trasferimento rappresentativo che ti è consentito eseguire, poi registra throughput e latenza interattiva nella stessa finestra. Un gateway può saturarsi mentre una copia massiva è ancora in corso, e la curva di latenza è ciò che gli utenti sentono davvero. Scrivi il trasferimento, il numero di client e la versione del demone accanto ai numeri.

Ripeti l’esecuzione con più flussi paralleli. La crescita tra i flussi suggerisce finestre per flusso; restare piatto con un core fissato suggerisce elaborazione.

Poi ripeti ancora una volta con i carichi opzionali fermi. Un backup, un invio di log o un database sullo stesso host possono produrre una media occupata che non ha nulla a che fare con i tunnel. Se la CPU è ancora fissata mentre l’host è altrimenti tranquillo, le prove indicano il processo VPN. Se scende, stavi misurando il vicino, e il gateway non è mai stato il problema.

Escludi il percorso prima di comprare hardware

Ritrasmissioni in aumento, una finestra di congestione che si restringe e un tempo di andata e ritorno crescente indicano tutti lontano dal processore. Confronta l’MTU del tunnel con l’MTU del percorso, controlla il collegamento sottostante per le perdite e conferma che l’uplink del client non sia il limite. Un gateway più grande non ripara un collegamento che perde pacchetti, e gli utenti descrivono entrambi i guasti con le stesse parole. Il contatore delle ritrasmissioni li separa in pochi minuti.

Su un server virtuale, aggiungi le metriche del provider a quelle del guest. Il tempo rubato è il modo in cui la sovravendita diventa visibile dentro il guest, e nessun tuning dentro il guest lo elimina. I contatori del guest non vedono l’host, quindi un grafico pulito del guest non è prova di un host sano.

Un cambiamento, una misura

Scegli l’ipotesi che le prove sostengono, poi cambia esattamente un’impostazione supportata: numero di worker, un’opzione di offload documentata o la dimensione dell’istanza. OpenVPN pubblica una guida alla risoluzione dei problemi di prestazioni sulla stessa separazione tra elaborazione e trasporto: Risoluzione dei problemi di prestazioni di OpenVPN.

Verifica che l’opzione di offload sia realmente attiva invece di fidarti del flag, poi ripeti il trasferimento identico e confronta il confrontabile. È l’unico modo per distinguere un miglioramento reale da un pomeriggio tranquillo. Conserva un punto di controllo che puoi ripristinare, perché è al secondo cambiamento che le persone perdono traccia di quale abbia aiutato. Una variabile per esecuzione è lenta per un giorno e veloce per un mese.

Non indebolire l’autenticazione o la suite di cifratura per far sembrare il grafico migliore. Se la CPU continua a non seguire il sintomo, torna ai controlli di percorso e applicazione invece di aggiornare sulla base di un’ipotesi.