Pourquoi Home Assistant génère-t-il des charges différentes lors des lectures et des écritures ?

Home Assistant génère des charges de lecture et d’écriture différentes, car les requêtes réutilisent des pages mises en cache, tandis que la persistance de l’état modifie les journaux, les index et le stockage durable.

L’ouverture d’un graphique d’historique peut analyser de nombreuses lignes stockées sans les modifier, tandis qu’un seul capteur très bavard peut créer de petites transactions tout au long de la journée. Le premier scénario favorise les lectures séquentielles, le cache de la base de données et les index de requête ; le second ajoute la synchronisation, les mises à jour du journal, les métadonnées du système de fichiers et l’amplification des écritures sur mémoire flash. Les graphiques diffèrent donc même lorsque les deux opérations utilisent la même base de données Recorder.

Les changements d’état en temps réel génèrent plus d’une écriture

Recorder convertit certaines modifications d’état et d’événements en transactions de base de données. L’insertion d’une ligne logique peut également mettre à jour les index et un journal ou un journal d’écriture anticipée avant que le système de fichiers et le cache du périphérique ne confirment l’écriture durable.

Un article explicatif sur les bases de données et les statistiques distingue le stockage de l’état à court terme des statistiques à long terme, ce qui clarifie pourquoi les structures de données de Recorder peuvent toucher plusieurs structures associées plutôt qu’un seul fichier en ajout.

Les entités à haute fréquence créent de nombreuses petites modifications logiques qui peuvent être validées par groupes. Cela peut apparaître sous forme de rafales périodiques ; le nombre d’octets écrits physiquement peut dépasser la charge utile, car les couches de la base de données et du stockage préservent la cohérence.

Les lectures de l’historique dépendent de la plage, de la sélectivité et du cache

Une recherche de l’état actuel est limitée, mais un graphique d’historique couvrant plusieurs entités peut analyser une grande plage temporelle, décoder les attributs, agréger les résultats et les envoyer au client. Des index utiles et des pages de base de données déjà en cache peuvent éviter que bon nombre de ces opérations n’accèdent au stockage physique.

Un cas de performances étudié sur une longue période a révélé un accès à l’historique extrêmement lent malgré une utilisation en temps réel ordinaire, montrant que la charge des requêtes d’historique peut révéler un problème sur le chemin des requêtes que le contrôle de l’état actuel ne sollicite pas.

Les lectures répétées deviennent souvent plus rapides lorsque les pages pertinentes restent en mémoire. Cet avantage disparaît après un redémarrage, sous la pression mémoire ou avec une autre plage de dates ; une seule requête effectuée sur des données déjà en cache ne constitue donc pas une mesure fiable de la capacité de stockage.

Le coût des écritures augmente avec la journalisation et les services voisins

Home Assistant Core n’est pas le seul processus à écrire sur un serveur domestique classique. Les journaux de débogage, les bases de données des modules complémentaires, les sauvegardes, les instantanés des caméras et les journaux des conteneurs peuvent partager le même périphérique et provoquer une mise en file d’attente précisément lorsque Recorder tente de valider ses données.

Les utilisateurs qui cherchent à réduire l’usure de la mémoire flash ont observé que les journaux et les composants associés ajoutent des cycles d’écriture. C’est pourquoi l’activité d’écriture sur l’ensemble du volume doit prendre en compte tout le volume, et pas seulement le processus principal de la base de données.

L’attribution au niveau des processus permet de distinguer le comportement de l’application de la contention du stockage partagé. Si Recorder est inactif tandis qu’un autre conteneur effectue les écritures, modifier les exclusions d’entités ne résoudra pas la charge observée.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

La maintenance peut inverser le schéma habituel

La suppression des lignes expirées, la reconstruction des index, la récupération d’espace ou le compactage peuvent lire et réécrire de grandes parties d’une base de données. Pendant cette période, une tâche décrite comme un nettoyage peut générer à la fois davantage de lectures et davantage d’écritures que l’ingestion normale des états.

Les discussions sur la configuration de Recorder associent la durée de conservation et le comportement de purge à la maintenance de la base de données. Le comportement de conservation et de purge est donc essentiel lorsqu’un pic de charge régulier apparaît chaque jour à la même heure.

L’explication fondée sur les lectures et les écritures ne s’applique plus lorsque le goulot d’étranglement se situe dans l’évaluation des modèles côté processeur, le rendu côté client ou la transmission réseau. Les compteurs de stockage doivent augmenter en même temps que le symptôme ; sinon, la base de données n’est qu’un élément adjacent au ralentissement.

Comparez un chemin de lecture et un chemin d’écriture

Choisissez une requête d’historique fixe et une action sans risque qui modifie l’état. Pour chacune, relevez la latence de la requête, l’utilisation du processeur, le temps passé dans la base de données, le débit du disque, les IOPS, la profondeur de file d’attente et la latence du périphérique lors d’un démarrage à froid, puis lors d’une exécution répétée avec les données en cache.

L’article associé sur la croissance des données conservées explique pourquoi l’augmentation des métadonnées et de l’historique modifie la charge de travail, en ancrant la comparaison dans les données conservées plutôt que dans un trafic de test arbitraire.

Classez la limite en fonction de la covariance : une première lecture lente suivie d’une répétition rapide suggère une bonne localité du cache ; un temps de requête qui augmente avec la plage suggère un coût d’analyse ; un retard d’écriture accompagné d’une profondeur de file d’attente élevée suggère une contention du stockage durable ; l’absence de ces deux schémas suggère une autre couche. N’optimisez que le chemin qui reproduit deux fois le ralentissement visible par l’utilisateur.