Autor Thema: [gelöst] Optimierung Dauer von "save config"  (Gelesen 723 mal)

Offline FhemPiUser

  • Sr. Member
  • ****
  • Beiträge: 745
Antw:Optimierung Dauer von "save config"
« Antwort #15 am: 17 Oktober 2020, 23:04:58 »
ja, 48mb mehr bringen nicht viel.

mein raspian sollte lite sein...

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16601
  • s/fhem\.cfg/configDB/g
Antw:Optimierung Dauer von "save config"
« Antwort #16 am: 18 Oktober 2020, 00:06:26 »
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline FhemPiUser

  • Sr. Member
  • ****
  • Beiträge: 745
Antw:Optimierung Dauer von "save config"
« Antwort #17 am: 18 Oktober 2020, 09:14:56 »
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?
« Letzte Änderung: 18 Oktober 2020, 10:32:17 von FhemPiUser »

Offline FhemPiUser

  • Sr. Member
  • ****
  • Beiträge: 745
Antw:Optimierung Dauer von "save config"
« Antwort #18 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...

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...
« Letzte Änderung: 18 Oktober 2020, 10:45:02 von FhemPiUser »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22968
Antw:Optimierung Dauer von "save config"
« Antwort #19 am: 18 Oktober 2020, 10:45:51 »
Kannst Du bitte das Problem mit dem angehaengten fhem.pl nachstellen, und den FHEM-Log-Ausschnitt hier anhaengen?
 
Welchen Typ hat snipsMQTT ?

Offline FhemPiUser

  • Sr. Member
  • ****
  • Beiträge: 745
Antw:Optimierung Dauer von "save config"
« Antwort #20 am: 18 Oktober 2020, 11:07:38 »
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....
« Letzte Änderung: 18 Oktober 2020, 11:10:48 von FhemPiUser »

Offline FhemPiUser

  • Sr. Member
  • ****
  • Beiträge: 745
Antw:Optimierung Dauer von "save config"
« Antwort #21 am: 18 Oktober 2020, 11:54:04 »
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...
« Letzte Änderung: 18 Oktober 2020, 13:41:27 von FhemPiUser »

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16601
  • s/fhem\.cfg/configDB/g
Antw:Optimierung Dauer von "save config"
« Antwort #22 am: 18 Oktober 2020, 12:55:27 »
Das Problem ist höchstwahrscheinlich in FHEM zu suchen, nicht im Betriebssystem oder in der Hardware.

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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline FhemPiUser

  • Sr. Member
  • ****
  • Beiträge: 745
Antw:Optimierung Dauer von "save config"
« Antwort #23 am: 18 Oktober 2020, 13:12:28 »
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...
« Letzte Änderung: 18 Oktober 2020, 13:19:15 von FhemPiUser »

 

decade-submarginal