Perché Home Assistant genera carichi diversi durante le operazioni di lettura e scrittura?

Home Assistant produce carichi diversi in lettura e scrittura perché le query riutilizzano le pagine memorizzate nella cache, mentre la persistenza dello stato modifica journal, indici e spazio di archiviazione durevole.

L’apertura di un grafico della cronologia può analizzare molte righe archiviate senza modificarle, mentre un singolo sensore rumoroso può creare piccole transazioni durante tutta la giornata. Il primo schema favorisce letture sequenziali, la cache del database e gli indici delle query; il secondo aggiunge sincronizzazione, aggiornamenti del journal, metadati del file system e amplificazione delle scritture sulla memoria flash. Per questo i relativi grafici differiscono anche quando entrambe le operazioni coinvolgono lo stesso database Recorder.

I cambiamenti dello stato in tempo reale generano più di una scrittura

Recorder converte i cambiamenti selezionati dello stato e degli eventi in transazioni del database. L’inserimento di una riga logica può inoltre aggiornare gli indici e un journal o log di scrittura anticipata prima che il file system e la cache del dispositivo confermino il completamento durevole.

Una guida esplicativa su database e statistiche separa l’archiviazione dello stato a breve termine dalle statistiche a lungo termine, chiarendo perché le strutture dei dati di Recorder possano interessare diverse strutture correlate invece di un solo file a cui vengono aggiunti dati.

Le entità ad alta frequenza creano molti piccoli cambiamenti logici che possono essere sottoposti a commit in gruppi. Questo può apparire come una serie di raffiche periodiche; i byte scritti fisicamente possono superare il payload perché i livelli del database e dello storage preservano la coerenza.

Le letture della cronologia dipendono da intervallo, selettività e cache

Una ricerca dello stato corrente è ridotta, ma un grafico della cronologia con più entità può analizzare un ampio intervallo temporale, decodificare gli attributi, aggregare i risultati e inviarli al client. Indici utili e pagine del database già presenti in cache possono mantenere molte di queste operazioni lontane dallo storage fisico.

Un caso di prestazioni analizzato a lungo ha rilevato un accesso alla cronologia estremamente lento nonostante il normale utilizzo in tempo reale, mostrando che il carico delle query sulla cronologia può rivelare un problema nel percorso delle query che il controllo dello stato corrente non attiva.

Le letture ripetute spesso diventano più veloci quando le pagine pertinenti rimangono in memoria. Questo vantaggio scompare dopo un riavvio, sotto pressione della memoria o con un intervallo di date diverso, quindi una singola query eseguita con la cache già calda non è una misura affidabile della capacità dello storage.

Il costo delle scritture cresce con la registrazione e i servizi vicini

Home Assistant Core non è l’unico processo che scrive su un tipico server domestico. I log di debug, i database degli add-on, i backup, le istantanee delle telecamere e i log dei container possono condividere lo stesso dispositivo e causare accodamenti proprio quando Recorder sta tentando di eseguire il commit.

Gli utenti che hanno ridotto l’usura della memoria flash hanno osservato che i log e i componenti correlati aggiungono cicli di scrittura; per questo l’attività di scrittura sull’intero volume dovrebbe includere tutto il volume, non soltanto il processo principale del database.

L’attribuzione a livello di processo separa il comportamento dell’applicazione dalla contesa sullo storage condiviso. Se Recorder è inattivo mentre un altro container esegue le scritture, modificare le esclusioni delle entità non risolverà il carico osservato.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

La manutenzione può invertire lo schema abituale

L’eliminazione delle righe scadute, la ricostruzione degli indici, il vacuum o il riconfezionamento possono leggere e riscrivere grandi parti di un database. Durante questa fase, un’attività descritta come pulizia può generare sia più letture sia più scritture rispetto alla normale acquisizione dello stato.

Le discussioni sulla configurazione di Recorder collegano la conservazione dei dati e il comportamento delle operazioni di eliminazione alla manutenzione del database, quindi le impostazioni di conservazione e di eliminazione sono essenziali quando un picco di carico regolare compare ogni giorno alla stessa ora.

La spiegazione basata sulla differenza tra letture e scritture non è più valida quando il collo di bottiglia è la valutazione dei template lato CPU, il rendering del client o la distribuzione tramite rete. I contatori dello storage devono aumentare insieme al sintomo; altrimenti il database è soltanto adiacente al ritardo.

Confronta un percorso di lettura e uno di scrittura

Scegli una query della cronologia fissa e un’azione innocua che modifichi lo stato. Per ciascuna, registra la latenza della richiesta, l’utilizzo della CPU, il tempo del database, il throughput del disco, gli IOPS, la profondità della coda e la latenza del dispositivo, prima partendo da una cache fredda e poi ripetendo l’operazione con la cache calda.

La guida correlata sulla crescita dei dati conservati spiega perché la crescita dei metadati e della cronologia modifichi il carico di lavoro, ancorando il confronto ai dati conservati invece che a un traffico di benchmark arbitrario.

Classifica il limite in base alla covarianza: una prima lettura lenta seguita da una ripetizione veloce suggerisce una località della cache; un tempo di query crescente all’aumentare dell’intervallo suggerisce il costo della scansione; un ritardo nelle scritture insieme alla profondità della coda suggerisce una contesa sullo storage durevole; l’assenza di entrambi gli schemi suggerisce un altro livello. Ottimizza soltanto il percorso che riproduce due volte il ritardo percepibile dall’utente.