Hi all,
Just for information, I figured out the main problem for my memory leaks : ipcamera addon.
The plugin was the cause of tons of threads, file descriptors and memory leaks.
Interresting command also in console : shell:info
I completly removed the bundle, waiting for a serious upgrade. Until this upgrade, I re-code all the stuff of the plugin in the rules …
Perhaps it can help someone else.
4 Likes
maybe @matt1, who is afaik mainting the ipcamera binding, can work together with you tracking down the issues you have noticed in the binding?
A lot has changed in the binding recently, upgrade to the 3.2milestone3 or use the even newer version of the binding which can work on 3.1 Stable and can be downloaded here:
Index of /openhab/IpCameraBinding/ (pcmus.com)
If you get dependency issues, just install the tellstick binding.
There is a post on the forum about the breaking change that this version brings as the serving is now done on port 8080 for all cameras.
Thanks @matt1 !
I will give it a try next week.
I understand that your jar is 3.2-snapshot that can work over OH 3.1-stable.
Yes it will work on 3.1 Stable, just need to be aware of the breaking change of the new URLS. You can run with it and when you upgrade to milestone 4 or 3.2 Stable just go back to the built in binding and you have dealt with the breaking change already.
I would like to post my experience here because I had the “out of memory” problem with my openhab2 (2.5.12-1) installation.
Optimizing the JAVA_OPTS didn’t do anything for me. Instead, however, I found the dependency on VisualStudio code and the extension to be the cause of the problem.
As Andrew said, one should disable the language server in the settings of the openhab plugin for VScode.
Hope this post helps others who end up here via a Google search.
The funny thing was, that it worked without any problems running openhab on virtualbox. Moving VDI to RAW and importing to proxmox and running there brought the problem. Strange.
2 Likes
OH 3.2… I had this problem. Disabling vscode language server seemed to fix it. Also, I got frequent openHAB crashes when using ctrl c to copy code. Disabling the server seems to have fixed that too.
1 Like
LSP-issue still persists with OH 3.3.0.M5.
Is anybody aware of any activity in solving this issue?
1 Like
This post ( above ) shows the registered issue on github. According to the tracker it doesn’t look like there would be any current activity.
Hello everyone,
I’ve been fiddling with my new installation of oh 3.3 for a while now.
Every time the system crashes after a certain amount of time. I am now monitoring my heap.
I have seen that java uses 100% cpu as root. Is that normal?
I also still face this issue
Okay but this doesn’t cause crashes? How long have you been running your system?
@jelmer1 Can you check what process this is that is running java as root? In my install (openhabian), openhab java is running as the openhab user, not root.
Try ps -ef | grep java
1 Like
@Kai - Can you create an official stacked post with listed clear procedures (also for non linux experts) for these annoing issue that many many many users still to have randomly in their OH life?
- How to give you right informations (like how to extract the JAVA thread dump)
- Is there something special to look inside on it?
- A list of the corrently known root causes that bring to cylcis crushes due to JAVA HEAP SPACE
I think at the moment this is the most annoying issue OH have…
Thank you in advance.
Nicola
Hi ,
Thanks for your replay @Mherwege .
that’s my output:
My heap is very stable and flushes.
my memory:
And my cpu.
uptime.
Can you guys give me any tips and help? So I can know what uses a lot of cpu? A specific binding?
Thanks!
@jelmer1 Could it be you have 2 instances of openHAB running, one as root, and one as user openhab? The root one got started at 9:13 this morning (the openhab one is running since yesterday). It is the root one that is at 100% CPU.
How can in see if there are two instances running? And can it be the carafe console that is not sealed?
@jelmer1 The karaf console indeed creates a second java openhab process. It looks then like it is an open karaf console, started as root, that is eating 100% CPU. I tried on my install. If you use openhab-cli console it will not create it as root (but user openhab). And in my case, having the console open does not spike the CPU to 100% (RPi 4). The process is also gone when I leave the console.
Process will run under the user that starts it. In case started as root then process is owned by root.
in case started by openhabian it is owned by openhabian but because of the length of the account name it is being displaced as openhab+