¿Qué límite de memoria deberías establecer para Home Assistant?

No existe un único límite de memoria correcto para Home Assistant. Establece el límite a partir de tu pico máximo medido, deja RAM utilizable para el host y los demás contenedores, y considera cualquier terminación por falta de memoria (OOM) como una señal de que el límite o la carga de trabajo requieren investigación.

En un servidor doméstico compartido, una lectura en reposo no es suficiente: las tareas de Recorder, las copias de seguridad, las recargas de integraciones, los paneles y una secuencia intensa de automatizaciones de toda la casa pueden producir picos diferentes. El enfoque seguro es registrar una línea base, elegir un límite reversible por encima del pico de carga verificado, confirmar que el host aún tiene margen y repetir la prueba durante el periodo de mayor actividad original antes de hacer permanente la configuración.

Empieza por el uso máximo, no por una cifra genérica de RAM

Mide el contenedor de Home Assistant y el host al mismo tiempo durante varios días normales. Incluye un reinicio, una copia de seguridad, una purga o reorganización de la base de datos si utilizas alguna, actividad en los paneles y el periodo de automatizaciones más intenso que puedas reproducir de forma segura. Registra el pico del contenedor, la memoria disponible del host, la actividad de intercambio y cualquier cambio en el tiempo de respuesta.

Un límite de memoria es un límite de cgroup, no un objetivo de rendimiento. Cuando un contenedor supera un límite estricto, el kernel puede terminar un proceso; un código de salida 137 junto con un estado de terminación por OOM es la señal útil. Por eso, el uso máximo observado importa más que un promedio o una recomendación copiada.

Si la memoria aumenta durante una tarea y después se estabiliza, dimensiona el límite para ese pico reproducible más un margen de trabajo. Si la memoria anónima aumenta durante horas y no vuelve a bajar cuando termina la carga, deja de ajustar el límite e investiga una integración con fugas, un componente personalizado o una regresión de versión. Un límite superior puede retrasar el fallo sin corregirlo.

Reserva memoria para el host y todos los servicios alojados conjuntamente

Haz una lista de los servicios que deben seguir respondiendo cuando Home Assistant esté más ocupado: el sistema operativo, Docker, una base de datos, MQTT, DNS, los paneles, los servicios multimedia y las tareas de copia de seguridad. El límite debe proteger tanto esos servicios como Home Assistant; asignar a un contenedor casi toda la RAM instalada simplemente traslada el fallo al host.

Compara el pico de Home Assistant con la memoria disponible del host durante el mismo periodo. La caché que puede recuperarse no equivale a la memoria de las aplicaciones, y la actividad de intercambio puede hacer que el sistema parezca estar funcionando mientras el control de dispositivos se vuelve lento. Si el host pierde margen antes de que Home Assistant alcance su pico, reduce las tareas simultáneas o mueve un servicio antes de ajustar a la baja el límite de Home Assistant.

Esta es una decisión de capacidad, no solo una configuración de Docker. La guía relacionada de ZimaSpace sobre medir Home Assistant más allá de la caché activa explica por qué una carga de trabajo en frío y ocupada, pero reproducible, ofrece una línea base más fiable que una cómoda instantánea en reposo.

Aplica un límite reversible y comprueba que se haga cumplir

Añade la configuración de memoria en el archivo de configuración que realmente recrea el contenedor, como tu archivo de Compose o la interfaz de orquestación. Evita depender de una actualización temporal en ejecución si la siguiente implementación la va a descartar. Guarda la configuración anterior para poder restaurarla de inmediato.

Después de recrearlo, inspecciona el contenedor en ejecución y confirma que el límite configurado sea visible. Luego supervisa el uso del contenedor, la memoria disponible del host, el intercambio, el número de reinicios y la latencia. Una configuración visible que el cgroup del host no haga cumplir genera una falsa sensación de seguridad, especialmente en la virtualización anidada.

Si el contenedor se reinicia, no aumentes automáticamente el límite. Comprueba si el entorno de ejecución informa de un estado OOMKilled y del código de salida 137. Si no es así, investiga otra causa de apagado. Si lo es, compara la marca de tiempo con la carga de trabajo: un pico corto y reproducible sugiere que falta margen de trabajo, mientras que un crecimiento constante sugiere una fuga o una integración descontrolada.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Repite la prueba con la carga de trabajo intensa original de Home Assistant

Repite exactamente el escenario utilizado para la línea base: recarga las mismas integraciones, abre los mismos paneles, ejecuta la misma secuencia de control de toda la casa e incluye la misma actividad de copias de seguridad o Recorder. Cambiar la carga de trabajo solo demostraría que un sistema más ligero cabe dentro del límite.

Un resultado satisfactorio significa que el contenedor se mantiene por debajo del límite sin eventos OOM, que el host conserva memoria utilizable, que el intercambio no provoca retrasos en el control y que las automatizaciones terminan a su velocidad habitual. Reinicia dos veces y vuelve a comprobarlo después de la siguiente tarea en segundo plano programada para asegurarte de que el resultado resiste la recreación y las tareas dependientes del tiempo.

Revierte el nuevo límite si el control de dispositivos deja de ser fiable, el contenedor entra en un bucle de reinicios o la presión sobre el host sigue siendo grave. Pasa a aislar integraciones o comparar versiones cuando la memoria siga aumentando después de terminar la carga que la desencadenó; en ese punto, ajustar el límite ya no es la solución principal.

Preguntas frecuentes

¿Home Assistant debería tener siempre un límite estricto de memoria? En un host de Docker compartido, un límite probado puede proteger los demás servicios. Una máquina o VM dedicada con HAOS se dimensiona de otra manera, así que no copies un límite de contenedor en la asignación de una VM sin medir todo el sistema invitado.

¿Un uso elevado de memoria significa automáticamente que hay una fuga? No. La caché y los picos breves de carga pueden ser normales. Busca memoria anónima que siga creciendo, eventos OOM, bucles de reinicio o una latencia cada vez mayor después de que termine la carga.

¿Deberías desactivar el intercambio? No como primera medida. Primero averigua si el intercambio está ocultando la presión sobre el host o evitando un fallo abrupto; después, cámbialo solo con un procedimiento de reversión probado y suficiente RAM física para toda la carga de trabajo.