[ERLEDIGT] FHEM wird nach Neustart nach und nach träger (Load geht nach oben)

Begonnen von M.Piet, 01 Oktober 2024, 08:06:14

Vorheriges Thema - Nächstes Thema

M.Piet

Hallo Zusammen,
ein seltsames, für mich nicht greifbares Problem habe ich seit kurzem.
FHEM wird nach einem Neustart immer mehr träge und Load geht nach oben. Es scheint (wie man am Screenshot sehen kann) Schrittweise zu passieren.

Gemerkt habe ich es, weil in FTUI oft Sachen nicht (oder nur sehr lang) geladen haben und immer wieder Meldungen vom PRESENCE-Modul kamen, dass Geräte Offline sind. In den Logs auch gut zu sehen, dass es zu Timeouts kommt.
Weiter ist die CPU-Temperatur auch viel höher, als sie sonst es war.

2024.09.29 07:28:33 3: DS2438_DCDE84000003: reading VAD did not return a value
2024.09.29 07:28:33 3: DS2438_DCDE84000003: reading VDD did not return a value
2024.09.29 07:28:34 1: Timeout for PROPLANTA_Run reached, terminated process 3063
2024.09.29 07:28:46 3: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 3225
2024.09.29 07:28:46 3: PRESENCE (AP_Scheune) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2024.09.29 07:28:46 3: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 3226
2024.09.29 07:28:46 3: PRESENCE (AP_Dachgeschoss) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2024.09.29 07:29:26 1: Timeout for SYSMON_blockingCall reached, terminated process 3259
2024.09.29 07:29:40 3: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 3291

Auch die 1wire Kommunikation macht zunehmend Probleme:
2024.10.01 07:21:10 3: DS2438_DCDE84000003: reading VDD did not return a value
2024.10.01 07:21:10 3: DS2438_DCDE84000003: reading temperature did not return a value
2024.10.01 07:21:28 3: DS18B20_DBDE84000003: reading temperature did not return a value
2024.10.01 07:23:12 3: DS2438_DCDE84000003: reading VAD did not return a value
2024.10.01 07:31:26 3: DS2438_DCDE84000003: reading VAD did not return a value

Da belegen ein paar Prozesse ganz schön viel CPU-Last.
Jemand eine Idee, wie ich der Ursache auf die Schliche komme?
Soll ich noch ein paar Logs posten?

Vielen Dank für die Hilfe!


tomcat.x

Hm, wenn ich mir den Speicherverbrauch ansehe, hast Du vermutlich außer fhem nicht viel oder gar nichts darauf laufen. Aber was sind die vielen python Prozesse?
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

M.Piet

Richtig. Eigentlich nur FHEM und für 1wire der OWFS.
Aber leider habe ich keine Ahnung, warum so viele python Prozesse da sind. Wie komme ich dem auf die Spur?

MadMax-FHEM

Zitat von: M.Piet am 01 Oktober 2024, 09:01:46Wie komme ich dem auf die Spur?
Hast du z.B. fhem Module in Betrieb, die "unterlagert" python nutzen, z.B.: https://forum.fhem.de/index.php?topic=115230.0

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

M.Piet

Zitat von: MadMax-FHEM am 01 Oktober 2024, 09:07:17
Zitat von: M.Piet am 01 Oktober 2024, 09:01:46Wie komme ich dem auf die Spur?
Hast du z.B. fhem Module in Betrieb, die "unterlagert" python nutzen, z.B.: https://forum.fhem.de/index.php?topic=115230.0
Wüsste nicht, dass ich sowas mal mit eingebaut habe.

Der Fehler ist auch erst seit ca. 1-2 Wochen da. Ich habe in der Zeit nichts verändert, woran ich mich so erinnern kann. Schon gar nicht was in python.

MadMax-FHEM

Zitat von: M.Piet am 01 Oktober 2024, 09:11:11Wüsste nicht, dass ich sowas mal mit eingebaut habe.
Naja, eingebaut.
Wenn das python mal installiert ist, sind es "danach" auch nur fhem Module/Devices...

Was "sagt" denn:
update list
im Fhem-Web-Eingabefenster?

Die Fehlermeldungen sehen fast alle nach "Netzwerk" aus?
Und v.a. nach "forking" -> es werden Prozesse im Background gestartet -> Speicher, CPU, ...
Und einige (alle) werden mit Timeout abgebrochen.

Dabei sind eben z.B. ping -> PRESENCE?
PROPLANTA
SYSMON
FRITZBOX
...

Wenn du auf dem fhem Rechner bist (ssh-Console), kannst du die Geräte, die du mit PRESENCE/ping überwachst anpingen?
Oder generell "ins Netz"?
Z.B. ping google.de etc.

Irgendwas im Netzwerk geändert?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

M.Piet

Danke für deine Hilfe. 😊

update list bringt folgendes:

http://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt
https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt
https://raw.githubusercontent.com/kc-GitHub/FHEM-HM485/master/controls_hm485.txt
https://raw.githubusercontent.com/ThorstenPferdekaemper/FHEM-FUIP/master/controls_fuip.txt
https://raw.githubusercontent.com/knowthelist/ftui/master/controls_ftui.txt

Ich habe länger einen Ping laufen lassen, es gibt keine Peaks nach oben. Läuft sauber durch. Es gab auch keine Änderungen im Netzwerk. Haben Glasfaser 500Mbit und der ist sauber.
Aber da auch anscheinend 1wire mit den hohen Load zu kämpfen hat, ebenso FTUI3, glaube ich auch nicht an ein Netzwerkproblem.

Bin echt ratlos.

Kann man nicht irgendwie über die PID dahinterkommen, wie die  Prozesse gestartet wurden?

MadMax-FHEM

Zitat von: M.Piet am 01 Oktober 2024, 09:50:12update list bringt folgendes:
Ok, dann ist zumindest wohl pythonbinding nicht genutzt...

Zitat von: M.Piet am 01 Oktober 2024, 09:50:12Ich habe länger einen Ping laufen lassen, es gibt keine Peaks
ping VOM fhem-Rechner zu einem der "überwachten" (PRESENCE) Rechner?
Und das ging durch?

Weil es ja in deinem Log so aussieht, als ob ping (aus PRESENCE) nicht (gut) ginge...

Glasfaser ist ja erst vom Haus ab weg...
...oder hast du lokal auch alles mit Glasfaser? ;)

Der Verdacht war/ist, dass irgendwas bzgl. Netzwerk AUF dem fhem-Rechner "schief" ist, weil es eben so viele Meldungen von Unterprozessen/Devices gibt, die irgendwas mit Netzwerk machen...

IP-Range (INTERN) geändert und z.B. vergessen global dnsServer anzupassen? Ist das Attribut dnsServer bei global überhaupt gesetzt?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

M.Piet

Ja, der Ping ging sauber durch.
Ne, Lokal habe ich keine Glasfaser. 😊
Du hast recht, PRESENCE meckert im Log. Aber eher wegen einem Timeout. Ich vermute, dass durch die hohe CPU Last das Modul einen Timeout bekommt. Genau wie 1wire (und das hat ja mit LAN nichts zu tun).

Der DNS unter Global ist gesetzt. 😊

Nach einem Neustart eben war die CPU Arbeitslos. Alles war flott. Nach ein paar Minuten taucht der erste python Prozezz auf, der die CPU zu 100% einnimmt (siehe Screenshot).

MadMax-FHEM

Zitat von: M.Piet am 01 Oktober 2024, 10:20:17Nach einem Neustart eben war die CPU Arbeitslos. Alles war flott. Nach ein paar Minuten taucht der erste python Prozezz auf, der die CPU zu 100% einnimmt (siehe Screenshot).
Tja, wenn du nicht weißt woher die python-Prozesse (plötzlich) kommen (könnten) und du auch (so sieht es aus) kein python aus fhem (z.B. python-binding) nutzt, wird es schwer...

Wenn es langsam ist/wird und du ein:
sudo killall -9 python
(ja ist rüde/hart aber nur so als Test)
ausführst, wird es dann wieder "flott"?

Ausgeführt werden die python-Prozesse offenbar durch root -> system bzw. ein "Service"?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

M.Piet

sudo killall -9 pythonDas hat (wie erwartet auch geklappt). Aber nach kurzer Zeit ist der Prozezz wieder da. So langsam wird es seltsam.

sepultura30

Hi,

installiere dir mal Webmin, da kannst du den Prozess verfolgen bis zum Mutter-Prozess.
Dann siehst du auch was es auslöst.

Grüße

Sandro

M.Piet

#12
Zitat von: sepultura30 am 01 Oktober 2024, 13:06:03Hi,

installiere dir mal Webmin, da kannst du den Prozess verfolgen bis zum Mutter-Prozess.
Dann siehst du auch was es auslöst.
Danke!!!! Jetzt kommen wir der Sache näher.
Die entsprechende Datei ultrasonic.py habe ich mal angehangen.

Ich erfasse von Zisterne und Öltank die Pegelstände mit Ultraschallsensoren.
Aber warum macht nun grad aktuell eine davon so einen stress?

Ich habe in dem Zuge damals auch einen Cronjob eingerichtet:

10 0,6,12,18 * * * /home/pi/ultrasonic.py >> /home/pi/zisterne.log


MadMax-FHEM

Schon mal in /home/pi/zisterne.log geschaut?
Vielleicht sieht man da was...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

M.Piet

Ja, ich bin in der Tat weiter.
Ich kann die Datei mit sudo python ultrasonic.py nicht starten. Es passiert nichts. Aber genau in dem Moment kommt der Prozezz wieder! Das ist also die Ursache!
Und da per Cronjob alle Stunde eine neue Abfrage gemacht wird, entsteht diese Kaskade mit immer neuen Prozezzen!!!

Es gibt noch die Datei ultrasonic2.py, damit frage ich den Stand des Öltanks ab.
Diese kann ich mit sudo python ultrasonic2.py auch korrekt abfragen. Hierbei entsteht nicht dieser Prozezz.

Ich habe beide Dateien mit Notepad vergleichen lassen. Sie sind identisch (mit Ausnahme der GPOIs, siehe unten).
Der einzige Unterschied: Berechtigungen.
ultrasonic.py 644
ultrasonic2.py 755
Das ist aber nicht die Ursache.

Die funktionierende ultrasonic2.py schaut auf diese GPIOs:
GPIOTrigger = 27
GPIOEcho    = 17

Die nicht funktionierende ultrasonic.py schaut auf diese GPIOs:
GPIOTrigger = 24
GPIOEcho    = 23

Kann ein GPIO defekt sein und das auslösen?
Ich werde den Ultraschallsensor auch mal abklemmen und schauen ob es immer noch so ist.

Vielen vielen dank euch allen für die Hilfe bis hier hin!!!!