¿Su puerta de enlace VPN está limitada por la CPU? Lea primero la carga por núcleo
Los promedios ocultan el hilo que importa. Lea la carga por núcleo frente a una transferencia controlada, descarte la ruta y luego cambie un ajuste documentado por ejecución.
Decida cuál de los tres límites ha alcanzado antes de comprar una instancia más grande. Un núcleo al máximo mientras el resto está inactivo apunta a trabajo criptográfico por flujo. Todos los núcleos saturados durante una transferencia apuntan a capacidad agregada. Una CPU baja con un recuento creciente de retransmisiones apunta a la ruta. Cada caso tiene un primer movimiento distinto, y solo uno se resuelve con una instancia más grande.
Tres límites, una tabla, tres correcciones
| 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 las filas como diagnósticos, no como etapas. Un solo hilo al 100% mientras los demás están inactivos es el resultado más común en una puerta de enlace que transporta un túnel grande, porque el cifrado de ese flujo se ejecuta en un núcleo. Todos los núcleos ocupados durante la transferencia significa que la máquina ya hace todo el trabajo que puede. Una CPU baja con retransmisiones crecientes significa que el procesador espera una red que no deja de perder datos.
Corríjalos en ese orden de evidencia. Repartir flujos entre trabajadores ayuda al primer caso y no hace nada por el segundo. Una instancia más grande ayuda al segundo y desperdicia dinero en el primero. Una corrección de MTU o de pérdida es la única que toca el tercero. Comprar capacidad antes de saber en qué fila está es la versión cara de adivinar.
Separe un hilo fijado de un servidor ocupado
Empiece por la utilización por núcleo, para que un núcleo fijado no pueda esconderse dentro de un promedio. Una sola ejecución durante la transferencia muestra si la carga es plana o con picos. Ambas formas son informativas, y un perfil con picos a menudo significa que la ventana de muestreo captó actividad del planificador en lugar del cifrado.
mpstat -P ALL 1 5Atribuya el núcleo ocupado a un proceso y luego a un hilo. La ejecución de seguimiento de abajo mantiene juntos los hilos padre e hijo, lo que importa cuando el demonio bifurca por conexión:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10La criptografía del núcleo nunca aparece en un contador de proceso de espacio de usuario. Muestree los hilos por separado y compare esa vista con la contabilidad del proceso:
top -H -b -n 1 | head -20Lea los contadores de sockets al final, porque deciden si más CPU ayudaría siquiera. Retransmisiones que suben con la CPU plana no es un problema del procesador. Mantenga la transferencia en marcha mientras muestrea, o los números describirán una máquina inactiva:
ss -ti | grep -E 'retrans|cwnd|rtt'Una transferencia controlada, ejecutada dos veces
Los contadores inactivos no prueban nada, y una prueba contra un extremo aleatorio prueba muy poco. Elija un cliente, un destino y una transferencia representativa que tenga permitido ejecutar, y luego capture el caudal y la latencia interactiva en la misma ventana. Una puerta de enlace puede saturarse mientras una copia masiva aún termina, y la curva de latencia es lo que los usuarios sienten de verdad. Escriba la transferencia, el número de clientes y la versión del demonio junto a los números.
Repita la ejecución con varios flujos en paralelo. Escalar hacia arriba con los flujos sugiere ventanas por flujo; quedarse plano con un núcleo fijado sugiere procesamiento.
Luego repita una vez más con las cargas opcionales detenidas. Una copia de seguridad, un remitente de registros o una base de datos en el mismo servidor pueden producir un promedio ocupado que nada tiene que ver con los túneles. Si la CPU sigue fijada con el servidor por lo demás tranquilo, la evidencia apunta al proceso VPN. Si baja, estaba midiendo al vecino, y la puerta de enlace nunca fue el problema.
Descarte la ruta antes de comprar hardware
Las retransmisiones crecientes, una ventana de congestión que se encoge y un tiempo de ida y vuelta creciente apuntan lejos del procesador. Compare el MTU del túnel con el MTU de la ruta, revise el enlace subyacente en busca de pérdidas y confirme que el enlace ascendente del cliente no es el límite. Una puerta de enlace más grande no repara un enlace que pierde paquetes, y los usuarios describen ambas fallas con las mismas palabras. El contador de retransmisiones las separa en minutos.
En un servidor virtual, añada las métricas del proveedor a las del invitado. El tiempo robado es cómo la sobreventa se hace visible dentro del invitado, y ningún ajuste dentro del invitado lo elimina. Los contadores del invitado no ven el host, así que un gráfico limpio del invitado no es prueba de un host sano.
Un cambio, una medición
Elija la hipótesis que respalda la evidencia y luego cambie exactamente un ajuste admitido: número de trabajadores, una opción de descarga documentada o el tamaño de la instancia. OpenVPN publica una guía de solución de problemas de rendimiento sobre la misma división entre procesamiento y transporte: Solución de problemas de rendimiento de OpenVPN.
Confirme que la opción de descarga está realmente activa en lugar de confiar en el indicador, luego repita la transferencia idéntica y compare lo comparable. Es la única forma de distinguir una mejora real de una tarde tranquila. Conserve un punto de control que pueda restaurar, porque en el segundo cambio la gente pierde la pista de cuál ayudó. Una variable por ejecución es lenta durante un día y rápida durante un mes.
No debilite la autenticación ni el conjunto de cifrados para que el gráfico se vea mejor. Si la CPU sigue sin seguir el síntoma, vuelva a las comprobaciones de ruta y aplicación en lugar de actualizar a ciegas.