[OH3] high cpu load, unresponsive OH

Hi all,

Since I’ve migrated to the stable version of OH3 in a docker on my Pi 3B+, the system (only OH3 container) becomes unresponsive after a few hours or if I do a lot of editing rules (part of the migration I move the text based rules to the new NGRE).


Also in the log I get time-outs of bindings (like iCloud or Unifi) and this message:
Dispatching event to subscriber 'org.openhab.core.internal.items.ItemUpdater@a79b69' takes more than 5000ms
I can’t access the MainUI, only restarting the docker container helps.

I found on the form a different posts, but they are either about OH2 or the beta’s/milestones of OH3.

Anyone experiencing the same?

Hi,

I’m experiencing the same! The lowest I cant get to on a RPi 3 B+ is a load average of 2 and above…

Rules load extremely slow (5min for a simple jython rule file with one rule).
Even when I let it calm down it won’t get better. Karaf console is also super unresponisve - I set karaf to DEBUG output but I don’t see much…

Here’s my /var/lib/openhab/config/org/openhab/addons.config:

[19:36:28] openhabian@openHABianPi:~$ cat /var/lib/openhab/config/org/openhab/addons.config
:org.apache.felix.configadmin.revision:=L"38"
action=""
automation="jythonscripting"
binding="hue,network,nest,zwave,astro,openweathermap,bosesoundtouch,systeminfo,chromecast,coronastats,pushbullet,miio,dwdunwetter,icalendar,nuki,mqtt"
legacy=B"true"
misc=""
package="standard"
persistence="influxdb,rrd4j"
remote=B"true"
service.pid="org.openhab.addons"
transformation="jsonpath,javascript,regex,map"
ui="basic,habpanel,habot"
voice="marytts,voicerss,googletts"

And shell:threads --list gives the top 20:

Id	Name	State	CPU time	Usr time
57	Dir Watcher	WAITING	159391	153480
14	Start Level: Equinox Container: 00b4dd77-4602-46bc-988a-67011f40d03e	WAITING	157955	154240
385	OH-scriptwatcher-1	TIMED_WAITING	65349	62220
293	OH-thingHandler-2	TIMED_WAITING	65164	59370
299	OH-thingHandler-4	TIMED_WAITING	63814	57410
267	OH-thingHandler-1	WAITING	62848	57000
296	OH-thingHandler-3	TIMED_WAITING	62341	56460
302	OH-thingHandler-5	TIMED_WAITING	61254	55300
97	features-3-thread-1	WAITING	60262	57610
387	OH-rulesRefresher-1	WAITING	51348	48620
110	SocketListener(openHABianPi-fritz-box.local.)	RUNNABLE	49647	47030
114	OH-eventexecutor-1	WAITING	43551	39870
4884	OH-rule-set-1-1	WAITING	36990	35920
240	OH-usb-serial-discovery-linux-sysfs-1	TIMED_WAITING	24182	16920
61	OH-OSGiEventManager	TIMED_WAITING	23337	20950
237	pool-14-thread-1	TIMED_WAITING	16872	14570
111	JmDNS(openHABianPi-fritz-box.local.).Timer	TIMED_WAITING	15490	13470
5518	OH-rule-temp-1-1	WAITING	13142	12860
128	upnp-main-2	RUNNABLE	12675	11330
3605	qtp15820476-3605	RUNNABLE	11882	11460
424	RXTXPortMonitor(/dev/ttyAMA0)	RUNNABLE	11310	5300
4866	OH-rule-roborock-1-1	WAITING	11046	10720
3598	qtp15820476-3598	RUNNABLE	10718	10100
4869	OH-rule-garden-6-1	WAITING	10509	10250
371	pool-21-thread-1	RUNNABLE	9719	8940

I have started deactivating bindings that I supect, but no luck so far…

Any advice would be welcome!

Thank you so much!

Edit: @ljsquare can you check if you also get this line when setting karaf to debug:

[DEBUG] [core.karaf.internal.FeatureInstaller] - Running scheduled sync job

I get it every minute and don’t know if that is normal…

I haven’t checked yet, but I found another post that describes my/our exact problem:

Thanks for the link!

I might have found a solution:
First of all, after stopping openhab, i overwrote the addons.config with the addons.cfg where only package=standard was defined. So the addons.config is now clear of any packages (it still had some 1.x bindings in the beginning).
Secondly, i found a file named:

/usr/share/openhab/addons/
openhab-addons-3.0.0.kar

Which i renamed openhab-addons-3.0.0.bak.
Then I cleaned the cache: openhab-cli clean-cache
After restarting openhab all your bindings will be gone, but I re-added them all and now it seems to be running smoothely.

My unqualified guess: Openhab got the addons from two sides at the same time, the kar file and the config file.

Hello,

I’ve got the same problem.
I did a clean install with the Openhabian v1.6.2 on a RPI4B.
I didn’t import anything and just starting from scratch.
The system becomes slower and even unresponsive after a few hours.

I read on an other thread that this issue was also found on the M2 and M3 builds.
The problem might be in the Rules, the seem to be parsed every time the run (don’t no if this is the case).
This could explane why a rule is taking a ‘long’ time when it is triggered.
I’ve seen that a simple rule can take 5 seconds.

I turned off my rules for now, for testing the effect.

I’ll post my findings later.

Best regards,
Edwin

Do you have your rules defined in the UI or via text files?

I’ve created everything with the new MainUI, also the rules.
Only the sitemap with a textfile because some options were not supported yet with the UI.

It seems that there’s a problem with DSL rules created in the UI:

Depending on how many rules you have you could try to put them in text files instead. Just until it’s fixed.

1 Like

Hello,

To confirm what was expected.
After I turned off the Rules in the UI, the system load stays 's low and resonsive.

I hope the Rule problem is getting a fix soon, for now I will be using my old rules files again.

Best Regards,
Edwin

2 Likes

Hello
I have the same issue. After a fresh install of OH with etcher & the openhabian image, with everything fresh inputted, all through UI, CPU load is at 100% (RPI).
However, disabling the rules I have, did not reduce the load.

Hi,

I still see this problem on my side too. Is there a solution meantime?
Fresh install on a RPI3, all items/rules/… are created over mainUI.
CPU is used 100% .

When I reboot the device than it works for some days and we see that cpu load is low.

best regards,
Lars

Are there any timers in your rules?

I ran into the same issue after using timers (all created in main UI).
had to reboot daily.

After removing those timers my system is running without higher loads so far :crossed_fingers:

Edit: after a few days high load & unresponsive OH returned and keeps returning in a 3 days interval

1 Like

More useful than “me too” would be try out the latest fix relating to UI entered rules.

1 Like

Hello! I have the same problem and really want to test this fix. But I’m not shure how. Could you writedown the instructions, or send the link of them.
Thanks!

The easiest way would be to install a Milestone development version.

Hi ! I’ve setting up a new Openhabian 3.1 Instance on a Raspi3+ and had the same issue. Now i could solve the problem for me. I’ve migrated text based rules from OH 2.5 and one statement in a rule causes the the unresponsive OH after a few hours.
The rule switches only a few lights, but when it’s fired a storm of event’s are looping and flooding the log. This was caused by a “postupdate” command for a item enabled for the openhab smart home skill, to control with the amazon echo’s (text based item defined as “switchable”. The “postupdate” for this item makes OH running wild and causes the high cpu load.

Hey Guys,

I have a similar problem. But I can connect without any problem/delay with Basic UI or openHAB App.
Is ist necessary ti cancel the rules is it enough to deactivated it?

Hi,

same issue on my fresh installation. CPU goes to 100% after some days but i don’t have a memory leak.
No rules are active.

Hi all,

since about one year I’m trying to set up an OpenHab 3 configuration in my garden house. As it is remote my possibilities to work on it is rather limited.

First I want to express that I’m really fond of the concept and the flexibility of OpenHAB. It is really great!

Unfortunately I’m facing annoying problems that limit my1 joy with it. As it mainly concerns the topic treated in this thread and none of the solution tips I found here and in other forums helped to overcome the troubles I decided to add my case here.#

First my hardware setup:

  • RaspBerry Pi 3B+ 1GB
  • ScanDisk Extreme 128GB
  • USB Stick 128GB (system)
  • Raspbian GNU/Linux V 10 (buster) build 5.10.60-v7+
  • OpenHAB 3.1 (stable)

Hardware connected to OpenHAB:

  • Trådfri Gateway
  • Hikvision DS-2CD2010F-I
  • Weather station WS980 WIFI
  • Trådfri Bulbs

In OpenHAB I’ve added the bindings below:

  • Astro V 3.1
  • Exec V 3.1
  • HTTP V 3.1
  • iCloud V 3.1
  • ipcamera V 3.1
  • Mail V 3.1
  • Network V 3.1
  • OpenWeatherMap V 3.1
  • System Info V 3.1
  • TRÅDFRI V 3.1
  • Z-Wave V 3.1

I’ve created two DSL rules.

To access OpenHAB I use the myopenhab cloud.

As described in this thread the Java process runs on 100% CPU load after about 6-9 hours. There is a cron job that stops and re-starts the OpenHAB service each day at midnight. Thus in the morning I’m able to access the MainUI but at about 9 AM I receive a gateway timeout and afterwards the myopenhab cloud reports that the server is offline.

According to the tips I found in the internet I disabled the rules, removed the items that access the image/video channels of the IP camera things.

One day I did not access the server at all (neither MainUI nor the admin page), one day I just checked the MainUI pages, another I did some modifications via the MainUI. But the result stayed the same loosing contact at about 9 AM When making modifications even earlier).

Furthermore I noticed that the used Ram increases after each re-start of the OpenHAB service. After reboot of the machine it is approx. 15-20% and after a week (re-starting each night) its ast about 50-60%.

Two questions come to my mind:

  1. May the reason for the problems be that the RaspBerry 3B+ with 1GB is not appropriate for the given configuration?
  2. Will OpenHAB 3.2 solve these problems (I read that at least the iCloud that started to report a communication error and the access to the IP camera image/stream should be fixed)?

I would be really happy if anyone could answer my questions or give me advice how to overcome this discouraging problems.

  1. Open your own new thread but only after tying the latest build.
  2. If your having issues, dont stay on an old build. UPGRADE to the milestone now or wait a week or two for the next 3.2 stable release.
  3. Ram always increases as Linux keeps it for cache reasons it is nothing to be concerned about.
  4. Always check your logs as often they will contain a clue that you can use to search the forum with.