So konfigurierst du Cache und temporären Speicher in Home Assistant

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Konfigurieren Sie den Home-Assistant-Cache, indem Sie zunächst feststellen, welche Daten entbehrlich sind. Verschieben Sie niemals den gesamten Pfad der persistenten Konfiguration in einen temporären Speicher.

„Cache“ kann Browser-Frontend-Assets, TTS-Ausgaben, integrationsspezifische temporäre Dateien, das /tmp eines Containers, den Seitencache des Betriebssystems oder den Arbeitsbereich einer Datenbank bedeuten. Diese Ebenen haben unterschiedliche Verantwortliche und ein unterschiedliches Wiederherstellungsverhalten. Bewahren Sie Benutzer, Registrierungen, Konfiguration, den Recorder-Zustand und andere maßgebliche Dateien auf dauerhaftem Speicher auf. Verwenden Sie tmpfs oder RAM-basierten Speicher nur für einen dokumentierten, entbehrlichen Pfad, dessen Verlust und Speicherverbrauch Sie durch einen Neustart getestet haben.

Ordnen Sie den Cache ein, bevor Sie einen Pfad verschieben

Beginnen Sie damit, Verantwortlichen, Pfad, maximal erwartete Größe, Wiederaufbaumethode und die Folgen eines Datenverlusts zu benennen. Der Browser-Cache befindet sich auf dem Client; der persistente Anwendungszustand von Home Assistant liegt unter dem konfigurierten Datenpfad; Integrations-Caches unterscheiden sich; temporäre Containerdateien können beim Neustart verschwinden. Diese Bereiche sollten nicht mit einer einzigen globalen Einstellung für ein „Cache-Verzeichnis“ gelöst werden.

Ein Home-Assistant-TTS-Fall zeigt ein eng begrenztes Beispiel, bei dem generierte Audiodateien unter einem bestimmten Cache-Pfad absichtlich an einen RAM-basierten Speicherort umgeleitet wurden. Die wichtige Grenze beim Verschieben eines entbehrlichen TTS-Caches besteht darin, dass der Benutzer auf ein einzelnes wiederherstellbares Verzeichnis und nicht auf den gesamten Konfigurationsbaum abzielte.

Wenn Sie nicht nachweisen können, dass eine Datei verschwinden kann, ohne Identität, Verlauf, Einstellungen, Dashboards oder die Registrierung einer Integration zu verlieren, stufen Sie sie als persistent ein. Die sicherste Standardeinstellung ist dauerhafter Speicher. Optimierungen folgen erst, wenn geklärt ist, wer für die Wiederherstellung zuständig ist.

Bewahren Sie den persistenten Home-Assistant-Zustand und den Recorder auf dauerhaftem Speicher auf

Der Konfigurations-Mount ist kein Cache, nur weil er einige generierte Dateien enthält. Er kann Authentifizierungsdaten, Entitäts- und Geräteregistrierungen, den Automatisierungszustand, die Konfiguration, benutzerdefinierte Komponenten und die standardmäßige Recorder-Datenbank enthalten. Wenn Sie den gesamten Pfad auf tmpfs legen, führt ein Neustart zu Datenverlust. Außerdem hängen Backups dann von Speicherinhalten ab, die nie als maßgebliche Daten gedacht waren.

Die Erklärung von ZimaSpace zu den Rollen persistenter Home-Assistant-Daten ist der richtige erste Filter: Trennen Sie maßgeblichen Zustand, wiederaufbaubaren Cache und temporäre Arbeitsdaten, bevor Sie Speicherklassen zuweisen.

Verwenden Sie für den Anwendungszustand eine SSD oder ein anderes zuverlässiges Dateisystem mit dauerhaftem Speicher und halten Sie ausreichend freien Speicher für Datenbankwachstum, Upgrades und Wartungsarbeiten vor. Das Verschieben eines kleinen entbehrlichen Caches in den RAM kann ein zu kleines oder fehlerhaftes persistentes Volume nicht ausgleichen.

Verwenden Sie tmpfs nur für ausdrücklich entbehrliche Pfade mit Speicherbegrenzung

tmpfs kann Schreibvorgänge reduzieren und eine sehr niedrige Latenz bieten, verbraucht jedoch den Arbeitsspeicher des Hosts und verschwindet, wenn der Container oder Host beendet wird. Dadurch eignet es sich für begrenzte Arbeitsdaten, nicht aber für etwas, das nach einem Neustart benötigt wird. Der Mount muss außerdem so dimensioniert sein, dass eine temporäre Auslastung nicht den für Home Assistant Core und benachbarte Dienste benötigten Speicher aufbrauchen kann.

Ein aktueller Docker-Compose-Leitfaden erklärt, dass die tmpfs-Nutzung auf die Speicherkapazität angerechnet wird und bei einer im Verhältnis zum Container-Budget zu großen oder unbegrenzten Konfiguration zu Fehlern wegen fehlenden Speicherplatzes oder zu OOM-Zuständen führen kann.

Legen Sie eine Größenobergrenze fest, überwachen Sie die maximale Auslastung und starten Sie den Container bewusst neu. Der Pfad sollte automatisch wieder befüllt werden, während Benutzer, Einstellungen, Verlauf und Integrationen unverändert bleiben. Wenn die Anwendung das Verzeichnis nicht wiederherstellen kann oder sein Fehlen als Beschädigung behandelt, verschieben Sie es zurück auf dauerhaften Speicher.

Betrachten Sie den Frontend-Cache als Client-Problem, nicht als Serverspeicher

Eine veraltete Home-Assistant-Seite kann in einem Browser bestehen bleiben, obwohl der Server fehlerfrei arbeitet, weil Frontend-Ressourcen vom Browser oder der App zwischengespeichert werden. Das Löschen temporärer Dateien auf dem Server behebt diesen Client-Zustand nicht. Umgekehrt reduziert das Leeren des Browser-Caches weder die Festplatten-I/O des Recorders noch die Größe der Home-Assistant-Datenbank.

Home-Assistant-Benutzer unterscheiden ausdrücklich zwischen dem Frontend-Cache als Browser-Cache. Deshalb sollte die Cache-Fehlerbehebung damit beginnen festzustellen, ob das Problem nur auf einem Client oder auf dem gesamten Server auftritt.

Verwenden Sie einen bereinigten Browser oder ein privates Profil als Kontrolltest. Wenn der neue Client ordnungsgemäß funktioniert, belassen Sie die Lösung auf der Frontend-Seite. Wenn alle Clients dieselben fehlenden Daten oder denselben serverseitigen Fehler anzeigen, löschen Sie nicht weiter lokale Caches, sondern kehren Sie zur Fehlerbehebung anhand von Home-Assistant-Protokollen, Speicher, Integrationen oder Datenbanken zurück.

Testen Sie temporären Speicher durch Neustart-, Belastungs- und Freispeichertests

Messen Sie nach der Änderung eines Cache- oder tmpfs-Pfads die normale und maximale Größe, den verfügbaren Host-Speicher, den Speicherdruck des Containers, den freien Speicherplatz des persistenten Volumes und das Neustartverhalten. Führen Sie anschließend die Arbeitslast aus, die den Cache erstellt – TTS, Medien, die Verarbeitung durch eine benutzerdefinierte Integration oder einen anderen bekannten Erzeuger – und bestätigen Sie, dass die Bereinigung wie erwartet erfolgt.

Halten Sie auf dem dauerhaften Speicher ausreichend Reserve für Vorgänge vor, die temporären Arbeitsbereich benötigen, auch wenn die Datenbank im täglichen Betrieb bequem hineinpasst. Füllen Sie das persistente Volume nicht, nur weil ein RAM-Cache normale Schreibvorgänge kleiner erscheinen ließ. Upgrades, Datenbankwartung, Backups und Protokollspitzen können sehr unterschiedliche Anforderungen an temporären Speicherplatz haben.

Der Test ist bestanden, wenn jeder entbehrliche Pfad verschwinden und wiederaufgebaut werden kann, der persistente Zustand einen Container- und Host-Neustart übersteht, die maximale tmpfs-Nutzung innerhalb des Speicherbudgets bleibt und Home Assistant weiterhin ausreichend freien dauerhaften Speicher hat. Wenn nach dem Test eine erforderliche Einstellung oder ein Verlauf verschwunden ist, wurde der Pfad falsch eingestuft und muss vor weiteren Optimierungen zurück auf persistenten Speicher verschoben werden.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.