Seu gateway VPN está limitado pela CPU? Leia primeiro a carga por núcleo

Decida qual dos três limites você atingiu antes de comprar uma instância maior. Um núcleo no máximo enquanto o resto está ocioso aponta para trabalho criptográfico por fluxo. Todos os núcleos saturados durante uma transferência apontam para capacidade agregada. CPU baixa com contagem crescente de retransmissões aponta para o caminho. Cada um tem um primeiro movimento diferente, e apenas um se resolve com uma instância maior.

Três limites, uma tabela, três correções

Leia as linhas como diagnósticos, não como etapas. Um único thread a 100% enquanto os outros estão ociosos é o resultado mais comum em um gateway com um túnel grande, porque a criptografia desse fluxo roda em um núcleo. Todos os núcleos ocupados durante a transferência significa que a máquina já faz todo o trabalho que pode. CPU baixa com retransmissões crescendo significa que o processador espera uma rede que não para de perder dados.

Corrija-os nessa ordem de evidência. Distribuir fluxos entre workers ajuda o primeiro caso e não faz nada pelo segundo. Uma instância maior ajuda o segundo e desperdiça dinheiro no primeiro. Uma correção de MTU ou perda é a única que toca o terceiro. Comprar capacidade antes de saber em qual linha você está é a versão cara de adivinhar.

Separe um thread fixado de um host ocupado

Comece pela utilização por núcleo, para que um núcleo fixado não possa se esconder dentro de uma média. Uma única execução durante a transferência mostra se a carga é plana ou com picos. As duas formas são informativas, e um perfil com picos muitas vezes significa que a janela de amostragem capturou atividade do escalonador em vez da criptografia.

mpstat -P ALL 1 5

Atribua o núcleo ocupado a um processo e depois a um thread. A execução de acompanhamento abaixo mantém threads pai e filho juntos, o que importa quando o daemon faz fork por conexão:

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

A criptografia do kernel nunca aparece em um contador de processo no espaço do usuário. Amostre threads separadamente e compare essa visão com a contabilidade do processo:

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

Leia os contadores de socket por último, porque eles decidem se mais CPU ajudaria de alguma forma. Retransmissões subindo com CPU plana não é problema do processador. Mantenha a transferência em execução enquanto amostra, ou os números descreverão uma máquina ociosa:

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

Uma transferência controlada, executada duas vezes

Contadores ociosos não provam nada, e um benchmark contra um endpoint aleatório prova muito pouco. Escolha um cliente, um destino e uma transferência representativa que você tenha permissão para executar, depois capture a vazão e a latência interativa na mesma janela. Um gateway pode saturar enquanto uma cópia em massa ainda termina, e a curva de latência é o que os usuários realmente sentem. Escreva a transferência, o número de clientes e a versão do daemon ao lado dos números.

Repita a execução com vários fluxos em paralelo. Escalar com os fluxos sugere janelas por fluxo; ficar plano com um núcleo fixado sugere processamento.

Depois repita mais uma vez com as cargas opcionais paradas. Um backup, um remetente de logs ou um banco de dados no mesmo host podem produzir uma média ocupada que não tem nada a ver com túneis. Se a CPU continua fixada com o host de resto silencioso, a evidência aponta para o processo VPN. Se cair, você estava medindo o vizinho, e o gateway nunca foi o problema.

Descarte o caminho antes de comprar hardware

Retransmissões crescentes, uma janela de congestão encolhendo e um tempo de ida e volta crescendo apontam para longe do processador. Compare o MTU do túnel com o MTU do caminho, verifique o enlace subjacente quanto a perdas e confirme que o uplink do próprio cliente não é o limite. Um gateway maior não conserta um enlace que perde pacotes, e os usuários descrevem as duas falhas com as mesmas palavras. O contador de retransmissões separa as duas em minutos.

Em um servidor virtual, adicione as métricas do provedor às do convidado. O tempo roubado é como a sobrevenda se torna visível dentro do convidado, e nenhum ajuste dentro do convidado o remove. Os contadores do convidado não veem o host, então um gráfico limpo do convidado não é prova de um host saudável.

Uma mudança, uma medição

Escolha a hipótese que a evidência sustenta e então mude exatamente uma configuração suportada: número de workers, uma opção de offload documentada ou o tamanho da instância. A OpenVPN publica um guia de solução de problemas de desempenho sobre a mesma divisão entre processamento e transporte: Solução de problemas de desempenho da OpenVPN.

Confirme que a opção de offload está realmente ativa em vez de confiar na flag, depois repita a transferência idêntica e compare o comparável. É o único modo de distinguir uma melhoria real de uma tarde tranquila. Mantenha um ponto de verificação que você possa restaurar, porque na segunda mudança as pessoas perdem a noção de qual ajudou. Uma variável por execução é lenta por um dia e rápida por um mês.

Não enfraqueça a autenticação nem o conjunto de cifras para deixar o gráfico mais bonito. Se a CPU ainda não segue o sintoma, volte às verificações de caminho e aplicação em vez de atualizar com base em um palpite.