Please paste text in code fences, not screenshots.
Is there a particular reason you’re running a 3.2 milestone? I don’t know if that’s related, but for stability it’s best to stay on production releases, unless you absolutely need something that has been updated in a milestone.
Thanks for your feedback! Tried to save this post by not adding all the logging. Was not aware of the code fences option. I have changed it. I’am now traveling, will check my exact OH version tonight @ home.
Thanks for sharing! I have red the post, it is all OH2 related and to my opinion quite generic for OH2.
What I don’t understand, i have a basic installation of OH3, no strange or unsupported bindings. In above logging it say’s that the cammera binding was the route cause. Based on old logging (which i saved last crash) it say’s that the speedtest binding was the rout caus. I have installed the system binding and I’ll monitor the physical memory. Now, 24h after the reboot 18.8% of the system memory is used.
I believe that’s why one of the recommendations in the linked post is to turn off bindings. The camera and speedtest bindings are just the ones that triggered the error–they aren’t necessarily the root causes. It could be that one of them (or some other binding) is spiking your memory usage to 99% without failing.
FYI, I don’t think that post is actually specific to OH2. It’s just that people often referred to OH2 in the same way we now talk about OH3.
@wborn, do these old instructions you gave for a generating a heap dump still apply, or is there a newer method for Debian Buster?
Java does not use normal memory, it uses the HEAP. If you upgrade to the latest Milestone the system info binding can track the heap size for you.
When your having an issue, the first thing you should try is upgrading IMHO as the reason there is a newer version is because issues have been found and fixed. There’s no point reporting an issue in 3.1 if it is already fixed.
Thanks, Do i install the latest mileston by selecting ‘main’ in Openhabian version menu (so main in stead openHab3)? Or is openhab3 the latest Milestone (in the menu Openhabian version)?
There is a minor bug that is fixed in the next milestone due any day now. The bug will mean the graph is higher up the Y axis then it should be if the current heap is less than the max allowed heap. Dont worry if that is another language to you, just update to the next milestone when out and the graph it creates will still be useful.
you want a graph that stays horizontal and does not grow over time. Here is mine from the past week.
The heap grows in size until what is called ‘garbage collection’ is done and then it drops back down and keeps repeating this cycle. If you can see the heap growing in size, then it will help you to find the cause quicker as you wont need to wait 3-5 days for the error to occur.
I can already see it increasing. The sharp drop was the heap resizing bigger, next version the drop won’t show on the graph.
Now you need to press the pause buttons to stop things running to see what stops the upwards trend. It can be a rule that has an issue but I doubt it will be a rule as the increase is constantly occurring so it will be some code that is running all the time and not just an occasional run.
Have stopped all bindings. Below is the heap % of a day, per 8 hours the heap % goes up with 1%. Now i have started the MQTT broker with one import. Let’s see tomorrow what the effect is
Graph looks good but that is to be expected when everything is disabled. When you do work out which binding it is, also disable any rules that use that binding as it may be a poorly written rule that has stopped because the trigger for the rule never occurs when you disable the binding.