I didn’t add the reboot to prevent memory leaks. I added it out if general paranoia and the desire to have a stable system without fuss. It is something I do with most long-running processes.
Also, I stated I used systemctl to do the reboot, and it clearly, visibly, runs the shutdown scripts. I am surprised that a plain “reboot” does not, as it should be triggering systemctl as well. That difference seems unexpected and keeps me further away from zram, as there is clearly an unexpected risk there.
Do as you like. For me (as a Cloud architect/server engineer) and our customers that would be inacceptable, but you’re the customer here.
Well so was I and in fact learned meanwhile that I was at least partially wrong.
In latest openHABian, i.e. buster based, reboot/halt actually do trigger shutdown scripts, so that’s safe to use.
Well, as I said you’re the customer. But given that NOT to run zram is a well-known risk, too, I’d reconsider my decision if I was in your place.
I suggest to at least test to see if the issue still occurs in 2.5M2 before reporting in GH. There have been a lot of changes and fixes since 2.4… and IIRC the issue you reported has been addressed.
Last night, with the very patient help of @5iver, I managed to graph the current heap size. I’d previously had the java settings set to 3GB and 6GB:
EXTRA_JAVA_OPTS="-Xms3072m -Xmx6144m"
I reduced them to 1GB and 2GB:
EXTRA_JAVA_OPTS="-Xms1024m -Xmx2048m"
for testing.
This afternoon I noticed that the automatic lighting in the house had stopped working so I checked the heap size graph and saw that the java heap had grown hugely at 13:30:
I restarted the OH service at about 14:10. The strange thing is is that I can’t think of anything significant that occurred at 13:30. I’ve had a nose around openhab.log and events.log and didn’t spot anything obvious.
Maybe I could work on a rule that checks if the heap size has grown 50% above the average of the last 10 minutes and if so creates a heap dump? Does anyone have suggestions?
