Cómo evaluar el margen de recursos de Home Assistant con una carga de trabajo repetible
Un benchmark de rendimiento de Home Assistant solo es útil cuando reproduce la misma carga de trabajo y define qué significa «lo suficientemente rápido» antes de consultar los gráficos de recursos. De lo contrario, los valores de CPU, memoria, almacenamiento y red se convierten en observaciones sin una conclusión sobre la capacidad.
Esto es distinto de solucionar problemas en una instalación lenta. Un benchmark crea deliberadamente una línea base repetible, aumenta una dimensión de la carga de trabajo e identifica cuánto margen de recursos queda antes de que una automatización, una consulta del historial o la respuesta de un panel salga de su intervalo de latencia aceptable.
Define una carga de trabajo y un umbral de aceptación
Elige una carga de trabajo que represente un pico real del hogar: por ejemplo, una automatización local basada en movimiento, tres paneles activos, escrituras normales del Recorder, un periodo en segundo plano sin copias de seguridad y un conjunto fijo de integraciones. Registra la versión de Home Assistant, el hardware del equipo anfitrión, el almacenamiento, la base de datos, el cliente, la ruta de red y la duración de la prueba.
La vista de información del sistema de Home Assistant muestra información sobre la instalación, la red, las integraciones y los recursos que debe registrarse junto con el resultado de rendimiento. Sin los detalles del entorno, el tiempo de respuesta de una persona no se puede comparar de forma significativa con el de otra máquina.
Después, define el umbral de aceptación. Una automatización de iluminación podría necesitar una respuesta física inferior a un segundo, mientras que una consulta del historial de cinco años podría ser aceptable si tarda varios segundos. No combines ambas en una única puntuación genérica de «velocidad de Home Assistant».
Usa utilización, saturación y errores para cada recurso compartido
La utilización media por sí sola es un criterio deficiente para detenerse. Un disco puede estar ocupado y funcionar correctamente, o una CPU puede mostrar un uso medio moderado mientras los picos breves crean una cola que los usuarios perciben como latencia.
El método USE evalúa la utilización, la saturación y los errores de cada recurso físico o limitado. Aplica este marco a la CPU, la capacidad de memoria, la E/S del almacenamiento y las interfaces de red, en lugar de elegir el gráfico de utilización más alto.
En Home Assistant dentro de contenedores, incluye también los límites de cgroups como recursos. Un equipo anfitrión con un 60 % de CPU libre aún puede limitar un contenedor que haya alcanzado la cuota que tiene asignada.
Las métricas de presión muestran el tiempo perdido por la escasez de recursos
Pressure Stall Information de Linux añade una perspectiva orientada a la latencia. En lugar de preguntar únicamente cuánta CPU, memoria o E/S se utiliza, PSI mide la fracción de tiempo durante la que las tareas quedan bloqueadas porque un recurso está en contención.
La documentación del kernel de Linux explica que la presión de CPU, memoria y E/S se puede medir como tiempo real perdido por la contención, incluidos los picos breves que perjudican la latencia antes de que la utilización media parezca extrema.
Por eso PSI resulta útil en un servidor doméstico compartido. Si la latencia de Home Assistant empeora cuando aumenta la presión de E/S durante una ráfaga de escrituras de otro contenedor, tendrás pruebas más sólidas de contención en el almacenamiento compartido que con la afirmación «el SSD estaba ocupado al 70 %».
Aumenta solo una dimensión de la carga de trabajo en cada ejecución
No añadas simultáneamente usuarios de paneles, activadores de automatizaciones, transmisiones de cámaras, retención y tráfico de copias de seguridad. Aumenta una variable mientras todas las demás condiciones permanecen fijas.
Entre las pruebas escalonadas útiles se incluyen más eventos de automatización por minuto, más paneles simultáneos, intervalos de historial más amplios, más actualizaciones de entidades o una carga definida de un servicio vecino. Después de cada paso, espera el tiempo suficiente para que el sistema alcance un comportamiento estable, en lugar de recopilar solo los primeros diez segundos de una caché calentándose o de un pico de inicio.
El análisis de ZimaSpace sobre la contención de las colas de almacenamiento compartido y la latencia de cola muestra por qué la carga de trabajo debe asociarse con la ruta del recurso: el almacenamiento solo importa cuando la acción probada depende directamente de él o comparte la misma cola de E/S.
Cambia un recurso y exige que el resultado varíe
Un benchmark se vuelve diagnóstico cuando un cambio controlado en un recurso modifica la curva de latencia. Fija un servicio vecino pesado para que no use la CPU de Home Assistant, pausa un trabajo con muchas escrituras, aumenta el límite de memoria del cgroup probado, utiliza una ruta LAN directa o mueve los datos de la aplicación a un almacenamiento de menor latencia.
Si el umbral de latencia original mejora en el mismo paso de carga de trabajo, es razonable pensar que el recurso estaba limitando el margen disponible. Si nada cambia, revierte el experimento y prueba el siguiente candidato en lugar de convertir el cambio en una configuración permanente.
Publica el resultado como un límite de capacidad
| Dimensión de la carga de trabajo | Medir con | Detenerse cuando |
|---|---|---|
| Frecuencia de automatizaciones/eventos | Latencia de cola entre el activador y la acción | La latencia o las colas crecen de forma persistente |
| Clientes de paneles | Respuesta del servidor + renderizado del cliente | El retraso repetido en las interacciones supera el objetivo |
| Carga del Recorder/historial | Latencia de las consultas + presión del almacenamiento | La presión de E/S o la cola de latencia de las consultas se desvía bruscamente |
| Carga del equipo anfitrión compartido | PSI / cgroup / utilización | La latencia de Home Assistant cambia con la contención |
| Ruta de red | RTT, pérdida, DNS, tiempo de respuesta | La ruta remota incumple el objetivo definido |
El resultado final debería expresarse así: «este hardware, esta base de datos, esta combinación de clientes y esta carga de trabajo en segundo plano mantienen la ruta de control elegida dentro del objetivo hasta el paso N». Esa afirmación es reproducible. «Home Assistant solo usa un 20 % de CPU» no lo es.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Pueden las cámaras domésticas sincronizar eventos sin servicios de hora en la nube?
Una explicación centrada en el mecanismo del tiempo de la cámara sin nube, sus compensaciones por recursos compartidos, tres preguntas frecuentes sobre la propagación...
¿Puede un servicio de IA local detectar capas de modelo dañadas antes de la inferencia?
Una explicación basada primero en los mecanismos de la detección de capas de modelo dañadas, sus compensaciones en recursos compartidos, tres preguntas frecuentes sobre...
¿Se puede restaurar un sistema RAG sin regenerar cada embedding?
Una explicación centrada primero en el mecanismo de la restauración de RAG sin volver a generar embeddings, sus compromisos en el uso compartido de...
