Java CPU 100% on 1 core

I am using OH3 version 3.3 on openhabian platform (RPi3).
Using only few bindings from original source.

I found recently that the system was not responsive and was very slow especially in the webpage display, iOS app, etc.

So I checked the CPU usage using top and htop and found that the RPi was using only 1 core and using it at 100% (even over 100% sometimes). The process using this CPU time is “java” with user “openhab”. But the core used is not always the same one. It changes over time.

Due to the high CPU usage I am not even able to access the karaf console.

I also noticed in the past that after a while the unit just freezes and stop responding at all.
So, I don’t want to reboot it as I want to find the root cause.

How can I track down what is causing this CPU usage?
How can I see how much CPU is using a specific binding?
Why is openhab using only 1 core?

Any help will be appreciated.

Now I am getting these error messages in the log:

2022-12-29 11:30:00.467 [WARN ] [] - Dispatching event to subscriber 'org.openhab.core.internal.items.ItemUpdater@ca3cb0' takes more than 5000ms.

2022-12-29 11:30:18.026 [WARN ] [] - Dispatching event to subscriber 'org.openhab.core.internal.items.ItemUpdater@ca3cb0' takes more than 5000ms.

2022-12-29 11:30:49.015 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.

2022-12-29 11:31:46.338 [INFO ] [ternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online

2022-12-29 11:31:46.342 [WARN ] [] - Dispatching event to subscriber 'org.openhab.core.automation.internal.module.handler.GroupStateTriggerHandler@1c6836e' takes more than 5000ms.

2022-12-29 11:32:17.136 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.

2022-12-29 11:32:34.537 [WARN ] [WaveSerialHandler$ZWaveReceiveThread] - Exception during ZWave thread. 

java.lang.IllegalStateException: Queue full

	at java.util.AbstractQueue.add( ~[?:?]

	at java.util.concurrent.ArrayBlockingQueue.add( ~[?:?]

	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.processReceiveMessage( ~[bundleFile:?]

	at org.openhab.binding.zwave.internal.protocol.ZWaveController.incomingPacket( ~[bundleFile:?]

	at org.openhab.binding.zwave.handler.ZWaveControllerHandler.incomingMessage( ~[bundleFile:?]

	at org.openhab.binding.zwave.handler.ZWaveSerialHandler$ [bundleFile:?]

2022-12-29 11:33:00.780 [WARN ] [] - Dispatching event to subscriber 'org.openhab.core.automation.internal.module.handler.GroupStateTriggerHandler@1b8b098' takes more than 5000ms.

Here more recent error messages:

2022-12-29 12:10:16.103 [INFO ] [openhab.event.ItemStateChangedEvent ] - [FAILED toString()]

==> /var/log/openhab/openhab.log <==

2022-12-29 12:02:28.228 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.util.concurrent.RejectedExecutionException: Queue capacity exceeded

	at java.util.concurrent.ForkJoinPool$WorkQueue.growArray( ~[?:?]

	at java.util.concurrent.ForkJoinPool$WorkQueue.lockedPush( ~[?:?]

	at java.util.concurrent.ForkJoinPool.externalPush( ~[?:?]

	at java.util.concurrent.ForkJoinPool.externalSubmit( ~[?:?]

	at java.util.concurrent.ForkJoinPool.execute( ~[?:?]

	at java.util.concurrent.CompletableFuture.asyncRunStage( ~[?:?]

	at java.util.concurrent.CompletableFuture.runAsync( ~[?:?]

	at com.qubular.openhab.binding.vicare.internal.VicareDeviceThingHandler.handleCommand( ~[?:?]

	at com.qubular.openhab.binding.vicare.internal.VicareBridgeHandler.lambda$featurePoller$0( ~[?:?]

	at java.util.concurrent.Executors$ ~[?:?]

	at java.util.concurrent.FutureTask.runAndReset( ~[?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]

	at java.util.concurrent.ThreadPoolExecutor$ [?:?]

	at [?:?]

2022-12-29 12:11:17.546 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.lang.OutOfMemoryError: Java heap space

2022-12-29 12:11:21.932 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.

2022-12-29 12:11:35.006 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller

2022-12-29 12:11:35.010 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.

2022-12-29 12:12:05.493 [WARN ] [] - Dispatching event to subscriber '' takes more than 5000ms.


I had to reboot the RPi and magically the CPU load decreased, the system returned responsive, etc etc.
As it happens frequently (every month or so) I need to understand what is going on as this behaviour in a domotic system is dangerous.

Any one can help?

Something seems to be causing a memory leak. Once the memory is full many strange things happen. I use the systeminfo binding to monitor the memory allocation, both total memory and java heap space. You may be able to guess what’s the cause by removing some items or bindings until the memory leak does not happen anymore.

Hi Lionello,
a memory leak should not happen in the certified bindings activated from inside OH, as they are checked by the developers, right?

So where the leak could happen?

Developers cannot test all possible user’s configuration. I’ve seen in the past several threads about memory leaks for some bindings.
There have been threads reporting problems with zwave (e.g. this one)

I understand, but my OH3 fails sometime after a month, sometimes after 3 months.
How can I check all the bindings with this timeframe?
Any suggestion?

Hi Lionello,
after restart, I have

  • usedHeap=60%-91% (working smoothly)
  • available heap=30-120MB
  • memory available=189MB

what should be the threshold for an alarm on the usedHeap?

The out of memory also could be collateral damage. If data is received but can’t be processed queues can increase in size and cause the system to run out of memory. At least that is what I’m reading in your logs. It can be binding locks the shared scheduler causing other bindings not be able to process data, or even the binding itself.
In your log I see an unknown binding com.qubular.openhab.binding.vicare that also reports it’s queue is full. It could be this binding is blocked, either due to an other binding blocking or the binding blocking itself, while still receiving data and eventually causing it to run out of memory. (Or the queue running full is happening in the zwavel binding). A way to check if threads are blocked can be done in the karaf Console :

threads --monitors --locks

thanks for your reply.

Karaf was not accessible unfortunately.
When I tried to login Karaf, there was a timeout.