since some weeks I have some trouble with my openhab system and the Java heap size.
Currently I use version 4.3.6, but it was the same with 4.3.5 and before.
After around three days the Java heap size grows till the 4GB of space are used and then the system crashes.
During the last days I disabled one binding after another and in the end I found, that the problem starts when the hue binding is active.
Because I had still the APIv1 running, but also some Hue devices with APIv2, I cleaned that up and now I’m only using the APIv2. But the problem is still there.
In the picture you can see the growing of Java heap usage and the timestamps I disabled the Hue binding.
Is there anythingknown or I can do to fix that issue?
Thank you!
Till now, nothing. No warnings or anything else.
There was also no change in my Hue setup since years.
If you tell me what to do, I can generate some logs or information.
Could you see what happens when you disable specific Things? E.g. start by disabling the Bridge thing; then maybe try disabling half of the Device Things. That might tell us if the issue is in the Discovery, or the Bridge, or the Device Things code. Just a thought..
You might consider setting the suspected binding log to debug then focus on what happens at the ~2:30 both am and then again at pm time frame it appears every 12 hours some activity kicks off then the heap climbs up based on your graph this seems to occur in a pretty defined pattern. Do you have some scheduled rule or other activity that takes action or checks statuses on devices supported by hue binding every 12 hours?
Yes, I will start the binding again in the evening with DEBUG level.
No, there are no scheduled rules at this time. Most stuff is not related to Hue devices in my system, so I was wondering that this binding causes some trouble.
I will respond again, hopefully with some useful logs.
Also have a look at the result of the threads --list to see if there is anything special concerning hue / clip2. You should see a handful of such threads, which is normal, but let is know if there seems to be an excess.
Also, picking up on the periodic step increase in heap size: do you have dynamic ip addressing on your system? Either on the Hue bridge or on OH. It is just a wild hypothesis but if you would have a DHCP ip address renewal on either side, then it might be at 12 or 24 hour intervals, and if that would cause the socket to drop, there might conceivable be some debris left behind. Static addressing is anyway preferable. This might also apply if you are using wi-fi which periodically renews connections..
jwiseman
(Mr. Wiseman (OH 4.3.7 Stable on Pi4))
10
My guess is that is when your app setting is set to update HUE devices. I know that time is what mine is set to.
jwiseman
(Mr. Wiseman (OH 4.3.7 Stable on Pi4))
13
In the HUE app, there is a setting to set the time for updates to apply to hue devices. When this happens, I’ve seen the bridges, 2 for me, go offline and cause havic in the morning for me. I usually have to restart OH when this happens. The comment about 2 30 am is that default time when hue checks for device updates and applies them.
No, DHCP is not there on all the devices. And there was also no change in the basic structure of the whole setup.
I read the thread about the heap dump. Will check that in detail tomorrow, if nothing useful comes around with the debug logging.
The time for Hue updates is a different one on my system. At 2pm in the afternoon. No idea why I set that, maybe because no need for light during the day…
Since the system is now again at >30% of heap size, I created the heap dump and put it into MAT.
It found a leak, this is the summary:
One instance of java.util.concurrent.ThreadPoolExecutor loaded by occupies 709.302.592 (74,94 %) bytes. The instance is referenced by java.lang.Thread @ 0x6c8801050 JmDNS pool-5-thread-1, loaded by .
The thread java.lang.Thread @ 0x6c8801050 JmDNS pool-5-thread-1 keeps local variables with total size 2.456 (0,00 %) bytes.
The stacktrace of this Thread is available. [See stacktrace](file:///C:/Users/Sven/AppData/Local/Temp/report6356153589892877139/pages/24.html).
It seems to be JmDNS related but based on your info it cannot be determined what data structure is consuming the memory.
Usually the denominator view shows in detail where all the data is exactly allocated. Using that someone can look at the code and see when data is added and when it is or should be removed. Usually there is a code path or some kind of exception causing the data not to be removed. I’ve also seen clumsy programming where data is only added and never removed.
Do you mean the dominator tree view of MAT? Hopefully yes…this is it:
It is not the end of the tree structure. But I gave up to show all of them. It goes on like what you can see here with that blockingQueue$Node entries.
Because the system is now at 60% I created another heap dump in case it is needed.
Stopped again the hue binding now and heap space dropped to 15% again.
