Warum erzeugt Home Assistant beim Lesen und Schreiben unterschiedliche Lasten?

Home Assistant erzeugt unterschiedliche Lese- und Schreiblasten, weil Abfragen zwischengespeicherte Seiten wiederverwenden, während die Persistenz von Zuständen Journale, Indizes und dauerhaften Speicher verändert.

Beim Öffnen eines Verlaufsdiagramms können viele gespeicherte Zeilen gelesen werden, ohne sie zu verändern, während ein unruhiger Sensor im Laufe des Tages zahlreiche kleine Transaktionen erzeugen kann. Das erste Muster begünstigt sequenzielle Lesevorgänge, den Datenbank-Cache und Abfrageindizes; das zweite verursacht zusätzlich Synchronisierung, Journalaktualisierungen, Dateisystemmetadaten und eine Schreibverstärkung des Flash-Speichers. Daher unterscheiden sich die Diagramme, obwohl beide Vorgänge dieselbe Recorder-Datenbank verwenden.

Live-Zustandsänderungen erzeugen mehr als einen Schreibvorgang

Recorder wandelt ausgewählte Zustands- und Ereignisänderungen in Datenbanktransaktionen um. Das Einfügen einer logischen Zeile kann außerdem Indizes sowie ein Journal oder Write-Ahead-Log aktualisieren, bevor Dateisystem und Gerätepuffer den dauerhaften Abschluss bestätigen.

Eine Erklärung zu Datenbanken und Statistiken trennt die kurzfristige Zustandsspeicherung von langfristigen Statistiken und verdeutlicht, warum Recorder-Datenstrukturen mehrere zusammenhängende Strukturen statt nur einer Datei im Append-only-Modus berühren können.

Entitäten mit hoher Aktualisierungsfrequenz erzeugen viele kleine logische Änderungen, die möglicherweise in Gruppen festgeschrieben werden. Dies kann als regelmäßige Lastspitzen erscheinen; die physisch geschriebenen Bytes können die Nutzdaten übersteigen, weil Datenbank- und Speicherebenen die Konsistenz bewahren.

Verlaufsabfragen hängen von Bereich, Selektivität und Cache ab

Eine Abfrage des aktuellen Zustands ist klein, aber ein Verlaufsdiagramm mit mehreren Entitäten kann einen großen Zeitraum durchsuchen, Attribute dekodieren, Ergebnisse aggregieren und an den Client senden. Geeignete Indizes und bereits im Speicher befindliche Datenbankseiten können viele dieser Vorgänge vom physischen Speicher fernhalten.

Ein länger andauernder Performance-Fall stellte fest, dass der Zugriff auf den Verlauf trotz gewöhnlicher Live-Nutzung extrem langsam war. Das zeigt, dass die Verlaufsabfragelast ein Problem im Abfragepfad aufdecken kann, das bei der Steuerung des aktuellen Zustands nicht auftritt.

Wiederholte Lesevorgänge werden oft schneller, wenn relevante Seiten im Speicher bleiben. Dieser Vorteil verschwindet nach einem Neustart, bei Speicherdruck oder bei einem anderen Datumsbereich. Daher ist eine einzelne Abfrage mit warmem Cache kein zuverlässiges Maß für die Speicherkapazität.

Die Schreibkosten steigen durch Protokollierung und benachbarte Dienste

Home Assistant Core ist nicht der einzige Schreibprozess auf einem typischen Heimserver. Debug-Protokolle, Datenbanken von Add-ons, Sicherungen, Kamera-Schnappschüsse und Containerprotokolle können dasselbe Gerät nutzen und genau dann eine Warteschlange verursachen, wenn Recorder einen Commit ausführt.

Praktiker, die den Flash-Verschleiß reduzieren wollten, stellten fest, dass Protokolle und verbundene Komponenten zusätzliche Schreibzyklen verursachen. Deshalb sollte die Schreibaktivität des gesamten Volumes berücksichtigt werden und nicht nur der Hauptprozess der Datenbank.

Eine Zuordnung auf Prozessebene trennt das Anwendungsverhalten von der Konkurrenz um den gemeinsam genutzten Speicher. Wenn Recorder ruhig ist, während ein anderer Container die Schreibvorgänge verursacht, werden Änderungen an den Entitätsausschlüssen die beobachtete Last nicht beheben.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wartungsarbeiten können das übliche Muster umkehren

Das Löschen abgelaufener Zeilen, der Neuaufbau von Indizes, VACUUM oder das Neupacken kann große Teile einer Datenbank lesen und neu schreiben. Während dieses Zeitraums kann eine als Bereinigung bezeichnete Aufgabe sowohl deutlich mehr Lese- als auch mehr Schreibvorgänge erzeugen als die normale Zustandsaufnahme.

Diskussionen zur Recorder-Konfiguration bringen Aufbewahrung und Bereinigungsverhalten mit der Datenbankwartung in Verbindung. Daher sind Aufbewahrungs- und Bereinigungsverhalten entscheidend, wenn regelmäßig jeden Tag zur selben Zeit eine Lastspitze auftritt.

Die Erklärung anhand von Lese- und Schreibvorgängen endet, wenn der Engpass bei der CPU-seitigen Template-Auswertung, der Client-Darstellung oder der Netzwerkübertragung liegt. Die Speicherzähler müssen gemeinsam mit dem Symptom ansteigen; andernfalls ist die Datenbank lediglich ein benachbarter Bestandteil der Verzögerung.

Einen Lese- und einen Schreibpfad vergleichen

Wähle eine feste Verlaufsabfrage und eine unkritische Aktion, die den Zustand ändert. Zeichne für beide die Anfragelatenz, CPU-Auslastung, Datenbankzeit, Datendurchsatz des Datenträgers, IOPS, Warteschlangentiefe und Gerätelatenz zunächst bei einem kalten Start und anschließend bei einer wiederholten Ausführung mit warmem Cache auf.

Das verwandte Thema Wachstum gespeicherter Daten erklärt, warum das Wachstum von Metadaten und Verlauf die Last verändert, und verankert den Vergleich in den aufbewahrten Daten statt in beliebigem Benchmark-Datenverkehr.

Ordne die Begrenzung anhand der Kovarianz ein: Ein langsamer erster Lesevorgang mit anschließend schnellem Wiederholungszugriff deutet auf Cache-Lokalität hin; steigende Abfragezeiten mit zunehmendem Bereich deuten auf Suchkosten hin; eine Schreibverzögerung zusammen mit wachsender Warteschlangentiefe deutet auf Konkurrenz um dauerhaften Speicher hin; kein Muster deutet auf eine andere Ebene hin. Optimiere nur den Pfad, der die für den Benutzer sichtbare Verzögerung zweimal reproduziert.