A súa pasarela VPN está limitada pola CPU? Lea primeiro a carga por núcleo
As medias agochan o fío que importa. Lea a carga por núcleo fronte a unha transferencia controlada, descarte a ruta e despois cambie un axuste documentado por execución.
Decida cal dos tres límites acadou antes de comprar unha instancia máis grande. Un núcleo ao máximo mentres o resto está inactivo apunta a traballo criptográfico por fluxo. Todos os núcleos saturados durante unha transferencia apuntan a capacidade agregada. Unha CPU baixa cun reconto crecente de retransmisións apunta á ruta. Cada caso ten un primeiro movemento distinto, e só un se resolve cunha instancia máis grande.
Tres límites, unha táboa, tres correccións
| 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 |
Lea as filas como diagnósticos, non como etapas. Un só fío ao 100% mentres os demais están inactivos é o resultado máis común nunha pasarela que leva un túnel grande, porque o cifrado dese fluxo execútase nun núcleo. Todos os núcleos ocupados durante a transferencia significa que a máquina xa fai todo o traballo que pode. Unha CPU baixa con retransmisións crecentes significa que o procesador espera unha rede que non deixa de perder datos.
Corríxaos nesa orde de evidencia. Repartir fluxos entre traballadores axuda ao primeiro caso e non fai nada polo segundo. Unha instancia máis grande axuda ao segundo e desperdicia diñeiro no primeiro. Unha corrección de MTU ou de perda é a única que toca o terceiro. Comprar capacidade antes de saber en que fila está é a versión cara de adiviñar.
Separe un fío fixado dun servidor ocupado
Comece pola utilización por núcleo, para que un núcleo fixado non poida agocharse dentro dunha media. Unha soa execución durante a transferencia mostra se a carga é plana ou con picos. Ambas as formas son informativas, e un perfil con picos a miúdo significa que a xanela de mostraxe capturou actividade do planificador en lugar do cifrado.
mpstat -P ALL 1 5Atribúa o núcleo ocupado a un proceso e despois a un fío. A execución de seguimento de abaixo mantén xuntos os fíos pai e fillo, o que importa cando o demo fai fork por conexión:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10A criptografía do núcleo nunca aparece nun contador de proceso de espazo de usuario. Mostree os fíos por separado e compare esa vista coa contabilidade do proceso:
top -H -b -n 1 | head -20Lea os contadores de sockets ao final, porque deciden se máis CPU axudaría sequera. Retransmisións que soben coa CPU plana non é un problema do procesador. Manteña a transferencia en marcha mentres mostra, ou os números describirán unha máquina inactiva:
ss -ti | grep -E 'retrans|cwnd|rtt'Unha transferencia controlada, executada dúas veces
Os contadores inactivos non proban nada, e unha proba contra un extremo aleatorio proba moi pouco. Escolla un cliente, un destino e unha transferencia representativa que teña permitido executar, e despois capture o caudal e a latencia interactiva na mesma xanela. Unha pasarela pode saturarse mentres unha copia masiva aínda remata, e a curva de latencia é o que os usuarios senten de verdade. Escriba a transferencia, o número de clientes e a versión do demo xunto aos números.
Repita a execución con varios fluxos en paralelo. Escalar cara arriba cos fluxos suxire ventás por fluxo; quedarse plano cun núcleo fixado suxire procesamento.
Despois repita unha vez máis coas cargas opcionais detidas. Unha copia de seguridade, un remitente de rexistros ou unha base de datos no mesmo servidor poden producir unha media ocupada que nada ten que ver cos túneles. Se a CPU segue fixada co servidor por outra parte tranquilo, a evidencia apunta ao proceso VPN. Se baixa, estaba medindo ao veciño, e a pasarela nunca foi o problema.
Descarte a ruta antes de comprar hardware
Retransmisións crecentes, unha xanela de conxestión que encolle e un tempo de ida e volta crecente apuntan lonxe do procesador. Compare o MTU do túnel co MTU da ruta, revise o enlace subxacente en busca de perdas e confirme que a ligazón ascendente do cliente non é o límite. Unha pasarela máis grande non repara un enlace que perde paquetes, e os usuarios describen as dúas fallas coas mesmas palabras. O contador de retransmisións séparaas en minutos.
Nun servidor virtual, engada as métricas do provedor ás do convidado. O tempo roubado é como a sobrevenda se fai visible dentro do convidado, e ningún axuste dentro do convidado o elimina. Os contadores do convidado non ven o host, así que un gráfico limpo do convidado non é proba dun host san.
Un cambio, unha medición
Escolla a hipótese que apoia a evidencia e despois cambie exactamente un axuste admitido: número de traballadores, unha opción de descarga documentada ou o tamaño da instancia. OpenVPN publica unha guía de solución de problemas de rendemento sobre a mesma división entre procesamento e transporte: Solución de problemas de rendemento de OpenVPN.
Confirme que a opción de descarga está realmente activa en lugar de confiar no indicador, despois repita a transferencia idéntica e compare o comparable. É a única forma de distinguir unha mellora real dunha tarde tranquila. Conserve un punto de control que poida restaurar, porque no segundo cambio a xente perde a pista de cal axudou. Unha variable por execución é lenta durante un día e rápida durante un mes.
Non debilite a autenticación nin o conxunto de cifrados para que o gráfico pareza mellor. Se a CPU segue sen seguir o síntoma, volva ás comprobacións de ruta e aplicación en lugar de actualizar a cegas.