Come valutare il margine di risorse di Home Assistant con un carico di lavoro ripetibile

Un benchmark delle prestazioni di Home Assistant è utile solo quando riproduce lo stesso carico di lavoro e definisce cosa significhi “abbastanza veloce” prima di esaminare i grafici delle risorse. Altrimenti, i dati relativi a CPU, memoria, archiviazione e rete diventano semplici osservazioni senza una conclusione sulla capacità.

È diverso dal risolvere il problema di una singola installazione lenta. Un benchmark crea deliberatamente una baseline ripetibile, aumenta una dimensione del carico di lavoro e identifica quanto margine di risorse rimane prima che un'automazione scelta, una query sulla cronologia o la risposta di una dashboard superi il suo intervallo di latenza accettabile.

Definisci un solo carico di lavoro e una sola soglia di accettazione

Scegli un carico di lavoro che rappresenti un picco reale dell'abitazione: per esempio, un'automazione locale basata sul movimento, tre dashboard attive, le normali scritture del Recorder, un periodo in background senza backup e un insieme fisso di integrazioni. Registra la versione di Home Assistant, l'hardware host, l'archiviazione, il database, il client, il percorso di rete e la durata del test.

La vista Informazioni di sistema di Home Assistant espone il contesto relativo a installazione, rete, integrazioni e risorse, che dovrebbe essere registrato insieme al risultato delle prestazioni. Senza i dettagli dell'ambiente, il tempo di risposta di una persona non può essere confrontato in modo significativo con quello di un'altra macchina.

Definisci quindi la soglia di accettazione. Un'automazione dell'illuminazione potrebbe richiedere una risposta fisica inferiore al secondo, mentre una query della cronologia di cinque anni potrebbe essere accettabile in diversi secondi. Non combinare questi casi in un unico punteggio generico della “velocità di Home Assistant”.

Usa utilizzo, saturazione ed errori per ogni risorsa condivisa

Il solo utilizzo medio è un criterio insufficiente per decidere quando fermarsi. Un disco può essere occupato ma funzionare correttamente, oppure una CPU può mostrare un utilizzo medio moderato mentre brevi picchi creano una coda che gli utenti percepiscono come latenza.

Il metodo USE valuta utilizzo, saturazione ed errori per ogni risorsa fisica o soggetta a vincoli. Applica questo modello a CPU, capacità della memoria, I/O dell'archiviazione e interfacce di rete, invece di scegliere il grafico con l'utilizzo più elevato.

Per Home Assistant in container, considera come risorse anche i limiti dei cgroup. Un host con il 60% di CPU libera può comunque limitare un container che ha raggiunto la quota assegnata.

Le metriche di pressione mostrano il tempo perso a causa della scarsità di risorse

Il Pressure Stall Information di Linux aggiunge una prospettiva orientata alla latenza. Invece di chiedere soltanto quanta CPU, memoria o attività I/O viene utilizzata, PSI misura la frazione di tempo in cui i processi restano bloccati perché una risorsa è contesa.

La documentazione del kernel Linux spiega che la pressione su CPU, memoria e I/O può essere misurata come tempo reale perso a causa della contesa, inclusi brevi picchi che compromettono la latenza prima che l'utilizzo medio appaia estremo.

Questo rende PSI utile su un server domestico condiviso. Se la latenza di Home Assistant peggiora quando la pressione I/O aumenta durante il picco di scritture di un altro container, hai prove più solide di una contesa sull'archiviazione condivisa rispetto a “l'SSD era occupato al 70%”.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Aumenta una sola dimensione del carico di lavoro per ogni esecuzione

Non aggiungere contemporaneamente utenti delle dashboard, trigger delle automazioni, flussi video delle telecamere, conservazione dei dati e traffico di backup. Aumenta una variabile mantenendo fisse tutte le altre condizioni.

Test a incrementi utili includono più eventi di automazione al minuto, più dashboard simultanee, intervalli della cronologia più ampi, più aggiornamenti delle entità oppure un carico definito su un servizio vicino. Dopo ogni incremento, attendi abbastanza a lungo affinché il sistema raggiunga un comportamento stabile, invece di raccogliere solo i primi dieci secondi di una cache appena inizializzata o di un picco di avvio.

L'analisi di ZimaSpace sulla contesa nelle code dell'archiviazione condivisa e sulla latenza di coda mostra perché il carico di lavoro deve essere collegato al percorso della risorsa: l'archiviazione è rilevante solo quando l'azione testata dipende direttamente da essa o condivide la stessa coda I/O.

Modifica una risorsa e richiedi che il risultato cambi

Un benchmark diventa diagnostico quando una modifica controllata a una risorsa sposta la curva della latenza. Assegna a un processo vicino intenso una CPU diversa da quella di Home Assistant, sospendi un'attività ad alta intensità di scrittura, aumenta il limite di memoria del cgroup testato, usa un percorso LAN diretto oppure sposta i dati dell'app su un'archiviazione a latenza inferiore.

Se la soglia di latenza originale migliora allo stesso livello di carico, è plausibile che la risorsa stesse limitando il margine disponibile. Se non cambia nulla, annulla l'esperimento e testa il candidato successivo invece di trasformare la modifica in una configurazione permanente.

Pubblica il risultato come intervallo di capacità

Il risultato finale dovrebbe essere formulato così: “questo hardware, database, insieme di client e carico in background mantengono il percorso di controllo scelto entro l'obiettivo fino al livello N”. Questa affermazione è riproducibile. “Home Assistant usa solo il 20% della CPU” non lo è.