24 hours later… looks like that the hint from @matt1 and @mstormi did the trick…
memory usage since changing heap size and reboot yesterday is currently “stable” …
did no other changes since then… the items visibilty state in the android openhab apps
are more responsive also… at least most of the time…
a slight increase of memory usage is noticable… hopefully this will not result in a very slowly dead…
we will see…
what makes me wonder about this whole issue is… never had problems with heap size and memory before… using openhab since 4 or 5 years now… maybe because we moved into our new house and my environment growed over the last 1 1/2 years?
i will also try setting only Xmx as stated by matt1, reboot the server and will report back in about 24 hours
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.
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?
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.
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.
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.
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-create command. This may take several minutes when you run it on a Raspberry Pi.
Try adding EXTRA_JAVA_OPTS="-XX:+HeapDumpOnOutOfMemoryError" to your /etc/default/openhab2 file to get automatic heap dumps in case of an error.
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?