Original in Englisch ->
ZRAM status - Tutorials & Examples - openHAB Community
Was ist ZRAM und wie funktioniert es?
Das ZRAM-Konfigurationsprogramm für Swap, Directory & Log ist eine Betriebssystemerweiterung für IoT-/Maker-Projekte, um den Verschleiß von SD-, NAND- und eMMC-Blöcken zu reduzieren, der durch Schreibvorgänge wie Logging und Persistenz in openHAB verursacht wird. Es nutzt Komprimierung, um den wertvollen Speicherplatz zu minimieren und extrem seltene Schreibvorgänge und Arbeitsverzeichnisse mit annähernder RAM-Geschwindigkeit mit Speicherkomprimierungsverhältnissen, die von Ihren Daten und dem von Ihnen gewählten Komprimierungsalgorithmus abhängen.
ZRAM ist als Installationsoption in openHABian verfügbar, verwenden Sie Menüpunkt 38 zur Installation oder den nächsten (nicht nummerierten) Punkt zur Deinstallation.
ZRAM verwendet eine Tabelle in /etc/ztab, in der eine beliebige Kombination und Anzahl von ZRAM-Laufwerken erstellt werden kann. Bei dieser Implementierung wird ein OverlayFS-Mount mit ZRAM verwendet, so dass das Kopieren von Daten von der Festplatte in den RAM beim Booten nicht erforderlich ist. Dies sollte einen schnelleren Bootvorgang und größere Verzeichnisse ermöglichen, da keine komplette Verzeichniskopie erforderlich ist. Es ist alles der untere Mount im OverlayFS.
ZRAM ist standardmäßig für neue openHABian-Installationen aktiviert.
In einer openHABian-Implementierung werden swap, /var/log/* und /var/lib/openhab2/persistence in ZRAM ausgelagert. All das sind entbehrliche Daten, d.h. selbst wenn etwas schief gehen sollte, sollte Ihr openHAB-System weiterlaufen. Es gibt ein Protokoll in /usr/local/share/zram-config/log/.
Wir haben dies für neue openHABian-Einsätze geändert. Wenn Sie ZRAM für /var/lib/openhab2 verwendet haben, können Sie Ihre /etc/ztab bearbeiten, um diese Änderung auch auf Ihrem bestehenden System vorzunehmen. Danach ist ein Neustart erforderlich.
OverlayFS und Mounting
Beim ordnungsgemäßen Herunterfahren des Dienstes (zram-config stop oder reboot/shutdown) werden die von zram erstellten Verzeichnisse (OverlayFS) mit dem "unteren" Dateisystem synchronisiert (derselbe Verzeichnisname auf dem /-Dateisystem, das sich auf dem Standard-Bootmedium befindet) und das "obere" Dateisystem (der Teil im Speicher) wird "Lazy unmounted".
Lazy unmounting bedeutet, dass es immer noch Prozesse geben kann, die offene Dateien in diesem Verzeichnis haben. Das ist notwendig, um Systemprozesse zu starten (und am Laufen zu halten), die Verzeichnisse wie z.B. /var/log benutzen.
DOs und DON'Ts
• Sie dürfen Ihren openHABian-Server nicht ausschalten, bevor Sie ihn nicht ordnungsgemäß heruntergefahren haben. Dies ist eine Anforderung, die nichts mit ZRAM zu tun hat und im Grunde seit es UNIX gibt. Schließen Sie ihn außerdem an eine unterbrechungsfreie Stromversorgung (USV) an, um sich gegen Stromausfälle zu schützen.
• Verwenden Sie nicht zram-config sync (auch wenn es in Ihrer installierten Version vorhanden ist). Es ist bekannt, dass dies in einer Reihe von Situationen nicht funktioniert und zu Datenverlusten führen kann.
• Verwenden Sie eine Backup-Lösung wie Amanda 162, um tägliche Backups Ihrer zram'ed-Verzeichnisse (und natürlich auch des restlichen Systems) zu erstellen. ZRAM kann nicht vor Stromausfällen oder HW-Fehlern schützen.
• Überprüfen Sie Ihre OH-Protokolleinstellungen (log:get in der openHAB-Konsole) und stellen Sie sicher, dass nicht mehr Protokolle erzeugt werden, als Sie benötigen. Überprüfen Sie auch deren Anzahl und Größe: /var/lib/openhab/etc/log4j2.xml. Die gesammelten Logs müssen in das ZRAM-Verzeichnis passen, das in /etc/ztab definiert ist (beachten Sie, dass auch die Systemlogs dorthin gehören, aber standardmäßig ist das nur eine kleine Menge im Vergleich zu den OH-Logs).
• Sie sollten ZRAM nicht verwenden, es sei denn, Sie arbeiten mit einem SBC (kleiner "Einplatinen"-Computer wie Raspberry Pis), dessen Betriebssystem auf einem Flash-Speichermedium wie einer SD-Karte oder einem (!) USB-Stick läuft. USB-Sticks sind nicht besser oder sicherer als interne SD-Karten 51 - ein weiterer guter Grund für ZRAM.
• lassen Sie ZRAM nicht auf Maschinen laufen, die weniger als 1GB RAM haben, wie z.B. ein RPi Zero.
• lassen Sie es nicht auf Nicht-SBCs oder modifizierten SBCs laufen, um von "sicheren" Medien wie SSD oder HDD zu laufen. Nun, man kann es tun, aber es gibt nur einen vernachlässigbaren Vorteil dabei, so dass das Kosten/Risiko/Nutzen-Verhältnis schlecht ist.
• Wenn (und nur wenn) Sie ein SBC-System mit mehr als 1 GB haben, wie z.B. einen Raspi 4 mit 2,4 oder 8 GB oder einen anderen SBC mit 2 GB oder mehr, können Sie die Menge an RAM, die ZRAM zugewiesen ist, in /etc/ztab erhöhen, beginnend mit /var/lib/openhab2. Machen Sie sich keine Sorgen, dass ZRAM nicht die volle Maximalmenge belegen wird, wenn es nicht wirklich nötig ist.
• Sie können die Liste und die Größe der zu cachenden Verzeichnisse ändern, indem Sie die Einträge in /etc/ztab ändern. Wenn Sie es z.B. für zu riskant halten, die gesamte /var/lib/openhab2 aus dem ZRAM auszulagern, weil Sie z.B. nicht wollen, dass sich der Karaf-Cache dort befindet (da er sehr groß ist und so gut wie nur einmal beschrieben werden kann), können Sie ein Kommentarzeichen vor diese Zeile setzen oder sie durch zwei Zeilen für /var/lib/openhab2/jsondb und .../persistence ersetzen. Seien Sie sich aber bewusst, dass jede solche Änderung die Schreiblast auf Ihrer SD erhöht und damit die Wahrscheinlichkeit, dass Sie von Verschleiß betroffen sind. Siehe GitHub - mstormi/openhabian-zram: zram extensions for openHABian 67 für eine Erklärung der ztab-Felder.
• Es sind Statistiken verfügbar: Führen Sie zramctl ohne Optionen aus. Für erweiterte Statistiken enthält die Datei /sys/block/zram<id>/mm_stat alle Informationen, die Sie benötigen. Den kompletten Satz an Statistiken finden Sie in den Kernel-Dokumenten 11.
Bekannte Probleme
Sie könnten auf ein Fehlverhalten stoßen. Bitte lassen Sie es mich wissen, wenn dies der Fall ist, und teilen Sie mir die relevanten Details mit. Haben Sie in letzter Zeit etwas getan, das möglicherweise ein Auslöser war? Haben Sie eine .items- oder .rules-Datei bearbeitet? Eine Sache oder eine Bindung hinzugefügt, die zu einem Problem führen könnte ? Haben Sie die openHAB Version geändert (inkl. Milestones, Snapshot)?
Sie könnten auf Fehler bezüglich schreibgeschützter Dateien stoßen.
Wenn ja, rufen Sie zramctl auf und vergleichen Sie die Spalte TOTAL des ZRAM-Geräts für /var/lib/openhab2 (das ist normalerweise die zweite Zeile in der Ausgabe mit /dev/zram1).
Wenn dieser Wert größer oder gleich dem Wert ist, den Sie dieser Freigabe in /etc/ztab zugewiesen haben, passen selbst die komprimierten Daten nicht hinein. Weisen Sie mehr Platz zu. Er wird nur dann vom System verwendet, wenn ein Bedarf besteht Siehe OH-Upgrade-Verfahren.
• nach systemctl stop zram-config oder /usr/local/bin/zram-config stop bleibt möglicherweise ein ZRAM-Gerät /dev/zramX bestehen (X ist eine Zahl). Sie können versuchen, es mit zramctl -r /dev/zramX zu entfernen. Wenn das fehlschlägt, starten Sie neu, um es loszuwerden. Eventuell kann systemctl openhab2 vorher deaktivieren, damit es nicht automatisch nach dem Booten gestartet wird.
• Es kann sein, dass Sie Meldungen über verweigerte Zugriffsrechte sehen, die besagen, dass das System nicht in diese Verzeichnisse oder Dateien schreiben kann, weil sie schreibgeschützt sind. Dieses Problem wurde von den Benutzern nicht gemeldet, tauchte aber gelegentlich während der Tests auf. Es gibt viele mögliche Gründe dafür, und es wird noch untersucht, was der wahrscheinlichste/häufigste Grund dafür ist. ZRAM wird nie mit der Festplatte synchronisiert, es sei denn, Sie stoppen es (dabei werden alle Dateien synchronisiert, die in die ZRAM-Verzeichnisse gewechselt haben, und diese werden dann ausgehängt). Beim nächsten Start werden diese nicht mehr in den RAM kopiert, so dass der RAM-Verbrauch gering ist.
Genau wie auf der Festplatte muss die Menge an RAM, die ZRAM zur Verfügung haben muss, größer sein als die Menge an Daten, die dort gespeichert werden sollen, aber es ist etwas komplizierter als das, weil die Daten auch mit einem unterschiedlichen Komprimierungsfaktor komprimiert werden, so dass die genaue Menge an Rohdaten, die dort hineinpassen, unbekannt ist. Die Menge an Speicher, die ZRAM zur Verfügung steht, ist statisch (definiert in /etc/ztab).
Wenn nun etwas passiert, das mehr geänderte Daten in zram'ed-Verzeichnisse schreibt, als dort hineinpassen, ist "permission denied" (meistens) die Art und Weise, wie sich das System vor noch schwerwiegenderen Auswirkungen schützt.
Sie können versuchen, zram'ed-Daten zu löschen, aber normalerweise müssten Sie Ihr System herunterfahren (und das ist eindeutig die sicherere Methode).
Dabei schreibt ZRAM die Daten nämlich einmalig und am Stück auf die SD-Karte.
wobei das nur eine Vermutung ist... vielleicht hat sich nur noch niemand getraut, zu fragen...