Hallo zusammen
mir ist gestern aufgefallen das der Frontendseitenaufbau sehr lange dauert, aber nur wenn die HM Konfiguration (die ist allerdings sehr umfangreich) geladen ist.
Habt Ihr das auch schon beobachtet? Welche Optimierungstips gibt es dafür?
Logfiles auf -%y-%m
verbose 3
lg
Stefan
Auf welcher Hardware läuft dein FHEM?
Hi
auf einem RaspBerryPi.
lg
Stefan
Dann kannst du mit apptime erstmal gucken, ob wirklich das Homematic-Perl-Modul die Verzögerung verursacht oder irgendetwas anderes (z.B. dass Logging der nun häufigeren Ereignisse, irgendwelche notifies etc.)
Einfach apptime eingeben, ne Weile laufen lassen, und dann nochmal apptime - bzw. nochmal im Forum danach suchen.
Genereller Optimierungstipp: Manche Homematic-Devices erzeugen sehr viele Events und damit ggf. Log-Einträge, z.B. der Zwischenstecker mit Leistungsmessung oder der Heizungsthermostat. Hier sollte man mit event-on-change-reading arbeiten und die Events auf das einschränken, was man wirklich braucht.
Hallo zusammen
so schaut das Ergebnis von apptime aus
Zitat
name function max count total average maxDly
HML HMLAN_Read 27968 67 852666 12726.36 0 HASH(HML)
tmr-km200_GetStatus HASH(0x1a0f5d8) 18472 54 950160 17595.56 34089 HASH(myKM200)
myDbLog DbLog_Log 12253 1003 2125977 2119.62 0 HASH(myDbLog); HASH(myKM200)
tmr-IPSW_GetStatus HASH(0x1951710) 7582 28 176022 6286.50 45667 HASH(myIPSW_14)
tmr-IPSW_GetStatus HASH(0x1c42668) 6452 28 175024 6250.86 44590 HASH(myIPSW_23)
tmr-SYSMON_Update HASH(0x12a9060) 5069 28 85000 3035.71 47000 HASH(sysmon)
NO_PO_Klingel_O notify_Exec 3812 1003 4376 4.36 0 HASH(NO_PO_Klingel_O); HASH(HM_SCI_3_FM_23CC5E_Sw_01)
CUNO CUL_Read 3176 32 66590 2080.94 0 HASH(CUNO)
tmr-HMLAN_KeepAliveCheck keepAliveCk:HML 3086 42 3149 74.98 51956 keepAliveCk:HML
HML HMLAN_Ready 2901 11 22424 2038.55 0 HASH(HML)
No_Heizung_NiklasFenster_geschlossen notify_Exec 1908 3 1908 636.00 0 HASH(No_Heizung_NiklasFenster_geschlossen); HASH(HM_SEC_SC_219F72)
Pushover1 Pushover_Set 1897 2 3775 1887.50 0 HASH(Pushover1); Pushover1; msg; 'Achtung'; 'Klingel; Oben'; ''; 0; 'climb'
Button_Niklas_Btn CUL_HM_Set 1891 2 3242 1621.00 0 HASH(Button_Niklas_Btn); Button_Niklas_Btn; postEvent; 0
tmr-CUL_HM_ActCheck ActionDetector 1392 41 2507 61.15 44888 ActionDetector
tmr-CUL_HM_respPendTout respPend:21CEC3 1375 8 4638 579.75 33170 respPend:21CEC3
No_Heizung_NiklasFenster_offen notify_Exec 1366 3 1367 455.67 0 HASH(No_Heizung_NiklasFenster_offen); HASH(HM_SEC_SC_219F72)
FileLog_myIPS_14 FileLog_Log 973 84 1115 13.27 0 HASH(FileLog_myIPS_14); HASH(myIPSW_14)
tmr-at_Exec HASH(0x19c1dc8) 648 40 20387 509.68 44306 HASH(at_RpiTemp)
RpiTemp dummy_Set 527 40 18642 466.05 0 HASH(RpiTemp); RpiTemp; T:; 55.15
tmr-SYSSTAT_GetUpdate HASH(0x12bf288) 521 28 13033 465.46 45666 HASH(sysstat)
tmr-at_Exec HASH(0x12f97e0) 148 40 2054 51.35 44778 HASH(at_RpiRam)
lg
Stefan
Oha. Also da würde ich ersteinmal gucken, ob auf dem Raspberry sonst noch irgendwas außer FHEM läuft, was an der Systemleistung nuckelt (z.B. mit su top auf der Konsole).
Ansonsten ist innerhalb von FHEM bei dir dblog der Hauptressourcenfresser, was bei mir auf dem Raspi auch mal so war. Was nimmst du als DB, MySQL? Falls ja guck mal hier: http://forum.fhem.de/index.php/topic,23882.0.html - das sollte schonmal mehr speed bringen.
Edit: Und das Logging betreibt wohl irgendein "km200"-device exzessiv. Kenn ich zwar nicht, aber das scheint dein Log zu fluten.
LG Peter
Hi Peter
Danke. Der Tipp mit DBLog hat geholfen. Ich habe DBLog erstmal ausgeschaltet, jetzt läuft FHEM wieder stabiler.
DBLog ging in eine MySQL DB auf der QNAp
KM200 ist ein eigenes Modul das die Heizungsparameter abfragt hab ich jetzt etwas gebremst.
lg
Stefan