Assistance with Performance Issue (Original)

Hardware Server
1

openHAB 5.1.3

Raspberry Pi 5

Ram 8GB

Openhabian Installation

Debian GNU/Linux 13 (trixie)

openjdk 21.0.10 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Debian-1deb13u1, mixed mode, sharing)

about a month ago I did a complete re-install of openhabian and restored the openHAB config file

I am having intermittent performance issues where all 4 cores are 100% and the system is incredibly slow

the Process consuming all all the resources is the openhab java process

The only way around this is to restart openhab

I have connected Visual VM to the system and below I have a thread dump to try to see which thread could be the cause but I really do not have a good idea what to look for

I do see a few threads that are blocked but that could be just the time when I ran the thread dump

java.lang.Thread.State: BLOCKED
   java.lang.Thread.State: BLOCKED
   java.lang.Thread.State: BLOCKED

any advice on what else I could look for

threadDump.log (682.2 KB)

2

Check this one, maybe it will help pinpointing which process is the cause

3

Thanks i missed that in my searches

4

Definitely look for some common problems with your config. In particular apparently the MQTT binding changed how it interprets the isCommand property. It now does what it says it does. However, that means it’s more likely to create infinite loops.

The isCommand property should only be ON in very rare cases where you need the messages to be sent as commands to the Item and an event Channel is not possible for some reason and there is no stateTopic configured. The configured stateTopic is where the loop comes in.

This would be the first thing I’d check.

5

Ok , thanks both used the previous mentioned command my mapdb seemed to be the problem but actually what was happening is my rrd4j persistence was having an issue with 3 files (it complained about the header being wrong. )

I deleted them and the system recovered.

I have since seen same conditions and fixed with same result (same item)

I have not yet excluded it from persistence because i want to debug when/if it happens again because it looks like there is a bigger persistence/multi threading/blocking issue at play but will create a new issue as needed.

I will mark this as solution for now.