Varför genererar Home Assistant olika belastning vid läsningar och skrivningar?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Does Home Assistant Generate Different Loads During Reads and Writes?

Home Assistant genererar olika läs- och skrivbelastningar eftersom frågor återanvänder cachade sidor, medan beständig lagring av tillstånd ändrar journaler, index och beständig lagring.

Att öppna ett historikdiagram kan skanna många lagrade rader utan att ändra dem, medan en brusig sensor kan skapa små transaktioner under hela dagen. Det första mönstret gynnas av sekventiella läsningar, databascache och frågeindex; det andra tillför synkronisering, journaluppdateringar, filsystemmetadata och skrivförstärkning i flashminnet. Graferna skiljer sig därför åt även när båda åtgärderna använder samma Recorder-databas.

Liveförändringar av tillstånd skapar mer än en skrivning

Recorder omvandlar utvalda förändringar av tillstånd och händelser till databastransaktioner. Infogning av en logisk rad kan också uppdatera index och en journal eller förskrivningslogg innan filsystemet och enhetens cache bekräftar att slutförandet är beständigt.

En förklaring av databaser och statistik skiljer korttidslagring av tillstånd från långsiktig statistik och klargör varför Recorders datastrukturer kan beröra flera relaterade strukturer i stället för en enda fil som bara fylls på.

Entiteter med hög uppdateringsfrekvens skapar många små logiska förändringar som kan verkställas i grupper. Detta kan se ut som periodiska toppar; antalet fysiskt skrivna byte kan överstiga nyttolasten eftersom databas- och lagringslagren bevarar konsistensen.

Historikläsningar beror på intervall, selektivitet och cache

En uppslagning av det aktuella tillståndet är liten, men ett historikdiagram för flera entiteter kan skanna ett stort tidsintervall, avkoda attribut, aggregera resultat och skicka dem till klienten. Användbara index och varma databassidor kan hålla många av dessa åtgärder borta från den fysiska lagringen.

Ett långvarigt prestandafall visade att historikåtkomst var extremt långsam trots normal liveanvändning, vilket visar att historikfrågebelastning kan avslöja ett problem i frågevägen som inte uppstår vid styrning av aktuella tillstånd.

Upprepade läsningar blir ofta snabbare när relevanta sidor finns kvar i minnet. Den fördelen försvinner efter en omstart, vid minnestryck eller med ett annat datumintervall, så en enda varm fråga är inte ett tillförlitligt mått på lagringskapaciteten.

Skrivkostnaden ökar med loggning och närliggande tjänster

Home Assistant Core är inte den enda skrivaren på en typisk hemserver. Felsökningsloggar, tilläggsdatabaser, säkerhetskopior, kamerabilder och containerloggar kan dela samma enhet och orsaka köbildning precis när Recorder försöker verkställa en transaktion.

Personer som minskat slitaget på flashminnet har observerat att loggar och relaterade komponenter lägger till skrivcykler. Därför bör skrivaktiviteten på hela volymen omfatta hela volymen och inte bara huvuddatabasprocessen.

Attributering på processnivå skiljer applikationens beteende från konkurrens om delad lagring. Om Recorder är inaktiv medan en annan container står för skrivningarna kommer ändringar av entitetsundantag inte att påverka den observerade belastningen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Underhåll kan vända det vanliga mönstret

Rensning av utgångna rader, ombyggnad av index, vacuum-körning eller ompaktering kan läsa och skriva om stora delar av en databas. Under den perioden kan en uppgift som beskrivs som rensning skapa både tyngre läsningar och tyngre skrivningar än normal inläsning av tillstånd.

Diskussioner om Recorder-konfiguration kopplar lagringstid och rensningsbeteende till databasunderhåll, så lagrings- och rensningsbeteendet är avgörande när en regelbunden belastningstopp inträffar vid samma tid varje dag.

Förklaringen med läsning kontra skrivning gäller inte längre när flaskhalsen ligger i CPU-baserad mallutvärdering, klientrendering eller nätverksleverans. Lagringsmätvärdena måste öka samtidigt som symptomet; annars ligger databasen bara nära fördröjningen utan att orsaka den.

Jämför en läsväg och en skrivväg

Välj en fast historikfråga och en ofarlig åtgärd som ändrar tillståndet. För varje åtgärd registrerar du svarstid, CPU-användning, databastid, diskgenomströmning, IOPS, ködjup och enhetens svarstid från en kall start och därefter från en upprepad varm körning.

Den relaterade artikeln om tillväxten av lagrade data förklarar varför tillväxten av metadata och historik förändrar belastningen och förankrar jämförelsen i lagrade data i stället för godtycklig benchmarktrafik.

Klassificera begränsningen utifrån samvariation: långsam första läsning plus snabb upprepning tyder på cachelokalitet; ökande frågetid med större intervall tyder på skanningskostnad; skrivfördröjning plus ökat ködjup tyder på konkurrens om beständig lagring; inget av dessa mönster tyder på ett annat lager. Optimera endast den väg som återskapar den användarsynliga fördröjningen två gånger.