[gelöst] Optimierung Dauer von "save config"

Begonnen von FhemPiUser, 17 Oktober 2020, 16:33:01

Vorheriges Thema - Nächstes Thema

FhemPiUser

ja, 48mb mehr bringen nicht viel.

mein raspian sollte lite sein...

betateilchen

Das Problem ist höchstwahrscheinlich in FHEM zu suchen, nicht im Betriebssystem oder in der Hardware.

Was ich als erstes machen würde: alle devices in FHEM deaktivieren, die exzessiv mit Betriebssystemaufrufen arbeiten.

Beobachte doch mal mit top in einem offenen Fenster auf dem pi, ob dort irgendwelche Auffälligkeiten passieren, wenn Du in FHEM ein save ausführst.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

FhemPiUser

#17
Ich habe mal "save config" gedrückt und parallel mit htop geschaut:

Der fhem-Hauptprozess geht auf 100% (in der Anzeige oben geht auch nur einer der 4 Prozessoren auf 100%).

Gleichzeitig vermehren sich die fhem-Prozesse auf 6 (Update: Das scheint an den "ping"-devices zu liegen und nicht die Ursache zu sein: Wenn ich alle "ping"-devices deaktiviere werden keine neuen Prozesse gestartet. Die CPU geht aber trotzdem auf 100% und fhem blockiert trotzdem für 1,5min)

Nach 1,5min normalisiert sich die Situation wieder und es gibt nur noch 1 fhem-Prozess, der 23,7% Memory benötigt und kaum CPU.

Es scheint also kein RAM, sondern ein CPU-Problem zu sein.

Gibt es eine Möglichkeit die CPU/RAM-Nutzung der einzelnen fhem-devices auszuwerten?

FhemPiUser

#18
Ich habe es: Ich habe mein snips/MQTT devices in fhem gelöscht, ein fhem update all ausgeführt, neu gestartet und jetzt geht das "save config" schnell...

Es scheint also an den snips / mqtt devices gelegen zu haben, bei dem die gegenstelle der mqtt nicht mehr da ist, da ich snips nicht mehr verwende...

rudolfkoenig

Kannst Du bitte das Problem mit dem angehaengten fhem.pl nachstellen, und den FHEM-Log-Ausschnitt hier anhaengen?

Welchen Typ hat snipsMQTT ?

FhemPiUser

#20
das war ein MQTT-Device und ein SNIPS-Device (http://snips.ai):

define SnipsMQTT MQTT 192.168.1.xx:xx
setuuid SnipsMQTT xx
attr SnipsMQTT room Snips
define Snips SNIPS SnipsMQTT Wohnzimmer
setuuid Snips xxx
attr Snips IODev SnipsMQTT
attr Snips room Snips


Ich versuche es mal nachzustellen. Noch kann ich nicht zu 100% sagen, ob das die Ursache war oder einfach das fhem Update oder der Neustart. Ich hatte vorher mein fhem >6 Monate nicht neu gestartet....

FhemPiUser

#21
Ich habe gerade versucht es nachzustellen, leider ohne Erfolg.

Nachdem ich die Snips devices wieder eingerichtet habe, geht das save config noch immer schnell (wobei ich die setuid Kommandos nicht ausführen konnte und daher weglassen musste)

Es muss also wohl mit dem fhem Update/Neustart zu tun gehabt haben, kann aber jetzt nicht das update rückgängig machen.

Meine Systemversion vorher:
- fhem.pl-Version war 20415 2019-10-27 17:23:55Z
- 01_FHEMWEB.pm 22632 2020-08-19 17:02:35Z

Evtl. ist es auch ein (kleines) Memory-Leak in irgendeinem Device, was erst nach mehreren Monaten fhem runtime bemerkbar ist und bei einem save config zum swap führt. Denn der Memory-Verbrauch ist bei mir jetzt niedriger seit dem update/neustart. Wobei das eigentlich nicht die Ursache sein kann, da ich keinen größeren IO-Traffic zur SD-Karte gesehen hatte in den 1,5min...

Habe jetzt auch nochmal den Raspberry neu gebootet udn der GPU nur 16MB gegeben

free -m sagt jetzt:

              total        used        free      shared  buff/cache   available
Mem:            975         148         719           6         107         768
Swap:            99           0          99



"used mem" war vorher etwa doppelt so hoch...

Ich richte jetzt ein DOIF auif sysmon swap used mit Benachrichtigung ein, damit ich weiß, wenn der Swap mal wieder verwendet wird...

betateilchen

Zitat von: betateilchen am 18 Oktober 2020, 00:06:26
Das Problem ist höchstwahrscheinlich in FHEM zu suchen, nicht im Betriebssystem oder in der Hardware.

Zitat von: FhemPiUser am 18 Oktober 2020, 10:39:21
Ich habe es: Ich habe mein snips/MQTT devices in fhem gelöscht, ein fhem update all ausgeführt, neu gestartet und jetzt geht das "save config" schnell...

q.e.d.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

FhemPiUser

#23
Hier der Beweis: Log-Output mit global verbose auf 5:

2020.10.18 13:09:40.541 5: Cmd: >save<
2020.10.18 13:09:40.542 5: Starting notify loop for global, 1 event(s), first is SAVE
2020.10.18 13:09:40.542 5: createNotifyHash
2020.10.18 13:09:40.630 5: statistics AussentemperaturStatistik: Notify.280 Notification of 'global' received. Device not monitored.
2020.10.18 13:09:40.630 5: statistics AussentemperaturStatistik_tendency: Notify.280 Notification of 'global' received. Device not monitored.
2020.10.18 13:09:40.631 5: statistics CO20_Statistics: Notify.280 Notification of 'global' received. Device not monitored.
2020.10.18 13:09:40.631 5: statistics Drainage_Statistics: Notify.280 Notification of 'global' received. Device not monitored.
2020.10.18 13:09:40.631 5: statistics Drainage_backup_Statistics: Notify.280 Notification of 'global' received. Device not monitored.
2020.10.18 13:09:40.632 5: statistics stat_Windsensor: Notify.280 Notification of 'global' received. Device not monitored.
2020.10.18 13:09:40.636 5: AptToDate (SysAptInfo) - Notify: $VAR1 = [
          'SAVE'
        ];

2020.10.18 13:09:40.658 5: r_wochenprogramme: not on any display, ignoring notify
2020.10.18 13:09:40.659 5: rg_battery: not on any display, ignoring notify
2020.10.18 13:09:40.659 5: rg_battery_ftui: not on any display, ignoring notify
2020.10.18 13:09:40.659 5: rg_boe: not on any display, ignoring notify
2020.10.18 13:09:40.659 5: rg_dead: not on any display, ignoring notify
2020.10.18 13:09:40.660 5: rg_httpmod_sensitivity: not on any display, ignoring notify
2020.10.18 13:09:40.660 5: rg_missingAck: not on any display, ignoring notify
2020.10.18 13:09:40.660 5: rg_motionIndicator: not on any display, ignoring notify
2020.10.18 13:09:40.660 5: rg_seqnodiffs: not on any display, ignoring notify
2020.10.18 13:09:40.670 5: End notify loop for global
2020.10.18 13:09:40.809 4: PROPLANTA proplanta: HtmlAcquire.594 345257 characters captured
2020.10.18 13:09:40.837 4: PROPLANTA proplanta: Run.703 Start HTML parsing of captured page
2020.10.18 13:09:41.011 4: WEB: /fhem?cmd=save&XHR=1&fwcsrf=xxx&fw_id=5771 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate


Das config save hat jetzt also ca. 500ms gedauert, war voher 1,5min...