Cosa limita effettivamente le attività simultanee di Home Assistant prima che il controllo locale inizi a peggiorare?
Home Assistant non ha una risposta univoca alla domanda «quante attività simultanee è in grado di gestire?». Dieci brevi attività asincrone possono essere meno onerose di una sola integrazione che blocca il ciclo degli eventi, mentre cinquanta automazioni in coda possono rimanere innocue se trascorrono la maggior parte del tempo in attesa di operazioni I/O indipendenti.
Il limite utile è il punto in cui il lavoro aggiuntivo crea un ritardo ripetibile nel percorso di controllo più importante: un evento impiega più tempo per essere elaborato, la coda di un’automazione cresce, una chiamata al servizio non rispetta più i tempi previsti oppure una risorsa condivisa di CPU, memoria, archiviazione o rete entra in sofferenza. La concorrenza è quindi prima di tutto un problema di latenza e code, non di numero di attività.
La concorrenza di Home Assistant inizia dal ciclo degli eventi asyncio
Home Assistant Core è basato su Python asyncio. I componenti pianificano il lavoro come attività e il codice asincrono cooperativo cede il controllo mentre attende l’I/O, consentendo alle altre attività di avanzare invece di dedicare un thread del sistema operativo a ogni integrazione.
La documentazione attuale per gli sviluppatori di Home Assistant spiega che Core pianifica le attività dei componenti tramite un ciclo degli eventi centrale e si basa sulla sospensione corretta delle attività durante l’attesa. Per questo «simultaneo» non significa che ogni attività esegua istruzioni della CPU nello stesso istante.
Un’analisi pratica della concorrenza fa la stessa distinzione: le attività asincrone possono sovrapporsi nel tempo trascorso, mentre l’esecuzione effettiva nel ciclo degli eventi rimane serializzata tra i punti di attesa. La capacità dipende dal tempo per cui ogni attività occupa il ciclo e da ciò che sta aspettando.
Il lavoro bloccante può degradare molte attività contemporaneamente
Il problema di concorrenza più dannoso spesso non è «troppe automazioni», ma un’unica operazione che blocca il ciclo degli eventi abbastanza a lungo da impedire l’esecuzione di aggiornamenti di stato e callback non correlati.
Home Assistant avverte esplicitamente che le operazioni bloccanti nel ciclo degli eventi arrestano l’intero sistema per tutta la durata della chiamata. Questo include operazioni I/O sui file gestite male, librerie di rete, pause o elaborazioni sincrone pesanti all’interno di un’integrazione.
Questo cambia il modo in cui interpretare un test di capacità. Se la latenza del controllo locale aumenta quando una specifica integrazione è attiva, anche se l’utilizzo complessivo della CPU rimane basso, il problema può comunque essere un blocco del ciclo degli eventi anziché una capacità di elaborazione insufficiente.
La modalità dell’automazione determina come i trigger ripetuti diventano lavoro
Le automazioni aggiungono un ulteriore livello di gestione della concorrenza. Una regola può rifiutare un secondo trigger, riavviare l’esecuzione corrente, mettere il lavoro in coda oppure creare esecuzioni parallele. Queste scelte modificano sia il comportamento corretto sia il consumo di risorse.
La documentazione attuale sulle modalità delle automazioni di Home Assistant definisce le modalità single, restart, queued e parallel, con un numero massimo configurabile di esecuzioni in coda o parallele. Il valore massimo predefinito per le modalità in coda e parallela è 10, ma questo valore di configurazione non rappresenta una capacità della piattaforma nel suo complesso.
Un’automazione per un sensore della porta che attende due secondi prima di inviare una notifica e un’automazione per l’illuminazione che effettua cinque chiamate di rete non sono attività equivalenti. Imposta la modalità dell’automazione partendo dall’ordine e dalla correttezza, quindi osserva se la coda o la sovrapposizione risultante influisce sulla latenza del controllo.
Misura la crescita delle code e la latenza di coda, non solo la percentuale di CPU
Usa un’automazione locale critica come sonda della latenza. Registra l’arrivo del trigger, l’avvio dell’automazione, la chiamata al servizio e la risposta del dispositivo fisico aumentando una sola variabile di concorrenza alla volta: trigger ripetuti, client della dashboard, integrazioni in background o servizi adiacenti.
L’articolo di ZimaSpace sul lavoro basato sugli eventi e il carico inattivo del server offre il punto di riferimento corretto: i sistemi basati sugli eventi sono efficienti quando il lavoro si attiva solo quando serve, ma anche i picchi richiedono margine sufficiente di pianificazione e risorse per essere smaltiti senza code persistenti.
Osserva la latenza mediana e le esecuzioni normali più lente. Un sistema può avere una CPU media al 10%, ma creare arresti di un secondo durante brevi picchi. Il limite utile di capacità appare quando le code continuano a crescere, gli avvisi sul numero massimo di esecuzioni compaiono ripetutamente oppure la latenza di coda non torna ai valori di base dopo la fine del picco.
Distingui la concorrenza di Home Assistant dalla contesa sul sistema host
Home Assistant può pianificare correttamente le attività mentre un altro container satura CPU, memoria, archiviazione o rete. In questo caso, aumentare o ridurre max dell’automazione potrebbe non cambiare il problema, perché l’host condiviso ha già esaurito il proprio margine di risorse.
Ripeti il test di concorrenza dopo aver messo in pausa il carico adiacente. Se i tempi del ciclo degli eventi e la latenza del controllo locale si ripristinano immediatamente, considera il limite un problema di capacità dell’host condiviso. In caso contrario, analizza le operazioni bloccanti, il comportamento dell’integrazione o la progettazione della coda dell’automazione all’interno di Home Assistant.
Usa una condizione di arresto invece di pubblicare un numero di attività
| Segnale osservato | Significato | Test successivo |
|---|---|---|
| Le esecuzioni parallele o in coda raggiungono il limite configurato | Limite della coda a livello di automazione | Controlla la modalità, l’ordine e la frequenza dei trigger |
| Avviso sul ciclo degli eventi o ampio rallentamento dell’interfaccia e del controllo | Possibile lavoro bloccante | Individua l’integrazione o la chiamata sincrona |
| La latenza aumenta solo quando è attivo un altro servizio | Contesa sull’host condiviso | Misura la pressione su CPU, memoria, I/O e rete |
| Un singolo percorso del dispositivo è lento mentre gli altri rimangono veloci | Limite specifico della dipendenza | Analizza il percorso dell’integrazione o della rete interessato |
| Le code si svuotano e la latenza di coda rimane nell’intervallo previsto | Rimane un margine utile di concorrenza | Smetti di aggiungere carico al picco pianificato |
La capacità di Home Assistant dovrebbe quindi essere espressa come un carico di lavoro testato con un obiettivo di latenza, non come un numero universale di attività simultanee. La domanda corretta è quanto lavoro sovrapposto possano assorbire l’attuale insieme di integrazioni e l’host prima che il percorso critico del controllo locale smetta di rispettare la propria scadenza.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Stato di runtime vs stato persistente in Home Assistant: cosa deve sopravvivere al riavvio?
Home Assistant non conserva ogni valore in tempo reale; la configurazione, i registri, gli stati selezionati ripristinati, la cronologia e i dati di distribuzione...
Come autentica Home Assistant le sessioni locali e remote?
Le sessioni Home Assistant locali e remote utilizzano lo stesso modello di identità lato server; l'accesso remoto modifica il percorso e il confine TLS,...
Perché le query della cronologia di Home Assistant possono rallentare man mano che crescono i dati del Recorder?
La crescita del registratore può aumentare il costo delle query della cronologia quando l’intervallo richiesto coinvolge più righe, aumentano i cache miss o le...
