Optimisez les connexions à la base de données de Home Assistant en répartissant le budget total entre tous les conteneurs, plutôt qu’en maximisant un seul pool. Gardez une marge pour l’administration de la base de données et les tâches en arrière-plan, puis validez Recorder pendant un démarrage simultané et la période normale d’écriture la plus chargée.
Sur un hôte MariaDB ou PostgreSQL partagé, le nombre important correspond à la somme des connexions possibles de chaque service, multipliée par le nombre d’instances en cours d’exécution, à laquelle s’ajoutent l’accès de maintenance et l’accès d’urgence. Mesurez ensemble les connexions actives, inactives, en attente et ayant échoué, ainsi que la latence des requêtes et la charge du stockage. Si vous utilisez SQLite, arrêtez-vous ici : déplacer davantage de conteneurs vers le même fichier de base de données ne constitue pas un réglage du pool de connexions.
Confirmez la topologie de la base de données et la demande actuelle en connexions
Documentez le moteur et la version de la base de données, l’URL de Recorder de Home Assistant, tous les autres conteneurs clients, le nombre de réplicas, le pool configuré, les délais d’expiration, le comportement en cas de nouvelle tentative et la stratégie de redémarrage. Vérifiez que chaque service possède son propre utilisateur de base de données afin d’attribuer correctement les sessions actives.
Mesurez le nombre maximal de connexions de la base de données, les sessions actuelles par utilisateur et par état, le pic de sessions pendant le démarrage et en charge normale, les attentes, la latence des requêtes, l’utilisation du processeur, la mémoire et la latence du stockage. Un nombre élevé de connexions peut être le symptôme d’un traitement lent plutôt que sa cause ; ajouter des sessions à un disque saturé augmente généralement la contention.
Consultez le guide ZimaSpace sur la fiabilité d’une base de données externe pour Home Assistant afin de vérifier les sauvegardes, les autorisations de schéma, la prise en charge du moteur et les limites liées aux mises à niveau avant de régler la concurrence.
Établissez un budget de connexions pour tous les conteneurs
Réservez des connexions pour l’administration de la base de données, la surveillance, les migrations, les sauvegardes et les tâches internes du moteur. Répartissez le budget applicatif restant entre les services selon le travail concurrent mesuré, et non selon la quantité de RAM installée ou une valeur de connexions maximales copiée.
Les recommandations relatives aux pools de connexions pour les services multinstances rendent le calcul essentiel explicite : la base de données doit prendre en charge la taille du pool multipliée par le nombre d’instances. Le concept s’applique largement, mais chaque version de Home Assistant et de la base de données nécessite ses propres paramètres pris en charge.
Commencez avec des pools et des files d’attente plafonnés. Si la demande dépasse brièvement la capacité du pool, attendre peut être plus sûr que d’ouvrir un nombre illimité de sessions ; si le temps d’attente devient perceptible pour l’utilisateur, examinez la latence des requêtes et du stockage avant d’agrandir le pool. Conservez des délais d’expiration explicites pour les connexions et leur acquisition afin que les échecs soient signalés au lieu de provoquer une attente indéfinie.
Contrôlez les redémarrages, les nouvelles tentatives et les connexions inactives
Échelonnez le démarrage des conteneurs afin que Home Assistant, les tableaux de bord, les outils d’analyse, les sauvegardes et les importateurs ne se reconnectent pas et n’effectuent pas tous leurs migrations en même temps. Utilisez des vérifications d’état qui testent la disponibilité réelle de la base de données, mais évitez les boucles de nouvelles tentatives trop rapprochées, qui créent une tempête de connexions pendant la récupération de la base de données.
Définissez la durée de vie des connexions inactives et leur recyclage uniquement en tenant compte des délais d’expiration de la base de données, du pilote, du proxy et du réseau. Un pool qui conserve trop longtemps des sessions mortes provoque des erreurs ; un pool qui renouvelle les connexions de manière trop agressive ajoute une surcharge d’authentification et de configuration. Modifiez une seule couche de délai d’expiration à la fois.
Si vous introduisez un proxy de connexions, vérifiez la sémantique des transactions, les migrations, les instructions préparées et la compatibilité avec Home Assistant dans un environnement de test. Un proxy ne remplace pas l’analyse des requêtes lentes, des verrous, de la mémoire ou du stockage.
Réduisez le travail de la base de données avant d’augmenter la concurrence
Examinez la durée de conservation de Recorder, les entités à haute fréquence exclues, le comportement de purge, la taille de la base de données et les requêtes lentes. Si une requête de Home Assistant conserve une connexion pendant longtemps, réduire les données inutiles ou corriger la latence du stockage peut améliorer le débit plus sûrement qu’ajouter des sessions.
Ne séparez les outils d’analyse lourds ou les métriques à long terme de Recorder que lorsque le nouveau pipeline dispose d’un modèle clair de propriété et de conservation. Ne dirigez pas des conteneurs sans lien vers le schéma de Home Assistant et ne les laissez pas écrire dans les tables de Recorder ; utilisez les API prises en charge ou des bases de données indépendantes.
Vérifiez de nouveau la mémoire par connexion, la configuration des tampons, les attentes de verrous et la latence du stockage avant d’augmenter la limite du serveur de base de données. Le serveur doit rester réactif au pic planifié, avec une capacité suffisante pour la récupération et l’administration.
Validez pendant un démarrage concurrent et une charge Recorder maximale
Redémarrez la base de données et les conteneurs clients dans l’ordre prévu, puis répétez l’opération avec le chevauchement sûr le plus chargé : démarrage de Home Assistant, requêtes d’historique, importations, sauvegardes et pic d’un autre service. Surveillez le nombre de connexions, le temps d’attente lors de l’acquisition, les échecs, la latence des requêtes, les verrous et les entrées-sorties de l’hôte.
Une configuration validée conserve une interface de contrôle et un historique Home Assistant réactifs, reste dans les limites du budget de connexions, préserve l’accès administrateur et vide les files d’attente temporaires après le pic. Redémarrez deux fois et observez la prochaine fenêtre de maintenance planifiée pour confirmer la persistance.
Rétablissez la configuration précédente si les délais d’expiration, les erreurs de connexions trop nombreuses, la pression sur la mémoire de la base de données ou le retard de Recorder s’aggravent. Fournissez la topologie, le nombre de sessions par utilisateur, les paramètres des pools, les éléments probants concernant les requêtes lentes et les métriques de stockage plutôt qu’un simple nombre maximal de connexions.
Assistance et conseils
Plus à lire

Comment éviter les tâches ou importations en double dans Home Assistant
Utilisez des traces et des clés d’opération uniques pour rendre les automatisations et les importations réessayables en toute sécurité, sans générer d’actions ni d’enregistrements...

Comment réparer Home Assistant lorsque le volume de sa base de données est plein
Récupérer d’un volume Recorder plein sans supprimer d’abord les preuves, puis réduire la croissance et prouver que l’historique et les automatisations survivent au redémarrage.

Pourquoi Home Assistant recrée-t-il les fichiers manquants avec le mauvais propriétaire ?
Faites correspondre les UID et GID d’exécution avec ceux du chemin hôte, réparez uniquement les fichiers concernés lorsque le service est arrêté, puis vérifiez...

