Once more: 100% cpu after update

[Vetti52]

I have read the threads of Bartosz and those cited there but could not find a solution for my problem there:

After updating to weewx 5.01. without any flaws after a few weeks, when it got hot ouside, I realized, that my RPi4 had stopped working, because of getting too hot. After restart everything worked fine, until the temperature again rised over more than 60 °C. I checked with s-tui that one of the four cores remained ad 100%. Finally I found, that as soon as weewx generated the first record, the cpu usage was 100%. Now, I moved the RPi4 into a cool and dark room and leave the RPi case open, so that the temperature does not exceed 58 °C in average.

The latest update (and system upgrade) was yesterday.

My setup:

Raspberry4 with Bookworm, connected per LAN cable

Weewx 5.1 installed with Debian RPM

Ecowitt GW1000, driver 0.6.3

Skin alltimeSeasons with forecast extension

I replaced alltimeSeasons with regular Seasons skin, enabled debug = 1  and restarted weewx. Still the same result:

journalctl -u weewx

Aug 16 14:20:20 raspbee weewxd.py[4438]: historygenerator.py: Generated 5 tables in 0.20 seconds
Aug 16 14:22:49 raspbee systemd[1]: Stopping weewx.service - WeeWX...
Aug 16 14:22:50 raspbee systemd[1]: weewx.service: Deactivated successfully.
Aug 16 14:22:50 raspbee systemd[1]: Stopped weewx.service - WeeWX.
Aug 16 14:22:50 raspbee systemd[1]: weewx.service: Consumed 1d 21h 4min 31.966s CPU time.
Aug 16 14:23:09 raspbee systemd[1]: Started weewx.service - WeeWX.
Aug 16 14:23:16 raspbee weewxd.py[17471]: windy: version is 0.6
Aug 16 14:23:16 raspbee weewxd.py[17471]: windy: Data will be uploaded to https://stations.windy.com/pws/update
Aug 16 14:25:16 raspbee weewxd.py[17471]: historygenerator.py: Generated 5 tables in 0.21 seconds
Aug 16 14:30:18 raspbee weewxd.py[17471]: historygenerator.py: Generated 5 tables in 0.20 seconds
Aug 16 14:35:19 raspbee weewxd.py[17471]: historygenerator.py: Generated 5 tables in 0.20 seconds
Aug 16 14:40:21 raspbee weewxd.py[17471]: historygenerator.py: Generated 5 tables in 0.21 seconds
Aug 16 14:45:22 raspbee weewxd.py[17471]: historygenerator.py: Generated 5 tables in 0.20 seconds
Aug 16 14:50:24 raspbee weewxd.py[17471]: historygenerator.py: Generated 5 tables in 0.19 seconds
Aug 16 14:52:31 raspbee systemd[1]: Stopping weewx.service - WeeWX...
Aug 16 14:52:31 raspbee systemd[1]: weewx.service: Deactivated successfully.
Aug 16 14:52:31 raspbee systemd[1]: Stopped weewx.service - WeeWX.
Aug 16 14:52:31 raspbee systemd[1]: weewx.service: Consumed 27min 30.505s CPU time.
Aug 16 14:52:54 raspbee systemd[1]: Started weewx.service - WeeWX.
Aug 16 14:53:15 raspbee weewxd.py[18570]: windy: version is 0.6
Aug 16 14:53:15 raspbee weewxd.py[18570]: windy: Data will be uploaded to https://stations.windy.com/pws/update
Aug 16 14:55:15 raspbee weewxd.py[18570]: historygenerator.py: Generated 5 tables in 0.20 seconds
Aug 16 14:57:33 raspbee systemd[1]: Stopping weewx.service - WeeWX...
Aug 16 14:57:33 raspbee systemd[1]: weewx.service: Deactivated successfully.
Aug 16 14:57:33 raspbee systemd[1]: Stopped weewx.service - WeeWX.
Aug 16 14:57:33 raspbee systemd[1]: weewx.service: Consumed 2min 22.493s CPU time.
Aug 16 14:57:33 raspbee systemd[1]: Started weewx.service - WeeWX.
Aug 16 14:57:40 raspbee weewxd.py[18714]: windy: version is 0.6
Aug 16 14:57:40 raspbee weewxd.py[18714]: windy: Data will be uploaded to https://stations.windy.com/pws/update
Aug 16 15:00:20 raspbee weewxd.py[18714]: historygenerator.py: Generated 5 tables in 0.20 seconds
Aug 16 15:05:22 raspbee weewxd.py[18714]: historygenerator.py: Generated 5 tables in 0.21 seconds
Aug 16 15:10:24 raspbee weewxd.py[18714]: historygenerator.py: Generated 5 tables in 0.18 seconds
Aug 16 15:15:25 raspbee weewxd.py[18714]: historygenerator.py: Generated 5 tables in 0.19 seconds
Aug 16 15:20:27 raspbee weewxd.py[18714]: historygenerator.py: Generated 5 tables in 0.19 seconds

(No success to formate the pasted lines above into Courier, sorry)

No idea, where else to look at now. My intention now is, to install weewx on my other RPi5 from the scratch, and move the two databases (weewx.db and forecast.db) over and reestablish alltimeSeasons and forecast afterwards. 

So, is it possible to maintain weewx on different stations simultaneously? Would my approach work like that? Or should I first search for the cause for 100% CPU load?

[vince]

Check your weewx.sdb file first if it was originally on a system running weewx v3 or earlier.

As the other thread and multiple other ones have indicated, there 'is' a change in v5 that calculates elements present in a skin that are not in the db schema.  Typically this is appTemp but there are others.  This typically occurs for sites that started in weewx v3 or earlier.  New sites that started at v4 should not see this issue usually.

Check your schema to see how many elements are in your actual db schema.   The big wview-extended schema that is the default in v4 and later will return 114 for the following command.  The original wview compatible schema used in v3 and earlier will report a number around 50 or so (I forget the actual number).

# use the full path to your db below

# or cd into the archive directory before

# running the following command

echo ".schema" | sqlite3 weewx.sdb | wc -l

[Vetti52]

Sorry, I did not mention earlier, but I checked the schema count long time before, when changing to the new db schema. Yes, it is 114.

But before I could check, I had do install sqlite3, which was not installed in bookworm lite yet. weewx (or python) does not seem to need this package by itself.

Then, before doing the apt update/upgrade, I had to remove the old style gpg key and install the new one

wget -qO - https://weewx.com/keys.html | sudo gpg --dearmor --output /etc/apt/trusted.gpg.d/weewx.gpg

Same with the bookworm reposities gpg key accordingly.

Then I did, as mentioned in the other thread, check calc-missing only. Dont know, if I should check all the others mentioned there, such as appTemp.

weectl database calc-missing

and finally I checked for the amount of the 114 values, as you showed above. However, I had to do it as

sudo echo ".schema" | sqlite3 /var/lib/weewx/weewx.sdb  | wc -l
Maybe, there is a problem with my user rights settings?

Tanks

Peter

[vince]

I don’t know. At this point all I can suggest is trying to determine if your db is the reason or not. 

If you can set up your second pi, install a new os and weewx using the Simulator only and get that working (without any uploaders enabled). Then scp your db over and restart weewx and see if it breaks anything. The initial run will take a few minutes to build the NOAA files but the archive runs should be very fast afterward.

That will at least tell us if your db is ok.

[vince]

Brief update - I had the user make his db available to me and it's fine on both mac and raspi platforms, so the issue seems to be something in his os+weewx setup.....

[Vetti52]

My brief update:

Today I have installed weewx on my new Rpi5 from the scratch. Then I copied the weewx.db from the old Rpi4. I also installed alltimeSeasons manually (which would be nice to be integrated into the Seasons skin more easily). Thus, although using historygenerator.py again, everything works fine, no detectable cpu load so far. I hesitate to install forecast, which uses it‘s own database. But I think, that was not the reason, because the 100% cpu happened without using forecast as well.

Thus, it might remain an unresolved black box issue.

BTW, at the Rpi4 journalctl only historygenerator.py is listed every 5 minutes. In the new Rpi5, there are now listed cheetahgenerator and imagegenerator as well. At least concerning the journalling there are differences between both setups. No idea, how this happened.

Thanks anyway

Peter

[vince]

In the absence of debug=1 logs, best of luck.

As always, run with a 'clean' db and just one skin (pick one, Seasons or Standard) to stabilize your installation with a known reference point before adding your tweaks and additions and real db.  That's the only way we can try to replicate your setup if it comes to that.

[Vetti52]

as starting with a clean installation on my Rpi5, there was no indication for debugging. In parallel I monitored the activitation with s-tui, especially for cpu load/temperature and fan speed. So I started with simulator modus, then installed gw1000, all of it without any increase in cpu activity. Next day, I did the adoption of alltimeSeasons, as this needs to be installed completely manually. By this way, I had to correct two gw1000 specific entries, concerning the transmitter battery and the sun irradiation, both of them were empty. I transferred both entries from the old Rpi4 conf file to the new one, again without any change un cpu usage. Finally I installed windy upload. Still no problem. So, the only two things, I did not install, is forecast and cpu-temp. The latter, however, raised some cosmetic trouble as the data were collected in extraTemp1, which is now used by a meanwhile installed barn sensor for temp and humidity. I should try to delete the old data for cpu-temp, because it looks crasy, when temp was about 50 °C and now dropped to 10 °C.

As I monitor the two Raspis now in Home Assistant, I will not install this feature in weewx again. Concerning forecast, I am still thinking about.. Still, I doubt, that this is the cause for the high cpu usage at the Rpi4.

Before I decide this, I could use the Rpi4 installation now for testings. Maybe it is a good idea to remove one part by the next of all the additions, and look for effects on cpu load? Currently I have simply stopped the old Rpi4 weewx service, being glad, that the new one works fine now.