Hoher Systemload

[willy]

Hallo zusammen,

ich steuere schon seit einigen Jahren unser Haus mit Openhab. Im vergangenden Jahr habe ich OH3.3 parallel auf einem zweiten RPi installiert und bin so nach und nach von OH2.5 umgezogen. Soweit problemlos. Die OH3.3-Installation wurde inzwischen Master und hat die alte Installation fast vollständig ersetzt. Inzwischen ist die aktuelle OH3.4 Version herausgekommen, auf diese habe ich dann auch geupdatet.

Seitdem habe ich nun leider das Problem dass sich der Systemload zumeist morgens gegen 05:00 und Abends gegen 19:00 auf ca. 35 bis 45 erhöht. Das System ist dann für ca. 30 bis 60 min nur noch schwer zu erreichen / nicht bedienbar. In diesem Zeitraum werden dann einige Rules nicht ausgeführt, Fehlalarme u.s.w. In den logs gib es dann vermehrt Fehler wie :

Code: Alles auswählen

2023-02-07 19:37:33.110 [ERROR] [enhab.core.model.script.actions.HTTP] - Fatal transport error: java.util.concurrent.TimeoutException: Total timeout 5000 ms elapsed
[...]
2023-02-07 19:39:59.625 [WARN ] [d4j.internal.RRD4jPersistenceService] - Failed to open rrd4j database 'CPU_Load' to store data (java.lang.IllegalStateException: request interrupted for file:///var/lib/openhab/persistence/rrd4j/CPU_Load.rrd)
[...]
2023-02-07 19:44:04.769 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.io.monitor.internal.EventLogger@1cfc515' takes more than 5000ms.

Inzwischen habe ich OH3.4 nocheinmal komplett neu aufgesetzt, aber die gleichen Probleme, nur ist die Tageszeit leicht verschoben. Die Sd-Karte habe ich auch getauscht.

Mein System:

* Raspberry4 4GB Ram
* aktuelles Openhabian mit OH3.4.1
* mqtt-server local (ein zweiter von der Solaranlage wird eingebunden)
* zigbee2mqtt
* grafana
* persistence : influxdb + rrd4j
* apache2
* ca. 440 Items --> davon einige 'virtuelle' ; der Rest kommt zumeist über mqtt oder direkt per rest-api

Die rules sind alle mit JavaScript ECMA-2021 geschrieben. Da das System nun komplett neu aufgesetzt ist, kann es auch nicht an einem evtl. schief gelaufenen upgrade liegen. Aktuell habe ich nur noch ZRAM auf'm Zettel ...

Evtl. hat jemand von euch einen Hinweis für mich wo ich hier noch gucken kann.

Vielen Dank schonmal und beste Grüße

[willy]

Hallo,

hier mal ein update mit dem Versuch das Problem weiter einzugrenzen:
zram ist deinstalliert, jedoch keine Besserung.
Die folgenden Verzeichnisse (/var/log ; /var/lib/openhab/persistence ; /var/lib/influxdb) habe ich erstmal manuell ins RAM verschoben.

Nach genauerer Sichtung der logs scheint es, das sich der Dienst openhab zu den jeweiligen Zeitpunkten neu startet. Das bestätigt auch systemctl status openhab ...

Jetzt weiß ich nicht mehr so recht wo ich noch was machen kann, evtl. habt Ihr ja noch nen Hinweis.

Danke, Grüße!

[KellerK1nd]

Ja warum startet dein openhab überhaupt neu? Ist in den Logs kurz vor dem Restart nix zu erkennen? Auch mal im Journalctl danach schauen. Zu dem Zeitpunkt des Neustarts ist ja klar, das openhab nicht ansprechbar ist. Bis alles initialisiert ist dauerts beim Raspi etwas.

Ich würde jetzt aber mal die SD Karte ins Auge fassen. Vielleicht ist sie am sterben.

[willy]

ich habe mal im journalctl gesucht :

Code: Alles auswählen

Feb 15 04:05:18 openhabian karaf[28772]: Terminating due to java.lang.OutOfMemoryError: Java heap space
Feb 15 04:05:18 openhabian systemd[1]: openhab.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED
Feb 15 04:05:18 openhabian systemd[1]: openhab.service: Failed with result 'exit-code'.
Feb 15 04:05:18 openhabian systemd[1]: openhab.service: Consumed 5h 57min 43.414s CPU time.
Feb 15 04:05:23 openhabian systemd[1]: openhab.service: Scheduled restart job, restart counter is at 1.

In der syslog steht auch nicht mehr.

@sd-karte: ist neu und habe ich beim neuaufsetzen schon getauscht

Danke, Grüsse

[udo1toni]

Na ja, steht ja klipp und klar da: OutOfMemoryError.
Die Frage ist nun, warum openHAB der Speicher ausgeht. Welche Bindings hast Du im Einsatz? Wie hast Du konfiguriert (UI oder Text)?
Irgendwelche Besonderheiten auf dem System (zusätzliche Software, angepasste Startparameter wie z.B. geänderte RAM-Allocation...)?

ZRAM solltest besser wieder einschalten, es sorgt dafür, dass Deine SD-Karte nicht so schnell stirbt.

Laufen Grafana und InfluxDB auch auf dem Pi? Aber grundsätzlich sollte das keine Rolle spielen, InfluxDB braucht sozusagen überhaupt kein RAM (echt absurd... läuft bei mir seit Mitte Januar in einem eigenen LX Container und kommt trotz ca. 1400 verwalteten Items niemals über 230 MByte hinaus (Der Container "dürfte" 1 GByte beanspruchen... tut er aber nicht, egal was ich anstelle).

[willy]

Hallo,

@Bindings :
* Denon, deconz, Http, mqtt, neato, pushover, remoteOpenHab, Systeminfo, unifi
also nix besonderes

@config :
gemischt, die script/rules sind alle per ui. Die items/things (fast) alle per files. Hier keien großen Änderungen zur OH3.3 (wo noch alles lief)

@Besonderheiten : eigentlich nicht
ich habe nur noch apache2+php drauf, der empfängt Daten der Wetterstation und reicht diese an OH weiter

@zram : habe ich inzwischen auch wieder draufgemacht

@grafana+influx : ja ist drauf, aber scheinbar sehr genügsam, gleich Erfahrung

Habe inzwischen das update auf 3.4.2 gemacht, mal gucken pünktlich um 18:00 ist es ja wieder soweit, dann beobachte ich mal den RAM.

[willy]

Hallo,

das update hat keine Änderung gebracht. Ich habe mir mal den Speicherverbrauch von OH angeschaut :

openhab-cli console:

Code: Alles auswählen

openhab> shell:info
[...]
Memory
  Current heap size           989,793 kbytes
  Maximum heap size           997,376 kbytes
  Committed heap size         997,376 kbytes
[...]

das sieht für mich nach "viel" aus. Passt das zu nem RPi4 4GB?

Ich habe die /etc/default/openhab mal angepasst :

Code: Alles auswählen

EXTRA_JAVA_OPTS="-XX:+ExitOnOutOfMemoryError -Xms1024m -Xmx2048m"

danach sieht's so aus :

Code: Alles auswählen

Memory
  Current heap size           1,030,488 kbytes
  Maximum heap size           2,097,152 kbytes
  Committed heap size         1,192,960 kbytes

Bin mal gespannt ob das was gebracht hat, werde berichten.

Danke und Grüße!

[udo1toni]

Grundsätzlich ist es so, dass Java den Speicher, der vorhanden ist, auch nutzt. Wenn es also 1 GByte nutzen darf, wird das eine GByte auch gefüllt, bei 2 GByte werden eben zwei GByte gefüllt. Wenn ein Prozess Speicher zurück gibt, merkt sich Java, dass es diesen wieder verwenden darf, leert ihn aber nicht. Erst wenn der Speicher voll läuft, kommt die Garbage Collection zum Zug und räumt auf.
Ich habe bei mir keinerlei JAVA_EXTRA_OPTS gesetzt der Container hat insgesamt drei GByte RAM zur Verfügung und ein GByte Swap (ich habe noch nie gesehen, dass ein Container überhaupt Swap anrührt...), als Mem wird bei mir allerdings folgendes ausgegeben:

Code: Alles auswählen

Memory
  Current heap size           1,462,054 kbytes
  Maximum heap size           16,445,440 kbytes
  Committed heap size         2,514,944 kbytes

und ich habe keine Ahnung, woher der Heap von 16 GByte kommt. (Die Partition für das System hat 8 GByte, davon sind etwas mehr als 2 GByte belegt.) Vielleicht hängt das mit der 64-Bit-Version von Java zusammen.

Ich nutze 1395 Items, die auf 132 Things verteilt sind (ich könnte da mal ausmisten, der Großteil der Daten interessiert mich gar nicht...) Meine Sitemap ist 77 kByte groß, 56 Rules auf Textbasis nutzen zusammen 40 kByte, also nicht sonderlich groß, aber auch nicht sehr klein.

Ich denke, der Hauptunterschied ist tatsächlich, dass Java sich bei mir frei entfalten kann.

Es kann also gut sein, dass die Zuteilung von mehr Speicher Ruhe bringt. Es ist aber auch immer noch möglich, dass ein einzelner Prozess Speicher alloziert aber nicht mehr korrekt frei gibt, was dann halt nur später zu einem Problem führt. Letztlich musst Du beobachten, wie sich das System verhält

[willy]

Hallo,

nun läuft das system seit >1d ohne probleme, ich hoffe mal das bleibt so. DIe Umstellung der EXTRA_JAVA_OPTS wie oben beschrieben ist hier erstmal die Lösung. Wobei ich nicht ganz verstehe warum die Standardinstallation hier begrenzt ist.
Mein RPi4 mit 4GB hat noch ~ 1,4GB Speicher verfügbar, also ist da noch Luft nach oben. Aktuell belegt openhab ca. 1,3GB. Weiter habe ich festgestellt das das System jetzt flüssiger läuft, der Systemload ist jetzt im Schnitt knapp unter 1, vorher war er konstannt zwischen 2 und 5.

wenn ich den Speicherverbrauch bei knappen 1400 Items sehe, sollte mein 4GB-RPi noch eine ganze weile ausreichend sein.

Besten Dank für die Hilfe, Grüße!

[udo1toni]

Ja, wie gesagt, der Speicherbedarf hängt nur sehr indirekt mit der Menge an Items, Things und Rules zusammen.
Die künstliche Begrenzung rührt vor allem daher, dass openHABian auch auf Raspberry Pi2B ausführbar sein soll, auch wenn das niemand mehr so nutzen will, und auch der Pi3 ist nicht üppig mit RAM bestückt.

Grundsätzlich sollte openHAB aber auch mit weniger als 1 GByte gut zurecht kommen. Es ist also eine legitime Lösung, wenn das System jetzt stabil läuft (und vor allem stabil bleibt - Schwankungen nach oben und unten sind kein Thema), schöner wäre aber natürlich, die Ursache für diese negativen Auswirkungen zu kennen (das ist aber schwer zu analysieren, wenn man kein Profi ist).