Java Runtime Environment: _java version “1.8.0_221”
openHAB version: 2.4.0
Issue of the topic:
I have encountered that the camera stream is lagging on my sitemap, but it wasn’t since I set it up.
So I found out that CPU is on 100% when OH2 Server is running, that exact OH2 version ran on this PC for almost a year with 60% load max (except on startup it was 90% but that was normal).
In ttop I’ve found 4 tasks named qtp464142861 that had 1 hour or higher CPU time. Probably those are malfunctioning but I don’t know what are they. As they have so non-descriptive names that Google found nothing.
They are acting wierd, and not always up after a restart, so hard to trace.
I 've included some logs in the attached file. If anyone can point out which logs would tell more info, that would be nice.
Right now the system is usable with 60% CPU but daily it happens to go to 100% and stays there until i restart Openhab. So not sure if any of my rules are problematic but I doubt as I changed them on 18th August, and things on 15th October nothing later. (As i’ve read about high cpu at parsing rules)
CPU In task manager (aprox.) :
7% vlc rtsp stream
50% java (openhab)
1% UniFi Controller
2% Others
I am having no trouble with OH 2.4 on raspberry at Weekend House,
and I know some linux as well, Is the anwser repair the system or go to Linux, copy conf and write mqtt things in Studio instead of Paper UI (as i don’t know how to transfer them from Paper UI on this OH to another system, now it is also hard to backup .things as backup.bat throws an error).
[On raspberry i have also .things in conf and it is nice to bakup.]
If anwser is linux, I have no idea which distro to use to be light-weight maybe pepermint as I had problems with installing debian on some other PC…any better distro (with desktop for using on kitchen TV ocasionally).
They are “queued thread pool” threads that are used by the embedded Jetty HTTP server for handling Web UI and API requests. You can find more info on threads by using the threads command in the console. E.g. it would show something like this for the qtp threads:
"qtp945159566-108" Id=108 in RUNNABLE (running in native)
at java.base@11.0.5/sun.nio.ch.EPoll.wait(Native Method)
at java.base@11.0.5/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
at java.base@11.0.5/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
- locked sun.nio.ch.Util$2@3a165c18
- locked sun.nio.ch.EPollSelectorImpl@706b181d
at java.base@11.0.5/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141)
at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:466)
at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:403)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:360)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:184)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:135)
at org.eclipse.jetty.io.ManagedSelector$$Lambda$567/0x00000007c0915040.run(Unknown Source)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918)
at java.base@11.0.5/java.lang.Thread.run(Thread.java:834)
Maybe you have some phone/tablet/browser/script overloading your openHAB server with requests?
Thank you for the quick response and great explanation.
Now I am searching for differences between backed up OH2 from 3rd October and this OH2 that is problematic.
The backed-up version has lower CPU usage (min 6% max 45%)
I will carry on with .userdata, from backup and .conf from lastest OH2 to get new sitemaps… It is working fine… for now, if anything is still problematic, it will probably show up in a day or so, I will report then.
But i am not sure what caused that high qtp task CPU time, certainly wasn’t user device, maybe some misconfigured binding (Xiaomi waiting for server API response) ??
I have thrown wireshark in action and found out that VS Code on another pc that i had opened all the time was requesting all the Things and Items from the server every 500ms so i changed the refresh time in VS Code and the http traffic got under control.
I happened to eddit some python code in VS Code and haven’t closed openhab workspace in background.
So thanks for pointing out that HTTP server was overloaded.
