Quelle marge de puissance CPU devriez-vous réserver pour les pics de charge de Home Assistant ?
Réservez suffisamment de marge CPU pour la charge de travail répétable la plus exigeante afin de respecter les objectifs de délai entre l’événement et l’action, ainsi que de redémarrage ; aucun pourcentage universellement défendable ne convient à toutes les configurations Home Assistant.
Un hôte à quatre cœurs peut afficher une moyenne modeste alors qu’un cœur est saturé, ou sembler limité par le CPU alors que l’attente du stockage, la pression mémoire ou la limitation thermique constitue la véritable limite. Définissez le chevauchement réaliste le plus chargé, mesurez la latence de contrôle et le comportement de chaque cœur, puis conservez la plus petite marge de ressources qui réussit de façon répétée sans interrompre les services compagnons habituels.
Définir le pic et la limite perceptible par l’utilisateur
Créez une charge de travail qui combine le pic normal d’automatisations le plus intense avec l’utilisation du tableau de bord et les tâches d’arrière-plan planifiées, telles que la sauvegarde, la maintenance de la base de données, la voix ou certains traitements de caméra. Définissez la latence acceptable entre l’événement et l’action, le temps de réponse du tableau de bord et l’état de préparation après redémarrage avant de mesurer l’utilisation.
N’utilisez pas un test de charge artificiel sollicitant tous les cœurs comme seul pic de référence. Il mesure la capacité matérielle, mais pas le chevauchement entre la planification, la base de données, les intégrations et les modules complémentaires auquel les utilisateurs sont réellement confrontés.
Une référence valide exécute trois fois le même nombre d’appareils, les mêmes intégrations, le même état de la base de données et les mêmes services voisins. Si la charge de travail ne peut pas être reproduite, aucun pourcentage qui en est dérivé ne constitue une réserve fiable.
Effectuez une mesure pendant une période calme à titre de contrôle. La différence entre les états calme et de pointe révèle la sensibilité à la charge de travail ; le seul pourcentage de pointe ne permet pas de déterminer si le système était déjà proche de la saturation.
Lire séparément la saturation de chaque cœur et l’attente
Enregistrez l’utilisation de chaque cœur, la charge, le temps volé pour les machines virtuelles, l’attente d’E/S, la fréquence, la température et le processus Home Assistant, parallèlement à la latence perceptible par l’utilisateur. Alignez toutes les mesures sur les mêmes horodatages.
Parce qu’un cœur saturé peut se dissimuler derrière une moyenne globale du système bien plus faible, analysez le profil du processus au lieu de supposer que l’utilisation totale représente la marge réellement disponible.
Si un cœur atteint sa capacité maximale tandis que la latence augmente, la capacité monocœur du CPU ou une tâche bloquante est probablement en cause. Si l’attente d’E/S augmente en premier, corrigez le comportement du stockage ou de la base de données. Si la fréquence diminue avec la température, corrigez le refroidissement avant de réserver davantage de capacité nominale.
Créer de la marge avec la planification et l’isolation
Déplacez les tâches facultatives hors de la période de contrôle la plus chargée, limitez les conteneurs compagnons bruyants et empêchez les tâches de caméra, d’IA ou multimédias de consommer tous les cœurs disponibles. Veillez à ce que Home Assistant et les courtiers essentiels puissent continuer à fonctionner pendant ces pics.
Ne comparez la marge processeur déterminée par la charge de travail qu’après avoir mesuré le facteur limitant du système actuel. Acheter un processeur plus rapide ne corrige ni les tâches sans limites ni l’attente du stockage.
Effectuez un nouveau test après chaque modification de planification ou de limite. Si la latence respecte les objectifs sans changement matériel, la marge récupérée constitue une marge opérationnelle ; si le même cœur reste saturé, ne comparez un CPU plus puissant qu’avec une charge de travail identique.
Déterminer la réserve à partir de réussites répétées
Utilisez le pic observé le plus élevé lors de plusieurs exécutions propres et répétées, puis conservez une capacité supplémentaire pour la croissance attendue des intégrations et le chevauchement avec une opération de maintenance. Exprimez le résultat sous la forme d’une enveloppe de service testée, et non d’un objectif universel d’inactivité.
La procédure du test de marge de ressources fournit une référence multicritère pour le CPU, la mémoire, le stockage et le réseau.
Considérez le test comme réussi lorsque le pic initial respecte les objectifs de latence et de redémarrage lors d’exécutions consécutives, sans limitation thermique ni arrêt forcé des services. Envisagez une montée en gamme ou une mise à niveau lorsque la même saturation spécifique au CPU persiste après avoir écarté les causes liées à la planification, aux intégrations et aux E/S.
Produits recommandés
Assistance et conseils
Plus à lire
Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés
N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot...
Comment empêcher les tâches ou importations en double dans Immich
Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez...
Comment réparer Immich après le remplissage de son volume de base de données
Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez...
