Memory usage

Openhab 2.5.11
Ubuntu 20.04.1
Seems like in Jan/Feb something happened; my average RAM doubled; it’s all mainly under Java/Openhab. Any ideas how to track down what is causing this?

Thanks

Since there was no update of openHAB, did you update Java or anything else on that system?

In general, a service like openHAB or a browser and the like consuming lots of memory is not necessarily a problem unto itself. RAM is fast so many such programs are designed to use as much of it as they have a use for without causing impacts to the rest of the system.

So if this use isn’t actually causing real problems (services crashing, excessive use of swap, etc.), then don’t risk breaking something by changing things now.

To really nail down the problem you’ll need to identify exactly what changes in January. You are not even running the latest version of OH 2.5 so nothing has changed with the actual code you are running in OH. If OH is now consuming more memory, it’s not because of a change in the software. You have to look outside of OH itself.

Did you change a configuration? Upgrade the OS via APT?

Even if you didn’t touch anything at all, stuff outside of your control may have changed.

If you plan on continuing to run with an old and no longer supported version of OH, I highly recommend touching nothing. Change nothing. Don’t even run upgrades on the base OS. Even a minor change could break something and since 2.5.11 is no longer supported all we can recommend is to upgrade. The longer you wait to upgrade, the more work it’s going to be.

So, if this memory use is really a problem, then you have pretty much already reached the point where you have to upgrade. There really isn’t much we can do to help and even if we find a problem in the code, you’d have to upgrade to get the fix. It might be something that is already fixed.

2 Likes

I think addition of items/things can affect memory usage. And in particular based on some addons.

With no openhab version changed, I started getting restarted, and it was java heap memory and a the docker memory limit that I started hitting. I had to increase from 1.7gb to about 2.5. All that would have changed would have been the use of more things (mqtt based, hand coded) for zigbee2mqtt etc.

Thanks, appreciate the feedback.
Ironically, i don’t change anything/update anything.
I’d still be on a way older version of openhab if I didn’t have to scramble last year once the ecobee binding changed b/c of the auth change…otherwise i’d still be on an older version.
I usually build it up, get everything i want on it working, and leave it…i dont’ upgrade the OS, OH, etc…otherwise, you’re right, you start chasing lots of problems with all the variables that could have changed.

This just puzzles me; since i didn’t change anything, the RAM has basically doubled in use…you’re right, it’s not “causing any problems”; though I wonder if this has something to do with my other problem yet to be solved(slow emails going out over the last 6 months).

Thanks; yes i have added a few extra zwave devices…not many; maybe 3 or so to the system. No other “things” though other than that.

No i have not; least that i know of. I am the type of person that gets it all working and leaves it alone. Updating things tends to cause headaches :slight_smile:

But that was a configuration change. When we say you can’t change anything, that means OH config too. Did you add those around January?

It’s probably worth noting that not updating things also causes headaches. It just causes a far bigger headache and you have no control over when that headache will occur since, as shown here, things will change outside of your control which could break things and the longer you wait to upgrade the more chance things will break in the upgrade and the more work it will be to apply it. In short, not upgrading just saves up the work for later, it doesn’t eliminate it.

It also leaves you vulnerable to sometimes quite severe security vulnerabilities so even if you don’t ever update or change anything, you still must put in effort to mitigate security vulnerabilities as they arise in the software you use and the host OS. Not doing so would be like driving your very expensive car to the worst part of town and not even locking the doors after parking it.

For example, I don’t think you’d have the patch in OH for the recent log4j vulnerability which was given the highest rating (meaning the most dangerous) possible. So you’d have to mitigate that problem in other ways (e.g. disconnecting OH from myopenhab.org and not allowing OH to access nor be accessed by anything outside your LAN). With this vulnerability someone could craft a specially formatted string which will give them access to your machine. There were reports of people changing the names of their Tesla cars or iPhones and showing they could gain access to Tesla and Apple servers.

1 Like

You possibly have a binding with a mem leak.
Do you dynamically download bindings ?
Fetching addons from the remote repository (remote=true in /etc/openhab/services/addons.cfg and the corresponding UI setting) is the default in OH so that might go unnoticed on a restart.

This!
Your basic approach “I just need to get back to the software state where everything worked then everything will work again” won’t work. Whatever it was, something changed.
But even if you identify a change of relevance, undoing that might still not fix your issue. There’s still just too much going on left to potentially affect your setup.
I suggest you upgrade to latest 2.5 to see if the problem persists before you proceed with identifying the binding that has the mem leak.

1 Like

I don’t that will work in 2.5.11, due repository changes
BUT
cycle of fail/retry could be a resource hog, so a good observation.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.