How to find what Function/Binding is using my (java-)Memory?

Since I upgraded to the most recent stable release, my setup is instable with Errors around java heap space. I have some details and screenshots here, although I don’t know where to address that.
Is there a way to find out what is causing that? first it was the sitemaps, but I have removed all those and it continues. I wonder if maybe a binding is causing that?
Is there a way to see what binding or function is using how much memory? I read something about a memory profiler , but I have no idea what I am doing. :slight_smile:

Than trial and error is going to be your best bet. Uninstall a binding, restart, and look to see if the memory stops growing. If not uninstall the next one and so on until the problem resolves. Then you will have your culprit and can file an issue.

can you point me to where I can see Memory Consumption?

10th column of htop.

Look into htop to see how to sort by memory usage.

Ok, so it just happened again and I started htop and I am confused.
It looks to me that I don’t have a memory problem but a cpu limitation, although the log indicates that java space heap problem.

I have killed that process which affected openhab to restart and everything is ok again. I cannot deactivate specific bindings as I cannot login into karaf, it is not responding

High cpu is probably caused by the java garbage collection running all the time trying to free up space on the heap/stack. Free memory is not the same as free memory in the java heap.

To see it and confirm do the shell:info command in karaf console.

Example of how is here:


  Karaf version               4.2.7
  Karaf home                  /usr/share/openhab2/runtime
  Karaf base                  /var/lib/openhab2
  OSGi Framework              org.eclipse.osgi-3.12.100.v20180210-1608

  Java Virtual Machine        OpenJDK Server VM version 25.232-b18
  Version                     1.8.0_232
  Vendor                      Azul Systems, Inc.
  Pid                         9503
  Uptime                      1 day 5 hours
  Process CPU time            1 hour 44 minutes
  Process CPU load            0.03
  System CPU load             0.04
  Open file descriptors       298
  Max file descriptors        102,642
  Total compile time          5 minutes
  Live threads                229
  Daemon threads              131
  Peak                        304
  Total started               174933
  Current heap size           264,116 kbytes
  Maximum heap size           358,400 kbytes
  Committed heap size         358,400 kbytes
  Pending objects             0
  Garbage collector           Name = 'G1 Young Generation', Collections = 2928, Time = 1 minute
  Garbage collector           Name = 'G1 Old Generation', Collections = 0, Time = 0.000 seconds
  Current classes loaded      20,081
  Total classes loaded        34,036
  Total classes unloaded      13,955
Operating system
  Name                        Linux version 4.15.0-88-generic
  Architecture                i386
  Processors                  2

Well, mine looks a little different than the one in the Binding-Thread when it comes to the “total started”. I will post another shot after another blackout, if occurs and possible.

Or can you already see something?
I have nothing else running on that VM, grafana, influx etc is on different VMs. I could just increase the XMS/XMX values I guess (currently, have 2GB Ram), but that is more like a workaround.

That depends on if you have a memory leak or if you simply need a bigger heap. If you have a leak, increasing the heap size will only mean it takes longer to fill up.

By running shell:info multiple times a few days apart you will see if the heap is growing and not getting freed back up.

I think the advice in post 2 is best to follow to solve your issue the fastest. Work out which binding when removed stops the high CPU usage, excessive threads or memory usage not sure which one is the indicator or cause of your issue and go from there. It may be disabling a rule solves the issue, it is a matter of turning things off to work out where the cause is located and then look at it with more info on how to fix it after the cause is known.

Thanks ! That post#2 is a little bit difficult as the problem does not occur predictably or regulary. Yesterday it did not happen for example. But it happened around 5 times now since I upgraded. So to follow post#2, I would have to disable bindings like shelly, that will deactivate my home, literally :smiley:
I will do so anyway, I will start with other bindings that do not cause so much trouble.

Would you think it would be worth an “feature request” to have some kind of ressource monitoring built into OpenHab, to see cpu/memory/time usage by binding etc?

Ok, I guess I found it! well… something! :slight_smile:
I realized that it only happens when I am on my “other” Computer. As visible here, I turned on that other computer at 16:15 or so…

to search for something in the logs

and openhab never recovered from that…

I used VisualCode to read the logs. I don’t really close VisualCode, so it is doing “something” in the background. Even with no windows/files open, it creates min. 20% CPU and fills the heap to 100%. And that increases the more I do. Search all files while changing some… and boom.

And I now found this:

I have not yet seen / realized those problems. But for me it looks like it is checking a lot in the background and I have never realized how many issues I have. Maybe this is new in OH2.5.1?

So anyway, For now, I have increased my heap and will work on those rule-errors I have.