Cómo detectar problemas de rendimiento en Docker

Introducción

Detectar problemas de rendimiento en Docker consiste en localizar qué recurso o dependencia está limitando realmente a una aplicación antes de intentar optimizarla. Una respuesta lenta puede deberse a CPU saturada, falta de memoria, espera de disco, latencia de red, límites demasiado bajos, una base de datos bloqueada o incluso a un problema que no está dentro del contenedor.

El error más habitual es empezar por una suposición: “Docker consume mucha CPU”, “falta RAM” o “el disco es lento”. Sin medidas comparables, es fácil invertir tiempo en el componente equivocado. La metodología correcta parte del síntoma, reproduce el problema, observa host y contenedor, identifica el recurso que se aproxima a su límite y solo después formula una hipótesis.

Docker añade una capa de aislamiento y facilita medir cada servicio, pero no cambia las bases del diagnóstico de sistemas. Los contenedores comparten el kernel y los recursos físicos del host. Por eso una aplicación puede parecer limitada dentro de Docker cuando el cuello de botella está en el servidor, o puede afectar al resto de la plataforma porque consume un recurso compartido.

Este artículo se centra en el diagnóstico práctico de CPU, memoria, disco, I/O y red, además de límites de recursos, procesos internos, logs y dependencias. La supervisión cotidiana de estados, reinicios y healthchecks se trata de forma separada en cómo monitorizar contenedores Docker de forma sencilla. Aquí la pregunta es distinta: cuando ya sabemos que existe una degradación, ¿cómo averiguamos por qué?

Índice

• Diagnosticar antes de optimizar
• Definir el síntoma con precisión
• Comparar con una línea base
• Separar host, contenedor y aplicación
• Obtener una primera fotografía con Docker
• Diagnosticar problemas de CPU
• Diagnosticar problemas de memoria
• Reconocer cierres por falta de memoria
• Distinguir capacidad y rendimiento de disco
• Analizar espera e I/O
• Revisar volúmenes y bind mounts
• Diagnosticar problemas de red
• No olvidar DNS y resolución de nombres
• Comprobar límites de CPU y memoria
• Mirar dentro del contenedor
• Correlacionar métricas y logs
• Buscar dependencias lentas
• Comparar contenedores y momentos
• Reproducir la carga de forma controlada
• Relacionar el problema con cambios recientes
• Detectar competencia entre contenedores
• Errores frecuentes de diagnóstico
• Procedimiento paso a paso
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Diagnosticar antes de optimizar

El diagnóstico de rendimiento debe responder a una secuencia sencilla:

1. definir qué comportamiento es anormal;
2. reproducirlo o identificar cuándo ocurre;
3. medir los recursos relevantes;
4. localizar el primer límite observable;
5. formular una hipótesis;
6. cambiar una sola variable;
7. repetir la prueba;
8. comparar el resultado.

Este orden evita la optimización por intuición. Añadir memoria a un servicio limitado por disco no resolverá el problema. Asignar más CPU a una aplicación que espera continuamente una base de datos tampoco.

El cuello de botella es el recurso o dependencia que impide que el sistema mejore aunque otros recursos todavía tengan margen.

El artículo cómo planificar el crecimiento de una infraestructura Docker desarrolla cómo dimensionar una plataforma a largo plazo. Aquí utilizamos las mismas dimensiones —CPU, memoria, almacenamiento y red— pero con un objetivo distinto: explicar una degradación concreta.

Definir el síntoma con precisión

“Docker va lento” no es un síntoma suficientemente preciso. Antes de medir conviene describir exactamente qué ocurre.

Por ejemplo:

• una petición web tarda 8 segundos en lugar de 500 milisegundos;
• un proceso nocturno tarda el doble que la semana anterior;
• un contenedor consume CPU al 100 % durante horas;
• una aplicación empieza rápida y se degrada después de varias horas;
• el servicio se bloquea cuando concurren varios usuarios;
• las escrituras en una base de datos se han vuelto lentas;
• el problema solo aparece al copiar archivos grandes;
• varios contenedores se ralentizan simultáneamente.

Registrar cuándo ocurre

La hora y el contexto pueden revelar patrones. Un problema que aparece cada noche puede coincidir con backups, rotaciones de logs, análisis, tareas programadas o procesos de mantenimiento.

Separar latencia y capacidad

Una aplicación puede ser lenta incluso con pocos usuarios, lo que apunta a latencia. Otra puede responder bien con poca carga y degradarse al aumentar concurrencia, lo que apunta a un límite de capacidad.

Comparar con una línea base

Las métricas aisladas son difíciles de interpretar. Una CPU al 70 % puede ser normal para un servicio y anormal para otro.

La línea base describe el comportamiento habitual:

• consumo normal de CPU;
• memoria habitual;
• tiempo de respuesta;
• tráfico de red;
• volumen de operaciones de disco;
• duración de tareas periódicas;
• cantidad de usuarios o peticiones.

Si no existe histórico, puede crearse una referencia midiendo el sistema durante un periodo estable.

Una desviación respecto a la línea base aporta más información que una cifra absoluta. Pasar de 200 MB a 900 MB de memoria sin cambio conocido merece más atención que un servicio que siempre utiliza 900 MB y se mantiene estable.

Separar host, contenedor y aplicación

El rendimiento puede degradarse en tres niveles distintos.

Host

El servidor puede quedarse sin CPU, memoria, I/O o ancho de banda. Si el host está saturado, varios contenedores pueden verse afectados.

Contenedor

Un contenedor puede tener límites de CPU o memoria, demasiados procesos, una configuración inadecuada o un volumen lento.

Aplicación

El proceso interno puede ejecutar consultas ineficientes, bloquearse, consumir memoria progresivamente o esperar una dependencia externa.

El objetivo del diagnóstico es saber en qué capa aparece primero la limitación.

Obtener una primera fotografía con Docker

Una primera revisión puede hacerse con:

docker stats --no-stream

Este comando ofrece una fotografía rápida de CPU, memoria, tráfico de red y operaciones de bloques.

También conviene revisar estado y reinicios:

docker ps
docker ps -a

Y consultar los logs recientes del servicio afectado:

docker logs --since 30m --tail 200 nombre_contenedor

Qué buscamos en esta primera fase

• un contenedor claramente distinto del resto;
• CPU constantemente alta;
• memoria próxima al límite;
• reinicios;
• tráfico inusual;
• actividad de bloques muy elevada;
• errores coincidentes con la degradación.

Esta fotografía no suele resolver el problema, pero ayuda a elegir la siguiente dirección.

Diagnosticar problemas de CPU

Un uso elevado de CPU no es automáticamente malo. Si una tarea intensiva utiliza todos los recursos disponibles y termina antes, puede ser un comportamiento eficiente.

La CPU se convierte en sospechosa cuando:

• permanece saturada durante la degradación;
• el tiempo de respuesta empeora al aumentar concurrencia;
• otros contenedores pierden rendimiento al mismo tiempo;
• existe throttling por límites;
• un proceso consume CPU sin producir trabajo útil.

Comparar contenedor y host

docker stats permite observar el contenedor, pero también conviene mirar el host con herramientas como:

top
htop
uptime

Si un contenedor consume mucha CPU pero el host tiene varios núcleos libres, el problema puede estar en que la aplicación no paraleliza bien. Si todos los núcleos están ocupados, existe competencia global.

Mirar procesos internos

Docker permite ver los procesos:

docker top nombre_contenedor

También puede ejecutarse una herramienta dentro del contenedor si la imagen la incluye:

docker exec -it nombre_contenedor top

No confundir CPU con espera

Una aplicación lenta puede mostrar poca CPU porque está esperando disco, red o una base de datos. Un consumo bajo no significa que el sistema tenga rendimiento suficiente.

Diagnosticar problemas de memoria

La memoria requiere observar tanto cantidad utilizada como comportamiento a lo largo del tiempo.

Con docker stats puede verse la memoria atribuida al contenedor y su relación con el límite configurado.

Señales de problema

• memoria que crece continuamente;
• uso próximo al límite del contenedor;
• swap elevada en el host;
• reinicios asociados a presión de memoria;
• latencia creciente cuando el host empieza a intercambiar memoria;
• varios servicios compitiendo por RAM.

Caché no equivale necesariamente a fuga

Muchas aplicaciones utilizan memoria libre como caché. El crecimiento de memoria debe interpretarse junto con la capacidad para liberarla, el comportamiento del host y la estabilidad a largo plazo.

Mirar el host

free -h

Es importante conocer la memoria disponible del sistema completo. Un contenedor puede estar dentro de su límite y, aun así, participar en una presión global de memoria.

Buscar patrón temporal

Si la memoria aumenta después de cada operación y nunca vuelve a bajar, puede existir un problema. Si sube durante una tarea y después se estabiliza o libera, puede ser comportamiento normal.

Reconocer cierres por falta de memoria

Cuando el sistema no dispone de memoria suficiente, el kernel puede terminar procesos mediante el OOM killer.

Docker permite comprobar información del estado:

docker inspect nombre_contenedor

Dentro de la salida puede revisarse si el contenedor fue finalizado por falta de memoria.

También conviene consultar mensajes del host:

dmesg
journalctl -k

No resolver automáticamente aumentando el límite

Si el contenedor supera su memoria, aumentar el límite puede ser correcto si el dimensionamiento era insuficiente. Pero también puede ocultar una fuga o una configuración incorrecta.

Primero conviene responder:

• ¿la carga ha aumentado?
• ¿la memoria crece sin estabilizarse?
• ¿la aplicación cambió recientemente?
• ¿el límite era razonable?
• ¿otros contenedores están presionando al host?

Distinguir capacidad y rendimiento de disco

Un disco puede tener mucho espacio libre y, aun así, ser el cuello de botella. La capacidad responde a “cuántos datos caben”; el rendimiento responde a “con qué rapidez pueden leerse o escribirse”.

Conviene comprobar primero capacidad:

df -h
docker system df

Después, si el síntoma apunta a almacenamiento, hay que observar actividad de I/O en el host.

Herramientas habituales de Linux pueden mostrar utilización, espera y latencia de dispositivos, por ejemplo:

iostat -xz 1

La disponibilidad exacta depende de las herramientas instaladas en el sistema.

Señales compatibles con disco lento

• CPU relativamente baja mientras la aplicación responde despacio;
• tiempos altos en operaciones que leen o escriben muchos datos;
• varios contenedores afectados durante backups o copias;
• bases de datos lentas al escribir;
• picos coincidentes con rotación o compresión de logs;
• latencia elevada del dispositivo.

Analizar espera e I/O

La espera de entrada/salida puede hacer que una aplicación parezca “sin CPU” y, sin embargo, esté completamente limitada.

Observar el host

Herramientas como vmstat ayudan a observar actividad general:

vmstat 1

Y iostat permite profundizar en dispositivos.

Relacionar con Docker

docker stats muestra BLOCK I/O, que permite comparar actividad entre contenedores. No es una medida completa de latencia, pero puede indicar qué servicio genera más tráfico hacia almacenamiento.

Buscar competencia

Un backup, una importación o una compresión pueden competir con una base de datos aunque pertenezcan a contenedores diferentes. Todos terminan usando el mismo dispositivo físico.

Por eso es importante conocer la estructura de almacenamiento y no asumir que el aislamiento de contenedores equivale a aislamiento físico.

Revisar volúmenes y bind mounts

El rendimiento puede variar mucho según dónde estén realmente los datos.

Una aplicación puede utilizar:

• named volumes locales;
• bind mounts sobre el host;
• almacenamiento en red;
• un NAS;
• un disco dedicado;
• almacenamiento virtualizado;
• un sistema remoto.

Dos contenedores idénticos pueden rendir de forma muy diferente si sus datos viven en almacenamientos distintos.

Comprobar ubicación

Puede utilizarse:

docker inspect nombre_contenedor

para revisar montajes y volúmenes asociados.

Evitar conclusiones por el nombre del volumen

El nombre lógico no indica el rendimiento físico. Hay que conocer qué dispositivo o sistema de almacenamiento hay debajo.

La organización y persistencia se desarrolla en cómo gestionar correctamente los volúmenes Docker.

Diagnosticar problemas de red

La red se convierte en sospechosa cuando la degradación aparece al comunicar servicios, transferir archivos o acceder a dependencias externas.

Conviene separar varios tramos:

• aplicación dentro del contenedor;
• red Docker interna;
• host;
• red local;
• Internet o red externa;
• servicio remoto.

Probar desde distintos puntos

Una misma petición puede probarse desde el host y desde el contenedor:

curl -w '%{time_total}\n' -o /dev/null -s https://ejemplo.com

Si desde el host es rápida y desde el contenedor lenta, el ámbito de búsqueda se reduce.

Revisar tráfico

docker stats permite comparar NET I/O entre contenedores. Un tráfico elevado puede ser legítimo, pero ayuda a localizar quién utiliza la red.

No olvidar el servicio remoto

Una API externa lenta puede hacer que la aplicación Docker parezca lenta aunque el host tenga recursos libres.

No olvidar DNS y resolución de nombres

Algunas degradaciones aparentemente aleatorias proceden de resolución de nombres lenta o fallida.

En Docker, los servicios pueden comunicarse mediante nombres dentro de redes definidas. También pueden depender de DNS externos.

Si una conexión tarda varios segundos antes de empezar, conviene comprobar si el tiempo se pierde en resolución de nombres.

Pruebas útiles pueden incluir:

getent hosts nombre-servicio
getent hosts dominio-ejemplo.com

La herramienta disponible depende de la imagen. Las imágenes mínimas pueden no incluir utilidades de diagnóstico habituales.

Comprobar límites de CPU y memoria

Un contenedor puede estar limitado aunque el host tenga recursos libres.

Docker permite configurar restricciones de CPU y memoria. Esas restricciones son útiles para impedir que un servicio monopolice el servidor, pero un límite demasiado bajo puede convertirse en el cuello de botella.

Revisar configuración

Puede utilizarse docker inspect para revisar la configuración efectiva del contenedor.

CPU limitada

Una aplicación puede necesitar más tiempo de CPU del permitido. El host mostrará margen, pero el contenedor no podrá utilizarlo.

Memoria limitada

Si el servicio se aproxima continuamente a su límite, puede sufrir presión, reinicios o cierres.

No eliminar límites como primera reacción

Los límites tienen una función de aislamiento. Antes de quitarlos conviene determinar si estaban mal dimensionados o si la aplicación ha cambiado de comportamiento.

Mirar dentro del contenedor

Cuando Docker indica que un contenedor consume recursos, el siguiente paso es averiguar qué proceso interno los utiliza.

docker top nombre_contenedor

Si la imagen dispone de herramientas:

docker exec -it nombre_contenedor sh

Desde ahí pueden revisarse procesos, archivos, conexiones o configuraciones.

Imágenes mínimas

Muchas imágenes de producción incluyen pocas utilidades. Eso es positivo desde el punto de vista de superficie y tamaño, pero dificulta el diagnóstico.

No conviene instalar herramientas permanentemente dentro de un contenedor solo para investigar. Puede ser preferible utilizar utilidades del host, un contenedor temporal de diagnóstico o reproducir el problema en un entorno de prueba.

No modificar producción durante la observación

El diagnóstico debe alterar lo mínimo posible el sistema que se está midiendo.

Correlacionar métricas y logs

Las métricas muestran qué recurso cambia. Los logs pueden explicar qué estaba haciendo la aplicación en ese momento.

Conviene correlacionar:

• hora de pico de CPU;
• hora de crecimiento de memoria;
• latencia de disco;
• errores de red;
• reinicios;
• peticiones lentas;
• tareas programadas.

Por ejemplo, si a las 02:00 aumenta I/O y los logs muestran el inicio de una copia o una compactación, existe una relación que merece probarse.

Para revisar un periodo:

docker logs --since "2026-08-08T02:00:00" --until "2026-08-08T02:15:00" nombre_contenedor

Las fechas del ejemplo deben sustituirse por las del incidente real.

Buscar dependencias lentas

Un contenedor puede tener CPU y memoria libres y seguir siendo lento porque espera a otro componente.

Dependencias frecuentes:

• base de datos;
• caché;
• API externa;
• DNS;
• almacenamiento remoto;
• servicio de correo;
• proxy;
• otro microservicio.

Medir cada salto

Si es posible, mide el tiempo de respuesta de cada dependencia desde el contenedor que la consume.

Una dependencia compartida puede afectar a varios servicios

Si distintas aplicaciones se degradan simultáneamente, busca primero recursos comunes: base de datos, proxy, almacenamiento o red.

La organización de servicios independientes se desarrolla en cómo estructurar un entorno Docker para varios servicios independientes.

Comparar contenedores y momentos

La comparación es una herramienta muy potente.

Contenedor sano frente a contenedor lento

Si dos servicios similares usan imágenes o configuraciones parecidas, compara:

• CPU;
• memoria;
• montajes;
• límites;
• redes;
• variables;
• versión de imagen;
• volumen de carga.

Antes y después

Si el problema comenzó tras una actualización, compara métricas y configuración anteriores con las actuales.

Producción y prueba

Si el mismo despliegue funciona bien en pruebas y mal en producción, las diferencias de datos, carga, almacenamiento, red o límites pueden orientar el diagnóstico.

Reproducir la carga de forma controlada

Cuando sea posible, un problema de rendimiento debe poder reproducirse de forma controlada.

Por ejemplo:

• ejecutar la misma consulta;
• procesar un archivo representativo;
• realizar un número conocido de peticiones;
• ejecutar la misma tarea programada;
• copiar una cantidad definida de datos.

Cambiar una variable cada vez

Si aumentas CPU, cambias la base de datos y mueves el volumen simultáneamente, no sabrás qué modificación resolvió el problema.

Usar entornos de prueba cuando exista riesgo

Las pruebas intensivas pueden afectar producción. Cuando sea posible, reproduce la carga en un entorno separado con datos representativos.

Relacionar el problema con cambios recientes

Muchos problemas de rendimiento aparecen después de un cambio.

Conviene revisar:

• nueva versión de imagen;
• cambio de variables;
• migración de base de datos;
• nuevo volumen;
• cambio de almacenamiento;
• nueva red;
• nuevo proxy;
• cambio de límites;
• incorporación de otro contenedor;
• aumento de tráfico;
• nueva tarea programada.

Una buena trazabilidad reduce muchísimo el tiempo de diagnóstico. El artículo cómo documentar una infraestructura basada en Docker desarrolla cómo conservar ese contexto operativo.

Detectar competencia entre contenedores

Los contenedores aíslan procesos, pero siguen compartiendo recursos físicos.

Un servicio puede perjudicar a otro mediante:

• CPU;
• memoria;
• I/O;
• ancho de banda;
• almacenamiento;
• servicios compartidos.

Comparar antes y durante la degradación

docker stats permite observar si otro contenedor aumenta su consumo al mismo tiempo que el servicio afectado se degrada.

Tareas intensivas

Backups, compresiones, importaciones, generación de informes y análisis pueden consumir recursos durante periodos concretos.

Aplicar límites con criterio

Los límites pueden evitar que una carga secundaria monopolice el host. Pero deben dimensionarse con datos para no crear nuevos cuellos de botella.

Errores frecuentes de diagnóstico

Optimizar antes de medir

Introduce cambios sin saber si atacan el recurso limitante.

Mirar solo docker stats

Es una excelente primera fotografía, pero no sustituye las métricas del host ni el análisis de la aplicación.

Suponer que CPU alta es siempre el problema

Puede ser consecuencia de trabajo legítimo, mientras el verdadero problema está en otro punto.

Interpretar memoria usada como fuga

Cachés y buffers pueden crecer de forma normal. Hay que observar tendencia y capacidad de recuperación.

Confundir espacio libre con disco rápido

Un disco al 30 % de ocupación puede estar saturado de I/O.

No mirar dependencias externas

Una API, DNS o almacenamiento remoto lento puede dominar el tiempo total.

Eliminar límites sin investigar

Puede esconder el síntoma y permitir que un contenedor afecte al resto.

Probar muchos cambios simultáneamente

Impide atribuir el resultado a una causa concreta.

No registrar el momento del problema

Sin hora exacta resulta difícil correlacionar logs, métricas y tareas.

Diagnosticar solo dentro del contenedor

El host, almacenamiento y red física siguen siendo parte del sistema.

Procedimiento paso a paso

1. Define el síntoma. Especifica qué operación es lenta, cuánto tarda y desde cuándo.
2. Identifica cuándo ocurre. Busca horario, carga, usuarios o tareas coincidentes.
3. Obtén una fotografía. Usa docker stats --no-stream, estado y logs.
4. Comprueba el host. Revisa CPU, memoria, disco y carga general.
5. Busca el recurso más próximo al límite. CPU, memoria, I/O o red.
6. Revisa límites del contenedor. El host puede tener margen y el servicio no.
7. Observa procesos internos. Localiza qué proceso genera el consumo.
8. Revisa dependencias. Mide base de datos, DNS, red y servicios externos.
9. Correlaciona logs y métricas. Utiliza la misma ventana temporal.
10. Compara con una referencia. Antes/después, sano/lento o prueba/producción.
11. Formula una hipótesis. Debe explicar el síntoma y las medidas observadas.
12. Cambia una sola variable. Evita modificaciones múltiples.
13. Repite la prueba. Utiliza una carga comparable.
14. Documenta el resultado. Conserva causa, cambio y efecto.

Lista de comprobación

Preguntas frecuentes

Conclusión

Detectar problemas de rendimiento en Docker exige mirar más allá del estado del contenedor. CPU, memoria, disco, I/O y red forman parte de un sistema compartido con el host y con otros servicios.

El método más fiable consiste en definir el síntoma, obtener una línea base, comparar host y contenedor, identificar el primer recurso limitante y correlacionar métricas con logs y dependencias. Herramientas como docker stats, docker inspect, docker top y docker logs aportan una primera visión muy útil, pero deben complementarse con herramientas del sistema anfitrión cuando el problema lo exige.

El objetivo no es encontrar una métrica alta, sino demostrar qué componente está limitando el trabajo. Esa diferencia evita optimizaciones inútiles y permite aplicar cambios pequeños, medibles y reversibles.

Una plataforma bien diagnosticada no necesita estar sobredimensionada. Necesita conocer su comportamiento normal, sus límites y las relaciones entre servicios. Esa capacidad convierte los problemas de rendimiento en incidentes analizables en lugar de pruebas por ensayo y error.