Cómo usar IA para diagnosticar un servidor Linux lento

Los cinco sospechosos de un servidor Linux lento

Cuando un servidor Linux va lento, la causa casi siempre está en uno de cinco recursos: CPU, memoria RAM, disco (entrada/salida), red o un proceso concreto que se descontroló. El error más común es comprar más CPU cuando el problema era el disco. Por eso el diagnóstico se hace en orden, empezando por una foto general.

La clave de todo el proceso es no fiarse de una sola captura. Un servidor respira: un pico de un segundo no es lo mismo que una saturación sostenida. Siempre mira varios intervalos antes de concluir.

Paso 1: la foto general con top y uptime

Antes de investigar nada en detalle, mira el estado global con uptime y top. Te dicen en dos segundos si el servidor está saturado y por dónde empezar.

uptime

Devuelve algo como load average: 4.15, 2.30, 1.80. Esos tres números son la carga promedio en el último minuto, cinco y quince minutos. El load average es la cantidad media de procesos que están corriendo o esperando su turno. La regla práctica: compáralo con el número de núcleos (nproc). Una carga de 4 en un VPS de 2 vCPU significa saturación; en uno de 8 vCPU, holgura.

Luego abre top:

top

Fíjate en tres datos de la cabecera:

• %Cpu(s) — id: el porcentaje de CPU ociosa. Si es bajo, la CPU es el cuello de botella.
• %Cpu(s) — wa (iowait): tiempo que la CPU pasa esperando al disco. Si es alto, el problema es el almacenamiento, no el procesador.
• MiB Mem — avail: memoria realmente disponible. Es más fiable que la columna free.

Pulsa P para ordenar procesos por CPU y M por memoria. Con esto ya sabes si seguir por CPU, RAM o disco.

Paso 2: CPU — ¿quién se está comiendo el procesador?

Si la CPU ociosa (id) es baja de forma sostenida, el cuello de botella es el procesador y hay que encontrar el proceso culpable. htop es la herramienta más cómoda para verlo.

htop

htop es una versión visual de top: muestra una barra por núcleo, colorea el uso y permite ordenar y filtrar con el teclado. Si un solo proceso ocupa un núcleo entero de forma constante, ahí está tu sospechoso.

Para medir con más rigor durante un periodo, usa pidstat (del paquete sysstat):

sudo apt install -y sysstat
pidstat -u 1 5

Esto reporta el uso de CPU por proceso, una vez por segundo, cinco veces. A diferencia de una foto de top, promedia el comportamiento y separa el %usr (código de la aplicación) del %system (llamadas al kernel). Un %system alto suele delatar exceso de operaciones de red o disco disfrazadas de carga de CPU.

Distingue dos casos: si muchos procesos suman la carga, el servidor está simplemente ocupado y quizá necesites más recursos; si uno solo se dispara, probablemente hay un bucle, una consulta mal optimizada o un ataque.

Paso 3: RAM — memoria llena no es lo mismo que memoria en uso

Que Linux muestre casi toda la RAM ocupada casi nunca es el problema: Linux usa la memoria libre como caché de disco y la libera cuando una aplicación la necesita. El verdadero síntoma de falta de memoria es el uso de swap.

free -h

Mira dos columnas:

• available: memoria que las aplicaciones pueden pedir ya mismo. Si es sana, no te falta RAM aunque free sea bajo.
• Swap — used: si hay swap en uso y crece, el servidor se quedó sin RAM y está tirando de disco como memoria. Eso es lentísimo.

Para confirmar que el swap está activo ahora mismo, vmstat:

vmstat 1 5

Las columnas si (swap in) y so (swap out) deben estar en 0. Si muestran números constantes, el sistema está paginando a disco de forma continua: esa es una de las causas más brutales de lentitud. La solución es encontrar qué proceso consume la memoria, no añadir swap sin más. Tenemos una guía dedicada a encontrar el consumo de RAM en Linux con IA y otra sobre ver el consumo de CPU y RAM.

Paso 4: disco I/O — el cuello de botella invisible

Cuando la CPU está ociosa pero el servidor va lento, el culpable casi siempre es el disco. Un iowait alto significa que los procesos pasan el tiempo esperando lecturas y escrituras. Lo confirma iostat:

iostat -xz 1

Mira dos valores por cada disco:

• %util: porcentaje de tiempo que el disco estuvo ocupado. Cercano a 100% de forma sostenida es un disco saturado.
• await: milisegundos que tarda cada operación en completarse. En SSD debería ser de pocos milisegundos; decenas o cientos indican un disco al límite o degradado.

Para saber qué proceso genera esa carga de disco, usa iotop:

sudo iotop -o

La opción -o muestra solo los procesos que están leyendo o escribiendo en ese momento. Es el equivalente de top pero para el disco. Un backup mal programado, una base de datos sin índices o logs que crecen sin control aparecen aquí al instante.

Paso 5: red y procesos rebeldes

Si las descargas van lentas o hay timeouts pero CPU, RAM y disco están sanos, revisa la red y las conexiones abiertas. ss reemplaza al viejo netstat y es más rápido.

ss -s
ss -tan | awk '{print $1}' | sort | uniq -c

El primero resume las conexiones totales; el segundo cuenta cuántas hay en cada estado. Miles de conexiones en TIME-WAIT o SYN-RECV pueden indicar un pico de tráfico legítimo o un ataque. Para ver el tráfico por interfaz en tiempo real:

sar -n DEV 1 5

sar (también del paquete sysstat) muestra los KB recibidos y transmitidos por segundo. Así distingues un servidor que está genuinamente saturado de tráfico de uno que solo tiene un proceso mal comportado. Si sospechas de errores en los servicios, cruza estos datos con los registros: aquí ayuda saber detectar errores en los logs de Linux con IA.

Cómo un agente de IA acelera el diagnóstico

Todo el recorrido anterior —foto general, CPU, RAM, disco, red— es exactamente lo que Cortex AI hace por ti en segundos. Cortex AI es el agente de inteligencia artificial incluido sin costo en los VPS de Terranode, en su versión 1.2. Le escribes en español "¿por qué va lento el servidor?" y él se conecta por SSH, lee el estado real —procesos, memoria, carga, espera de disco—, ejecuta los comandos de diagnóstico y te resume la causa en dos frases.

La diferencia con buscar en un foro es que Cortex no te da instrucciones genéricas para que las copies: está dentro de tu máquina y trabaja con datos reales. Compara los dos caminos:

El control sigue siendo tuyo. Cortex se detiene a pedir confirmación antes de cualquier acción con consecuencias, bloquea lo destructivo, deja registro consultable de todo lo que ejecuta y guarda su llave SSH cifrada con AES-256, con cada cliente aislado del resto. Por ahora funciona solo en Linux. Puedes leer más en el artículo sobre Cortex AI, el agente de IA para VPS y en la guía de VPS con inteligencia artificial.

Que la IA lo haga rápido no te exime de entender qué mira: por eso este método sigue valiendo. La IA acelera el diagnóstico; conocer los comandos te deja verificar que la conclusión tiene sentido.