OH3 UI Navigation Slow and/or Unresponsive

I’ve noticed that navigation within the OH 3 UI is very slow and sometimes unresponsive. I frequently get the below warning from Chrome stating that the page is unresponsive when trying to navigate to Settings or Developer Tools requiring me to frequently refresh the page. Is this a known issue or do I perhaps have a localized problem causing the UI to run extremely slow? I know there’s not a lot of info here, but if others are running a similar hardware setup with no issues navigating the UI, that answers my question. Thanks in advance.

4GB rpi4, openHABian 3.1.0.M2

image

I have similar issue. OH3 3.1.0M2 UI response slowly and consume a lot of browser resources.
However also Karaf login is sometimes very slow and log:trail output when connected to Karaf is slow as well.
Im running OH3 in a docker container. NAS CPU is 5% only and 30% RAM usage only.

How can I check which process is causing this?

There might be a context with the widgets you use on the pages. For example the weather-widget will produce some load, as it have to receive & render a lot of item states & images.

And the animation stuff is also demanding (which you could deactivate in the About & Help section) which might cause problems on slower machines.

Does this happen only on certain pages or is this a “overall”-behaviour?!

The problem I’m referring too is not related to the Widgets. The browser performance is indeed an issue, especially when working on MacBook with Safari and Widget Editor.
However, this is not the problem I’m pointing too - its more an overall issue.
Also pages with less content, like things, channels, etc. is sometimes loading very slow.
This is not related to the browser I think.
This is also impacting the performance when connected via SSH.

I had to delete the Dockers Container two days ago, and clear the cache in order to be able to connect to Karaf. Login to Karaf was so slow.
After running a new docker container it worked well. However, yesterday the login process was slow again. I had to wait about 20sec to get the password prompt.

It “feels” like a memory issue, which slows the application the longer it is active.

Thats why I’m looking for a command I can use for verifying the utilization of the different processes.
Not sure how I can do it - Using TOP on the NAS doesn’t show anything. As I said, the overall CPU and memory usage on the NAS is very low.

Any idea?

I just recognized a strange log entry. The openhab.log is full with such entries.
Maybe this is related to the performance issue, but not sure. The item name should be as followed:

Bewaesserung_Rasen_.....
Bewaesserung_Vorne_.....

However, in the log file the item name is scrambled.

openhab.log (32.5 KB)

I guess something is wrong :frowning:

i had the kind of the same. In my case it seems that whilst i am working on a widget and typing the system is somehow “storing” it temporarily. Looks kind of funny…

Generally i know if you working on a widget that does have direct items mentioned that are not yet existing, you get a log entry…

2021-03-29 16:47:32.801 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: i
2021-03-29 16:47:33.254 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: i
2021-03-29 16:47:33.254 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: it
2021-03-29 16:47:33.908 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: i
2021-03-29 16:47:33.909 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: it
2021-03-29 16:47:33.909 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: ite
2021-03-29 16:47:34.352 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: i
2021-03-29 16:47:34.353 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: it
2021-03-29 16:47:34.353 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: ite
2021-03-29 16:47:34.353 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: item
2021-03-29 16:47:35.696 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: i
2021-03-29 16:47:35.697 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: it
2021-03-29 16:47:35.697 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: ite
2021-03-29 16:47:35.697 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: item
2021-03-29 16:47:35.698 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: items

Hi Jan,

I use 4 times the same item names for my watering system.
The only difference is the word behind “Bewaesserung_” - it can be “Rasen”, “Vorne”, “Unten”, “Hinten”, followed by the different types.
I use the same custom widget for all 4 areas. However one control does only work in the first widget, but not in the other 3. (oh-input with datepicker).
I suppose that this strange log files are related somehow to this problem, but cannot really confirm this.

For me, this is more of an “overall” behavior. I do have quite a lot of items loading on the “Overview” page, but even after everything is loaded and rendered, if I try to navigate to the “Settings” or “Developer” pages, it will often take minutes and/or I’ll receive the “Page Unresponsive” error. Perhaps this is still an artifact of the system load caused by the number of items that exist on the “Overview” page?

your log seems to point in the direction that your widget has a problem with oh-repeater

hmm, i don´t have a repeater in my widget. I was editing a widget and adding a new item when the log “logged” that way as it did, almost like after every button i type saving in the background…

ok. this pattern in your log file has some logic behind:

... item which doesn't exist: i
... item which doesn't exist: it
... item which doesn't exist: ite
... item which doesn't exist: item
... item which doesn't exist: items