RPI 3+ turn slow since openhab 2.1

RPI 3+ turn slow since openhab 2.1 and it’s much worse after 2.2,
basically CPU usage is around 30-50% during start up
speed is very fast on OH 2.0, in karaf you can see from the log, rules/addon/hardware config keep loading and usually finish loading in few minutes, after 2.1, it turns very slow, rules slowly read one by one on each can take up to 2-3 minutes on each rule files
and on 2.2, it even worse, after read the rules, hardware config read very slow

2.0 startup only few minutes
2.1 around 10-15 minutes
2.2 up to 30 minutes

Is there anyway can downgrade system back to 2.0? or speedup startup speed?

You can always install the older version of OH, though you might need to do a manual install to get back to 2.0. I don’t know if the apt repo goes back that far.

However, you will be stuck on the older version forever. Seems like it would be better to open an issue and try to help get the problem fixed.

I am also using a RPI 3 as openHAB server. And yes the Rasperberry is on hard work when starting openHAB. But there might be something you can do.
In my case I got some serious improvements by looking at my persistence strategy, previously I havn’t really thought about it, just saved everything… Not said that it is the same issue in your case :-). I have changed to use mapdb for restoreonstartup, where the other databases did grow over time, the mapdb database doesn’t as described here.

I also had issues with the OpenJDK, it ran awfully slow. I have changed to Oracle Java which also gave significant performance improvement in my case.The Raspberry where continously running at high load, and it didn’t seem to settle. After the change I don’t see this problem any more.

I am running on somewhat the latest nightly build (I thing #1177 or something)

I think Zulu has even better performance on RPi than Oracle. It is the officially recommended JRE in the OH docs and the JRE used by openHABian and the Docker image. OpenJDK is known to have some serious problems on the Pi though.

Great suggestion. It would be very interesting if this does end up being the problem.

1 Like

My RPI3 with Openhabian 2.2 and Mosquitto Broker runs at 7-8% average CPU load, peak maybe 15%. If you need 30-50% something is not ok, this is not normal.

okay, I think I report a wrong cpu value before, what I try to say earlier is cpu is not reached max,
below is chart for last 30 mins, usually around 9-15%

well in fact I got another issue with openhab2, few of the “thing” went offline after 2-3 days, restart openhab will be necessary, as issue only on specific hardware, will it be add-on bug?

HI,

I think I am currently running Zulu, detail can be read below, I have read the link you advised and I think it should not be my case as I should only running 32 bit version, also even it runs without hardware optimized, why will it be 10x slower than openhab 2.0 (only startup loading)

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (Zulu Embedded 8.20.0.42-linux-aarch32hf) (build 1.8.0_121-b42)
OpenJDK Client VM (Zulu Embedded 8.20.0.42-linux-aarch32hf) (build 25.121-b42, mixed mode, Evaluation)

Try this:

Maybe some rules are interfering with startup. I have a pretty large installation and it is up and running in about three minutes on my Pi3.

That is going to be specific to the binding and not a generic openHAB issue. Open a new thread tagged with the binding and provide as much detail as you can including configs and logs.

If you are runneing the Zulu openJDK you shoudln’t have any of these issues (I didn’t) - as @rlkoshak wrote.

But my point is still valid, there could be a lot of things causing the system to be slow. In my case it gave me quite some improvement to look at my persistence strategy. That is because I have just persisted everything.
You could also try to start and stop specific bundles, and see how it affects performance.
My general picture is that openHAB itself runs quite smooth on a Raspberry, but it all depends on your use. Once you know what is the reason it is much easier to find solutions.