Cómo saber si Home Assistant está limitado por la CPU, la RAM, el almacenamiento o la red
Solo puedes identificar un cuello de botella en Home Assistant después de reproducir un síntoma estable. Un gráfico de CPU alto, poca RAM libre, un disco ocupado o un contador de red elevado no bastan por sí solos; el recurso limitante es aquel cuya presión cambia al mismo tiempo que la automatización, el panel, la consulta del historial o la integración se vuelve lenta.
Primero, fija las condiciones de prueba. Usa la misma automatización, dispositivo, panel, intervalo del historial y carga en segundo plano cada vez. Después, observa la CPU, la memoria, el almacenamiento y la red por separado, y cambia una sola restricción sospechosa cada vez.
Define el síntoma antes de consultar los gráficos de recursos
«Home Assistant va lento» puede significar una acción física retrasada, un panel que tarda varios segundos en mostrarse, un historial que carga lentamente, una integración que se vuelve a conectar tarde o un host que se bloquea durante una copia de seguridad. Cada síntoma utiliza una ruta de datos diferente.
Elige un evento repetible y registra su hora. Para una luz activada por movimiento, registra la llegada del disparador y la respuesta física. Para el historial, mide desde el inicio de la consulta hasta el primer resultado. Para un panel, separa la respuesta del servidor del renderizado del navegador. Para una integración no disponible, registra la accesibilidad de la red y los registros de la integración.
No recopiles una docena de gráficos sin relación y busques el pico más alto. La prueba debe indicarte en qué etapa del sistema se estaba esperando cuando apareció el retraso visible para el usuario.
La CPU es el límite cuando el trabajo se acumula detrás del procesamiento
La CPU es una candidata clara cuando Home Assistant o un proceso relacionado consume capacidad de procesamiento de forma sostenida mientras el síntoma empeora, y la misma carga mejora cuando se elimina o aísla esa demanda de procesamiento.
El método de utilización, saturación y errores resulta útil porque distingue un recurso que simplemente está ocupado de uno en el que el trabajo se está acumulando. En Home Assistant, un pico breve de CPU es menos importante que una saturación repetible que coincida con automatizaciones retrasadas o actividad de la base de datos.
Comprueba qué proceso o contenedor está causando la carga. Una tarea de cámara, el mantenimiento de la base de datos, un contenedor de IA local o un servicio complementario pueden saturar el host mientras el propio Home Assistant sigue consumiendo pocos recursos.
La RAM es el límite cuando el conjunto de trabajo genera presión
Linux utiliza la memoria que de otro modo estaría inactiva para la caché, por lo que tener poca memoria «libre» no es automáticamente un problema. Observa la memoria disponible, el intercambio, la presión, los límites de cgroup y los eventos OOM.
La explicación de la caché del sistema de archivos de Linux se puede reclamar es importante al analizar un host de Home Assistant: una máquina puede mostrar la mayor parte de la RAM como utilizada y aun así disponer de un margen saludable.
La memoria se convierte en el límite probable cuando la misma carga normal reduce repetidamente la memoria disponible, provoca intercambio o bloqueos durante la recuperación de memoria, alcanza el límite de un contenedor o genera terminaciones por OOM. Añade RAM o reduce el conjunto de trabajo activo solo después de observar ese patrón.
El almacenamiento es el límite cuando la latencia cambia con el trabajo del Recorder o las copias de seguridad
La presión del almacenamiento puede ocultarse tras un uso bajo de la CPU. Las escrituras del Recorder, las consultas de la base de datos, las reorganizaciones, las copias de seguridad, las actualizaciones y otros contenedores pueden ponerse en cola en el mismo dispositivo mientras los núcleos de la CPU permanecen casi inactivos.
Una advertencia de acumulación de tareas del Recorder de Home Assistant se ha asociado explícitamente con sistemas limitados por la CPU, limitados por la E/S o afectados por un problema de base de datos o almacenamiento. Por eso, el error debe impulsar una correlación y no un reemplazo ciego de la base de datos.
Observa la latencia del disco, la espera de E/S, la profundidad de la cola y el horario de las tareas del Recorder o de las copias de seguridad. El almacenamiento es el diagnóstico más sólido cuando el síntoma sigue esas medidas y desaparece al eliminar la E/S que compite por el dispositivo.
La red es el límite cuando el servidor está listo, pero la ruta no
Un cuello de botella de red puede deberse al rendimiento, la pérdida de paquetes, el retraso del DNS, la inestabilidad de la Wi-Fi, las políticas del cortafuegos o la dependencia de un servicio remoto. Home Assistant puede tener la CPU inactiva y un almacenamiento local rápido mientras una integración o un cliente esperan a la red.
Prueba el servidor localmente y, después, prueba el dispositivo o cliente afectado desde la misma LAN. Si las solicitudes locales son rápidas, pero una VLAN, un segmento Wi-Fi, un nombre DNS o una integración basada en la nube funciona lentamente, concentra la solución en esa ruta.
El uso de la red por sí solo no basta. Una interfaz poco cargada puede seguir fallando por problemas de resolución, enrutamiento o pérdida de paquetes, mientras que una interfaz ocupada puede mantenerse estable si tiene margen suficiente y pocas pérdidas.
Cambia una sola variable y exige que el síntoma cambie
| Recurso | Pruebas que refuerzan el diagnóstico | Prueba de cambio útil |
|---|---|---|
| CPU | Saturación o acumulación sostenida durante el síntoma | Pausar el proceso pesado o aislar la carga de trabajo |
| RAM | Presión, intercambio, OOM o límite de cgroup | Reducir los servicios activos o aumentar el límite probado |
| Almacenamiento | La latencia o la espera de E/S siguen al Recorder o a la copia de seguridad | Pausar la E/S que compite o mover el estado a un almacenamiento más rápido |
| Red | Solo la ruta remota o hacia el dispositivo funciona lentamente | Usar una ruta local directa o una ruta de red alternativa |
El análisis de ZimaSpace sobre la latencia del almacenamiento en las rutas de control de Home Assistant es un buen ejemplo del método: un componente se convierte en el cuello de botella solo cuando su temporización coincide con el retraso de control real.
Detente cuando un cambio controlado mejore de forma fiable el síntoma original. Esto aporta pruebas más sólidas que cualquier porcentaje de utilización aislado y evita que una actualización costosa solucione la capa equivocada.
Productos recomendados
Soporte y Consejos
Más para leer
¿Deberías hacer una copia de seguridad de Home Assistant en ejecución o detener primero el servicio?
Las copias de seguridad integradas de Home Assistant pueden ejecutarse en vivo; las copias simples del sistema de archivos deben detener o poner en...
¿Por qué un servidor de Home Assistant se calienta o hace ruido durante las horas de inactividad?
Correlaciona los picos de ventilación o temperatura de Home Assistant con Recorder, las copias de seguridad, las integraciones y las tareas alojadas conjuntamente antes...
¿Cuándo deberías reconstruir Home Assistant en lugar de repararlo?
Repara primero la capa más pequeña de Home Assistant que haya fallado, restaura después un estado conocido y funcional, y reconstruye solo cuando no...
