Your log shows you the symptoms of your problem, not the root cause.
As you saw in the other thread where other users had a problem with CPU being at 100%, it was not obvious to anyone in the beginning that the problem was a bug in JDK17 (which needs to be installed for OH4).
Maybe your problem has a similiar reason which we (including YOURSELF) need to find out. Maybe there is no problem and we might find out due to the changes of OH4 and the new system requirements (mainly JDK17 and buster) that a PI with 4GB is the new minimum requirement especially when using MQTT and Grafana. Who knows - we need to find out.
The majority of work in the beginning is on your side whereas the experts have the majority of work towards the end (bugfixing). What I want to say is that everybody has to contribute a little bit of work especially when there are problems with a new version.
You already got a few recommendations from experts in this thread above. Please go ahead and try to narrow it down so that the experts here have a starting point.
You said you do not have time to start analysing YOUR problem? But you already had time to write posts about your problem the last 7 days… (no offense - just realising)
I respect everyone spend time to develop and I respect everyone how try to help me for fixing and I’m really glad that Openhab exist! That isn’t the core of all. You just see me here not often, but via Facebook I help to try many guys there if I can in the German Group. If you don’t see me here in the first row, that doesn’t mean that I’m a parasite who only criticism the system! But if you tell me, that I sit here to switch all rules off (90 rules) and Bindings (Dunno 15 but 120+ things) step by step for an event that happens not often but it does twice or more, than sorry I’m out! How many days I’m need for this? Month? Meanwhile OH4.1 is out…
I don’t say that’s your problem, i say exactly that’s my problem and I can only hope that someone else get in trouble, too. If i decide that this is riding the horse in hell and it don’t make sens to me to invest more time in something that nobody can do! Also you must respect me.
BTW OH3 and OH4 looks very similar with RAM consumption… If I remember right I was also round about 700mb… But with OH3 I had a ZWAVE system with ZWAVE.me solution also running and everything was OK. OH3 runs also with Z2M, ZWAVE, Grafana, Influx and an apache2 webserver… Everything was nice. But now i get in trouble with OH4. In the meanwhile i decided to kill ZWAVE and switch over to z2m completely. With OH4 there is more RAM free cause I don’t use ZWAVE anymore.
All good Swen. You misunderstood - I am not complaining that you are not contributing in general. I am not complaining at all
I described one of potential approaches. But I would be interested to see how your system works if you disabled all rules which can be done easily through MainUI in one minute. Do you have access to MainUI at least shortly after a restart?
When upgrading from 3.4 to 4 did you follow the upgrade instructions so that the upgrade script was able to be run?
Yes sure. After update to 4.0.2-1 it looks more stable as before. But it would be nice to find the hick up also when I remove bindings and reinstall them. The DenonMarantz problem is yet fixed also what I get via SYSlog, but Openhab do the same issue after time.
Don‘t know if this had been asked before, but did you update your rules to use GraalVM and not Nashorn?
Also check the config for 3.x leftovers…
This one might be helpfull
Yes, sure that is next point what i do after upgrade. I had to fix all rules. And the system crash all over the time and rules are sooooo slow if they are started in the first time. Also And I thing, hey if i must touch all rules, I can convert them directly to get them up to date with the new GraalVM. The log is now cleare without issues of any rule hope for sure. I never comes over 24h cause of fix or try something with restart.
What are leftovers in config from 3.x? Did you have more details? Must I delete something?
Other Thread I will check. But all things are created by UI.
As Rich was already mentioning the swap file is quite huge. My total mem consumption is 740 MB. Your is 1.4GB.
Can you do a htop screenshot sorted by memory (without threads) and scroll down for a while until the next non-oh related command is shown, like this:
If you don’t want to spend a lot of time on this I think your options are clear.
Move stuff off of the RPi3 (e.g. InfluxDB and Grafana) to give OH more RAM to work with
Abandon InfluxDB and Grafana for something that requires less memory (e.g. rrd4j and MainUI charts)
Move everything to a machine with more RAM
Given the symptoms, any one of these should fix your problem.
Anything else is going to take a lot of time and effort and you still may end up with the same three options when you are done.
There may be some half measures you can use for the three options above. For example, maybe just close down Grafana and use MainUI charting. Research InfluxDB to see if you can configure it to use less RAM.
But as far as I can tell, the problem here is that everything you are running on this machine needs about 1.4-1.7 GB of RAM and you only have 1 GB of RAM. The only way to fix it is going to be reducing the amount of RAM required to 1 GB which is a huge reduction. I doubt you’ll ever be able to reach that through tweaks to configs and command line arguments.
Oh I’ve got that one memorized. ;-). $OH_USERDATA/config/org/openhab/addons.config
● dphys-swapfile.service - dphys-swapfile - set up, mount/unmount, and delete a swap file
Loaded: loaded (/lib/systemd/system/dphys-swapfile.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2023-08-16 15:17:12 CEST; 2 days ago
Docs: man:dphys-swapfile(8)
Main PID: 457 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 2176)
CPU: 0
CGroup: /system.slice/dphys-swapfile.service
Warning: journal has been rotated since unit was started, output may be incomplete.
@rlkoshak I don’t understand you again. Sorry… But I see 750mb ram is in use and only 296mb swap is in use exactly in this moment. I don’t see that is something wrong here…
If openhab stops then there is 172MB in use and swap is 154MB… So tell me please whats wrong with it? I can’t find the issue at the moment. If swap will be filled totally than there is a problem with Openhab or Openhab needs 2GB of RAM. Then all users will have problems to run Openhab 4 on Pi 3. That don’t make seens to me sorry.
If I roughly add up my CPU of all various commands I end up almost exactly with the 22% out of 4GB ~ 800MB which is inline with the memory bar of htop in the upper left corner (no surprise).
If I do the same with your system, I end up with ~84% out of 1GB = 840MB which is also fine, BUT swapon showed us that another 312MB are in use.
This is to me unusual.
Maybe you get some tools so that you can identify which processes are using swap file.
Yes then we end in openhab. But what i say… We talk about something what we don’t need really. We can talk about it, with the swap is full. What i say… I it doesn’t matter if swap is 400 or 800… Cause if the swap is so high openhab is running! We don’t need talk about… I don’t say Openhab isn’t running.
But there is a process depended with VM Thread what openhab blocked to working… It needs then 5-10mins and Openhab is working… And we must investigate this!
