Quelle limite de mémoire devriez-vous définir pour Home Assistant ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Il n’existe pas de limite mémoire unique et correcte pour Home Assistant. Définissez cette limite à partir de votre pic d’utilisation mesuré, laissez suffisamment de RAM disponible pour l’hôte et les autres conteneurs, et considérez tout arrêt par manque de mémoire comme un signe que la limite ou la charge doit être examinée.

Sur un serveur domestique partagé, une mesure au repos ne suffit pas : les tâches de Recorder, les sauvegardes, le rechargement des intégrations, les tableaux de bord et une séquence d’automatisation intensive dans toute la maison peuvent produire des pics différents. La méthode sûre consiste à enregistrer une référence, à choisir une limite réversible supérieure au pic de charge vérifié, à confirmer que l’hôte dispose encore d’une marge suffisante, puis à retester la période chargée d’origine avant de rendre ce réglage permanent.

Commencez par l’utilisation maximale, pas par un nombre générique de RAM

Mesurez simultanément le conteneur Home Assistant et l’hôte pendant plusieurs jours ordinaires. Incluez un redémarrage, une sauvegarde, une purge ou un compactage de la base de données si vous en utilisez un, une activité sur les tableaux de bord et la période d’automatisation la plus chargée que vous pouvez reproduire sans risque. Notez le pic du conteneur, la mémoire disponible sur l’hôte, l’activité du swap et toute variation du temps de réponse.

Une limite mémoire est une frontière cgroup, pas un objectif de performances. Lorsqu’un conteneur dépasse une limite stricte, le noyau peut terminer un processus ; un code de sortie 137 associé à l’état OOM-killed constitue le signal caractéristique. C’est pourquoi l’utilisation maximale observée compte davantage qu’une moyenne ou qu’une recommandation copiée.

Si la mémoire augmente pendant une tâche puis se stabilise, dimensionnez la limite en fonction de ce pic reproductible, avec une marge de fonctionnement. Si la mémoire anonyme augmente pendant des heures sans redescendre après la fin de la charge, cessez d’augmenter la limite et recherchez une fuite dans une intégration, un composant personnalisé ou une régression de version. Un plafond plus élevé peut retarder le plantage sans le corriger.

Réservez de la mémoire pour l’hôte et chaque service hébergé conjointement

Listez les services qui doivent rester réactifs lorsque Home Assistant est le plus sollicité : le système d’exploitation, Docker, une base de données, MQTT, le DNS, les tableaux de bord, les services multimédias et les tâches de sauvegarde. La limite doit protéger ces services ainsi que Home Assistant ; attribuer à un conteneur presque toute la RAM installée ne fait que déplacer la panne vers l’hôte.

Comparez le pic de Home Assistant à la mémoire disponible sur l’hôte pendant la même période. Le cache récupérable n’est pas équivalent à la mémoire utilisée par les applications, et l’activité du swap peut donner l’impression qu’un système fonctionne encore alors que le contrôle des appareils devient lent. Si l’hôte manque de marge avant que Home Assistant n’atteigne son pic, réduisez le chevauchement des tâches ou déplacez un service avant de réduire le plafond de Home Assistant.

Il s’agit d’une décision de capacité, pas seulement d’un réglage Docker. Le guide ZimaSpace associé sur la mesure de Home Assistant au-delà du cache à chaud explique pourquoi une charge à froid et intensive, répétable, fournit une référence plus fiable qu’une simple capture pratique au repos.

Appliquez une limite réversible et vérifiez qu’elle est bien appliquée

Ajoutez le réglage mémoire dans la configuration qui recrée réellement le conteneur, par exemple votre fichier Compose ou votre interface d’orchestration. Évitez de vous fier à une modification temporaire effectuée en direct si le prochain déploiement doit l’annuler. Enregistrez la configuration précédente afin de pouvoir la restaurer immédiatement.

Après la recréation, inspectez le conteneur en cours d’exécution et confirmez que la limite configurée est visible. Surveillez ensuite l’utilisation du conteneur, la mémoire disponible sur l’hôte, le swap, le nombre de redémarrages et la latence. Un réglage affiché mais non appliqué par le cgroup de l’hôte donne une fausse impression de sécurité, notamment en virtualisation imbriquée.

Si le conteneur redémarre, n’augmentez pas automatiquement la limite. Vérifiez si l’environnement d’exécution indique OOMKilled et le code de sortie 137. Dans le cas contraire, recherchez une autre cause d’arrêt. Dans l’affirmative, comparez l’horodatage avec la charge : un pic court et reproductible suggère une marge de fonctionnement insuffisante, tandis qu’une croissance régulière suggère une fuite ou une intégration hors de contrôle.

Retestez avec la charge Home Assistant intensive d’origine

Répétez exactement le scénario utilisé pour établir la référence : rechargez les mêmes intégrations, ouvrez les mêmes tableaux de bord, exécutez la même séquence de contrôle dans toute la maison et incluez la même activité de sauvegarde ou de Recorder. Modifier la charge ne prouverait qu’un système moins sollicité peut fonctionner.

Un résultat concluant signifie que le conteneur reste sous la limite sans événement OOM, que l’hôte conserve une mémoire utilisable, que le swap ne provoque pas de latence dans le contrôle et que les automatisations s’exécutent à leur vitesse habituelle. Redémarrez deux fois et vérifiez à nouveau après la prochaine tâche en arrière-plan planifiée, afin de confirmer que le résultat résiste à la recréation et aux tâches dépendantes du temps.

Restaurez l’ancienne limite si le contrôle des appareils devient peu fiable, si le conteneur entre dans une boucle de redémarrage ou si la pression exercée sur l’hôte reste sévère. Passez à l’isolement des intégrations ou à la comparaison entre versions lorsque la mémoire continue d’augmenter après la fin de la charge déclenchante ; à ce stade, l’ajustement de la limite n’est plus la principale solution.

FAQ

Home Assistant doit-il toujours avoir une limite mémoire stricte ? Sur un hôte Docker partagé, une limite testée peut protéger les autres services. Une machine HAOS dédiée ou une VM se dimensionne différemment ; ne transposez donc pas une limite de conteneur à l’allocation d’une VM sans mesurer l’ensemble du système invité.

Une mémoire utilisée élevée indique-t-elle automatiquement une fuite ? Non. Le cache et les pics de charge momentanés peuvent être normaux. Recherchez plutôt une mémoire anonyme qui continue d’augmenter, des événements OOM, des boucles de redémarrage ou une latence qui s’aggrave après la fin de la charge.

Faut-il désactiver le swap ? Pas en première intention. Déterminez d’abord si le swap masque la pression exercée sur l’hôte ou empêche une panne brutale, puis ne le modifiez qu’avec une procédure de retour testée et suffisamment de RAM physique pour l’ensemble de la charge.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.