openHAB on Raspberry Pi freezes for a couple of minutes

This is what I also thought of. I’m using the official power supply (2.5A) but I have tried another official one. Same behaviour. And I also didn’t think of any hardware problems, because the other RPi where I ran OH before for testing, now runs Rapsbian with services running on it constantly without a problem…
I also think that htop is more reliable, but if I just rely on the numbers that htop shows, it would seem that nothing is wrong with it, the CPU usage and everything is the same there as before. However for even htop needs minutes to load if I can even bring it up…

Well, CPU is only one thing that can cause symptoms like this. Are you connecting over the network or physically with keyboard, monitor, and mouse?

Have you looked in syslog to see if something weird is going on?

Yes I think that - as stated in the 1st post - I/O handling and interrupt handling causes this, when lots of concurrent things happening (also inside openhab and “outside” of it), but I can’t make myself sure about this.
No there is no device connected to it, I can only access it through ssh.

It would be useful to see if the device has the same slowdown problems when connected to physically rather than through the network, given that the problem could be network related as well.

And how should I do that?
I mean I can easily remove the network from it, but then I couldn’t make sure that network causes the issue. Because that way most of the things which happens on this Raspberry is driven by network (polling device states, sending commands, running python scripts which polls other devices status, etc…), so I would also assume that the average usage will drop because there will be no traffic which needs to managed/controlled.

Don’t remove the network, but physically connect a monitor and keyboard and when trouble shooting the problems rather than going through the network to do it. At this point you can’t really tell whether there is a real slowdown on the machine or the network is throttled and everything just looks like it’s running slow.

Ah I get it!
However this seems to be done before. I also ran before Kodi on this device as well. First I thougth that I couldn’t handle Kodi and openHAB together (and Kodi also seemed to cause this) so I removed it now. But before I have used it with Kodi on it (which was a TV connected to it through the HDMI port) and Kodi also stopped when this slowdown happens.

Might be the java garbage collector. You should restrict cpu and memory of all java processes to 80% (rlimit), that way your ssh connection stays stable at least if java starts doing strange things.

Thanks I have never heard of this! I will try that (at least for testing it with this).
Do you have an example how I could do this without modifying the source code?

My guess would be it’s paging (swapping).
Check out my hints on optimizing swap here.
A patch to add zram compression is in the pipe for openHABian.

How a zram compression can help on this?
However you might be right. Initially I had to increase the swap size in order to function properly. Before this the problem was that there were no enough memory (not even in swap) and Raspberry got stuck (like a deadlock…).

It’s compressing RAM, effectively doubling it at a (minor) cost of CPU.

openHAB with java params from openHABian alone does well fit into 1GB w/o swap so you must have done something else on your system.
I’m using EXTRA_JAVA_OPTS="-Xms250m -Xmx350m" in /etc/defaults/openhab2.

And if you’re running additional programs consuming a lot of memory on the box (Grafana ?) it might be too much. Better move them to a different box.

Yes for me it won’t fit… It uses almost every available RAM (swappiness 60) and also uses around 500MB swap. I should move my system to a reliable server…

Maybe we can find the memory abusing binding / addon instead. The problem with a garbage collected language like Java is, that code that rapidly creates objects (but also frees them, so not a memory leak per se) will exhaust vmem. Most of the time there are coding patterns to avoid this.

Yes I know these, I’m also a junior Java developer :slight_smile: But I forgot these in this scenario. I wouldn’t say that there is an addon which uses this much RAM or more as it should. The RAM usage is constant. The problem might be that I’m running lots of little services on a single RPi (openHAB, Grafana, Node-RED, and not a few other “connectors”, mainly python scripts…).

Which is not recommended. Running some script services in addition to OH is ok, but at least Grafana (+ InfluxDB I assume) is not “little” but a memory hog.
You’ve created that situation by yourself by overburdening your HW. Move services off to another box or accept you need to live with the freezes.

I’m using MySQL which is on another server.
However thanks for your help, this is what I’ll do!

Try zram first. May or may not be sufficient.

It’s really time for a PI with 2gb ram. Most of the time it’s not CPU that’s limiting. I wonder if the Homeassistent guys manage to squeeze python and grafana on a Pi.

That’s a good question, especially since hass.io, if I understand correctly, loads everything in containers which should require even more memory.

I agree, if they produced an RPi with 2gb ram and at least USB 3 I might replace my server with Pis. For most stuff the CPU isn’t the problem, it’s the RAM. And the lack of USB 3 is there only thing holding it back from being a good NAS platform.

1 Like