Xmx only increases the heap size limit so Java will not crash as fast (it does when heap size reaches that limit). But crashing is not your problem anyway, memory consumption is.
Xms preallocates heap space. The default is fine as long as you don’t run anything else large on the same box and yes you can decrease or omit it, too.
But that can result in delayed rule execution, the setting is there to avoid that.
i see … did also some reading about the java heap size settings…
but since my openhab setup is already a construction site i will try all options/possibilities offered 
again 24 hours later… back again 
currently the ram usage with Xmx512m setting is “stable”…
will then start to add some more bindings again and also reactivate some rules…
lets see what happens then
have a nice weekend!
cheers
hans
1 Like
You appear to have the same symptoms that I had, so I will not be surprised the same fix worked. For me it was an image channel that was causing it and just like it happened for you it was only when a tablet or app was open.
2 weeks later, still the same issue…
did again a lot of tests without success and decided to switch over running
basic ui in fully kiosk browser on the tables.
currently running my full setup since one week without any memory problems (except some button display problem in the dark theme (grey font on black background))
but as soon as i turn on the android openhab app(S) the fun begins.
no or sporadically refreshing of item visibilty and memory is filling up and
openhab crashes about 24 hours later.
in the meantime i don’t have the time and patience for further testing.
so for me the android app is not usable in that way.
maybe the problems are related to this issue.
this is the only info i got from the maintainer of the app in this post.
is there a chance for further investigation of this issue on development side?
thanks,
cheers
Hans
It is an openHAB core problem unfortunately. The android app uses the official REST web interface and apparently one of the called endpoints is leaking memory. The android app might just call that very frequently so it happens more likely.
Next to REST it could also be the mDNS library that openHAB uses (which is bad code quality). Everytime a network peer asks for “openhab.local” the mDNS library kicks in and tells the local network about openHABs IP address. Maybe the android app does this quite often.
Someone would indeed need to investigate that sooner or later, otherwise openHAB cannot be deemed as being long-run-time stable anymore.
Cheers
2 Likes
I assume that should be sooner rather than later.
But that would be you then. There are no free developers at the moment, because of the Eclipse smarthome reintegration and the 50 new bindings pull requests of the last 4 weeks (each > 1000 lines).
I can´t… I havn´t got the knowlegde.
I understand things are highly complicated atm with alot of stuff to do. But what worry me is, if ie. bindings has higher priority than this kind of problem?
A binding developer is a potential new core contributor and openhab is in need of more core developers ^^.
2 Likes
Each person is donating their time on what THEY see is important for getting their own system running. For me a binding is more important, but that will change as more of my hardware is operating.
Yes I see binding development as a way to play and learn before doing some bug fixes on the core to learn how it operates, and then move into adding new features to the core later on after I know the framework and how things operate under the hood.
1 Like
ok, i see… looks like that i will have to wait for a fix for this issue… as i already said… running basic ui in fully kiosk browser is an acceptable temporary workaround for me. sometimes missing the left nav bar and the dark theme … but the the main thing is that the system is running stable… which it does since i’m avoiding the permanent usage of the openhab android app.
thanks!
cheers
Hans
1 Like
Is there any news about this Issue and a fix - i am dancing the same problem with oh 2.4.0
1 Like
Same problem here. I’m using 2.4.0 stable version. Need to reboot every two weeks. It consumes approx 200 K per hour. I’m doing nothing complicated (some rules and mqtt).
2 Likes
I have the same problem with Openhab 2.4. After 2 or 3 weeks there is no more memory available and the system crashes on a raspberry 3. Is there a way to monitor the individual memory consumption of every used binding and the openhab core?
Using the Android App with the remote myopenhab URL to get notifications from openhab.
Unfortunately not. openHAB is a so called monolith in a single JVM (java virtual machine).
There were other reports about the Android APP already. Apparently it uses an API very frequently that causes leaking memory in core. The REST API part of openHAB uses a 5 year old unmaintained library, so that is actually quite likely.
When your system has been running for a while you could make a heap dump and analyze where all the memory is consumed with Eclipse Memory Analyzer Tool (MAT). If you configure the runtime such that it will always write a heap dump on OOM errors you can always analyze them after they just occurred. I am very interested in the results.
-
Create a heap dump from the console with the
dev:dump-createcommand. This may take several minutes when you run it on a Raspberry Pi. -
Try adding
EXTRA_JAVA_OPTS="-XX:+HeapDumpOnOutOfMemoryError"to your/etc/default/openhab2file to get automatic heap dumps in case of an error.
See also:
2 Likes
I use Visual VM to look for leaks whilst Openhab is running. You can see how fast the memory is used and trigger a Garbage Collection at any time to see what gets left behind. The graphs in this article are all from the Visual VM tool.
Ok, so yesterday it got me too.
I’ve created a dump with dev:dump-create and a ZIP got created. Then I downloaded Eclipse Memory Analyser Tool (MAT) for Mac but then it requested me to install the old Java 6 (WTF?) so I gave up.
Can anybody do something with my dump to get this memory leak fixed or should I keep it for security reasons?
Thanks,
Sascha
I have this issue too. I have never had an OH setup that was more stable that staying up for a few days - I thought this was normal!
I have a rule setup that warns me when available memory gets below a set point - I then reboot the pi (before it dies).
I find it difficult to understand how an issue like this has gone un-fixed for years (while at the same time claiming that OH is stable)!
I’m sorry that I don’t have the skills to help resolve this, but in my opinion, getting OH to be truly stable should be a priority.