Un servidor Linux puede responder lentamente aunque la CPU no esté al 100 %, todavía quede memoria disponible y los discos no parezcan saturados. El origen puede estar en una cola de procesos, la presión sobre la memoria, el almacenamiento, la red, los límites de un contenedor o una aplicación que espera demasiado a una base de datos o a un servicio externo. La clave para encontrarlo es relacionar métricas y observar dónde empieza a aumentar el tiempo de respuesta.
Herramientas como vmstat, iostat, ss y las estadísticas de Pressure Stall Information (PSI) ayudan a investigar el estado del sistema. Pero el diagnóstico no termina en el sistema operativo: medir la latencia de las peticiones permite comprobar si el problema afecta realmente al servicio y separar los síntomas que perciben los usuarios de las causas técnicas.
Las claves para diagnosticar un servidor Linux lento en 20 segundos
- Una CPU ocupada no siempre está saturada: importa si hay tareas esperando para ejecutarse.
- La memoria disponible, el uso de swap y PSI ayudan a detectar presión sobre los recursos.
iostatpermite investigar la latencia del almacenamiento y las colas de operaciones.- Los errores de red y los límites de los contenedores pueden frenar aplicaciones con recursos libres en el host.
- La latencia de las peticiones ayuda a localizar problemas en bases de datos, DNS, API y otros servicios externos.
1. CPU saturada: demasiadas tareas para los núcleos disponibles
La utilización de CPU es uno de los primeros indicadores que se revisan al investigar un servidor lento. Sin embargo, un porcentaje elevado no demuestra por sí solo que exista un cuello de botella. Una máquina puede aprovechar todos sus núcleos y mantener tiempos de respuesta adecuados.
El problema aparece cuando las tareas ejecutables se acumulan y no consiguen tiempo de procesador con la rapidez necesaria. Para observarlo, se puede empezar con:
vmstat 1En la salida, la columna r indica las tareas ejecutándose o esperando tiempo de CPU. Si permanece por encima del número de CPU lógicas disponibles y el procesador apenas tiene tiempo ocioso, existe una señal de posible saturación. Conviene comprobar varias muestras, porque la primera salida puede reflejar promedios acumulados desde el arranque.
También puede ocurrir que un único núcleo esté saturado mientras los demás permanecen poco ocupados. Este patrón aparece en aplicaciones que dependen de un hilo principal o no paralelizan bien determinadas operaciones.
Para examinar el consumo por núcleo y proceso:
mpstat -P ALL 1
pidstat -u 1
topSi predomina el tiempo de CPU consumido por las aplicaciones, habrá que identificar qué proceso o tarea genera la carga. Si aumenta el tiempo de sistema, puede ser necesario revisar las llamadas al kernel, las interrupciones y el trabajo relacionado con la red o el almacenamiento.
2. Presión de memoria: el problema no empieza necesariamente al agotar la RAM
Linux utiliza memoria libre para mantener cachés y acelerar el acceso a los datos. Por eso, una cifra baja en la columna free no significa automáticamente que el servidor tenga poca memoria disponible. El indicador available de free ofrece una estimación más útil.
free -h
vmstat 1En vmstat, las columnas si y so muestran la entrada y salida de páginas mediante el área de intercambio (swap). Una actividad sostenida, combinada con latencia y presión de memoria, puede indicar que el sistema está dedicando demasiado tiempo a recuperar páginas.
Linux también ofrece Pressure Stall Information (PSI), que mide el tiempo durante el que las tareas sufren esperas relacionadas con determinados recursos:
cat /proc/pressure/memory
cat /proc/pressure/cpu
cat /proc/pressure/ioLos resultados permiten observar la presión en ventanas de 10, 60 y 300 segundos. En memoria y entrada y salida, some refleja periodos en los que al menos una tarea se encuentra bloqueada por la presión del recurso. full identifica periodos en los que todas las tareas no inactivas consideradas por la métrica están bloqueadas simultáneamente.
Si el sistema agota la memoria, el kernel puede activar el mecanismo OOM (Out of Memory) y terminar procesos. Los registros ayudan a confirmar si ha ocurrido:
journalctl -k | grep -i -E 'oom|out of memory'Lenguaje del código: JavaScript (javascript)Una memoria residente que crece continuamente puede justificar una investigación de fugas, aunque también puede deberse a un aumento normal de la carga. La evolución temporal es más reveladora que una captura aislada.
3. Almacenamiento: operaciones que se quedan esperando
Las bases de datos, los servidores de ficheros y las aplicaciones que generan muchos registros pueden sufrir degradaciones cuando el almacenamiento no completa las operaciones con suficiente rapidez.
Para investigar el dispositivo:
iostat -xz 1La salida incluye las operaciones de lectura y escritura por segundo, el tiempo medio de espera (await) y la longitud media de la cola (aqu-sz). Una latencia elevada y colas persistentes pueden señalar presión sobre el dispositivo, pero no existe un umbral universal válido para todos los discos y cargas de trabajo.
El siguiente paso consiste en identificar qué procesos generan la actividad:
pidstat -d 1Una copia de seguridad, una tarea de mantenimiento de una base de datos o un uso intensivo de swap pueden explicar un incremento repentino de las operaciones. Comparar estas métricas con vmstat permite comprobar si la presión de almacenamiento coincide con otros síntomas.
4. Red: retransmisiones, paquetes descartados y colas de conexiones
Un servidor puede tener CPU y memoria disponibles mientras las peticiones sufren retrasos por problemas de red. Las causas incluyen pérdida de paquetes, congestión, errores de interfaz o acumulación de conexiones pendientes.
Para empezar, conviene consultar:
ip -s link show
ss -ti
nstat -azLos errores y descartes de la interfaz, junto con un aumento de las retransmisiones TCP, ayudan a identificar problemas de conectividad. Los contadores deben compararse en distintos momentos, ya que sus valores acumulados no demuestran por sí solos que la incidencia siga activa.
También conviene comprobar las colas de los servicios que aceptan conexiones:
ss -ltn
ss -sSi las conexiones pendientes se acumulan, la aplicación podría no estar aceptándolas con suficiente rapidez. En sistemas que utilizan seguimiento de conexiones mediante conntrack, también puede ser necesario revisar el número de entradas activas y el límite configurado.
Si el servidor no muestra problemas internos, la investigación debe extenderse a la ruta de red y al extremo remoto. Una conexión lenta con una base de datos o una API puede manifestarse como una aplicación lenta aunque la máquina de origen funcione correctamente.
5. Límites de procesos y contenedores: recursos que no se pueden utilizar
Disponer de recursos libres en el host no garantiza que todos los procesos puedan utilizarlos. Un servicio puede alcanzar su límite de descriptores de fichero, una cuota de CPU o un límite de memoria impuesto por systemd o por un contenedor.
Para comprobar los límites de descriptores:
ulimit -n
cat /proc/<PID>/limits
systemctl show <servicio> -p LimitNOFILELenguaje del código: HTML, XML (xml)El resultado de ulimit -n corresponde a la sesión actual y no tiene por qué coincidir con el límite efectivo de un servicio en ejecución. El fichero /proc/<PID>/limits permite examinar el proceso concreto.
En sistemas con cgroups v2, los siguientes contadores aportan información sobre las restricciones aplicadas:
cat /sys/fs/cgroup/<ruta>/cpu.stat
cat /sys/fs/cgroup/<ruta>/memory.eventsLenguaje del código: HTML, XML (xml)cpu.stat incluye contadores relacionados con la limitación de tiempo de procesador, mientras que memory.events registra sucesos vinculados a los límites de memoria y a posibles terminaciones por falta de recursos.
Este patrón resulta especialmente útil cuando una aplicación dentro de un contenedor va lenta, pero el host presenta una utilización moderada. Antes de ampliar las cuotas, hay que confirmar qué límite se está alcanzando y si responde a una configuración intencionada.
6. Latencia de aplicación: cuando el problema está en una dependencia
La sexta señal permite investigar una situación que las métricas del sistema operativo no siempre explican: el servidor parece saludable, pero los usuarios siguen esperando demasiado.
Una petición web puede depender de una consulta a una base de datos, una resolución DNS, una llamada a una API externa, una negociación TLS o varios servicios internos. Si cualquiera de estas operaciones tarda más de lo habitual, la respuesta completa puede degradarse aunque la CPU y la memoria no estén saturadas.
Google SRE recomienda observar cuatro señales principales en los servicios: latencia, tráfico, errores y saturación. La latencia mide el tiempo que tarda en completarse una petición; el tráfico representa la demanda; los errores muestran los fallos del servicio y la saturación ayuda a identificar cuándo los recursos se acercan a sus límites. https://sre.google/sre-book/monitoring-distributed-systems/
Para analizar este tipo de incidencia, la aplicación debe registrar cuánto tarda cada petición y, cuando sea posible, cada operación relevante. En un servicio HTTP, las métricas útiles incluyen la duración de las solicitudes, la tasa de errores y el volumen de tráfico. Es recomendable observar también percentiles como el P95 y el P99: muestran cuánto tardan las peticiones más lentas y evitan que una media aparentemente correcta oculte una degradación importante.
Una primera prueba puede hacerse con curl:
curl -sS -o /dev/null \
-w 'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
https://ejemplo.com/Lenguaje del código: JavaScript (javascript)Hay que sustituir https://ejemplo.com/ por la dirección que se desea probar. El comando desglosa varios tiempos de la petición: resolución DNS, conexión, negociación TLS, tiempo hasta el primer byte y duración total. El resultado corresponde a esa prueba concreta; para extraer conclusiones fiables conviene repetirla y comparar con valores habituales.
Si el tiempo hasta el primer byte aumenta, la causa puede estar en el procesamiento de la aplicación o en una dependencia del servidor. Si la resolución DNS tarda más de lo habitual, habrá que investigar el resolvedor y los servidores DNS. Si la conexión o la negociación TLS se ralentizan, conviene revisar la conectividad, los certificados y la configuración del extremo remoto.
Una prueba externa no basta para identificar la causa definitiva. La instrumentación de la aplicación y los registros distribuidos permiten seguir la petición por sus distintas etapas y comprobar dónde se acumula el tiempo de espera.
Una tabla rápida para elegir la siguiente comprobación
| Señal | Primera herramienta | Qué buscar |
|---|---|---|
| CPU saturada | vmstat 1, mpstat -P ALL 1 | Cola de ejecución y núcleos ocupados |
| Presión de memoria | free -h, /proc/pressure/memory | Memoria disponible, intercambio y esperas |
| Almacenamiento lento | iostat -xz 1 | Latencia y colas persistentes |
| Problemas de red | ss -ti, ip -s link | Retransmisiones, errores y descartes |
| Límites de recursos | /proc/<PID>/limits, cgroups | Cuotas y límites alcanzados |
| Latencia de aplicación | curl, métricas y trazas | Tiempo DNS, conexión, procesamiento y dependencias |
Estas seis señales no son diagnósticos independientes. Una fuga de memoria puede provocar intercambio y aumentar la actividad del disco; una cuota de CPU puede elevar la latencia de las peticiones; una base de datos lenta puede hacer que se acumulen conexiones en la aplicación.
El método más fiable consiste en comparar las métricas durante la incidencia con el comportamiento habitual, cambiar una sola variable cada vez y verificar el resultado. La meta no es ejecutar todos los comandos disponibles, sino encontrar pruebas que permitan distinguir entre varias causas posibles.
Preguntas frecuentes
¿Cómo detectar el cuello de botella de un servidor Linux?
Empieza por CPU, memoria y almacenamiento con vmstat, free e iostat. Si esas métricas no explican el problema, revisa la red, los límites de los procesos y la latencia de las peticiones.
¿Qué significa que un servidor tenga CPU libre pero responda lentamente?
Puede estar esperando a que termine una operación de disco, una consulta a una base de datos, una resolución DNS o una llamada a un servicio externo. Las métricas de latencia ayudan a localizar esas esperas.
¿Qué es PSI en Linux?
Es una función del kernel que mide el tiempo durante el que las tareas sufren presión de CPU, memoria o entrada y salida. Sus estadísticas están disponibles en /proc/pressure/ cuando la función está habilitada.
¿Por qué conviene medir P95 y P99?
Porque permiten observar la latencia de las peticiones más lentas, que puede quedar oculta cuando solo se calcula el promedio. Son especialmente útiles en servicios con muchas solicitudes concurrentes.
