Hauptmenü

Auswertung apptime

Begonnen von CoolTux, 06 Januar 2016, 09:24:30

Vorheriges Thema - Nächstes Thema

CoolTux


name             function    max  count    total  average maxDly
             tmr-HUEBridge_GetUpdate      HASH(0x1c679e8)   8996     42    22710   540.71   1106 HASH(HUELAN1)
                              HMLAN1           HMLAN_Read   7330   2108   401863   190.64      0 HASH(HMLAN1)
       notifyLichtSceneAbendsHellBtn          notify_Exec   6752      1     6752  6752.00      0 HASH(notifyLichtSceneAbendsHellBtn); HASH(HM_3657EB_Btn_04)
              lightScenenLicht_Media       LightScene_Set   6741      3     8422  2807.33      0 HASH(lightScenenLicht_Media); lightScenenLicht_Media; scene; Twilight_7_WohnzimmerFlur
                tmr-watchdog_Trigger      HASH(0x25e5650)   5573      1     5573  5573.00     10 HASH(wd_AnniKraussStr_absent)
          Macro_AnniKraussStr_absent          notify_Exec   5421      1     5421  5421.00      0 HASH(Macro_AnniKraussStr_absent); HASH(Macro_AnniKraussStr_absent)
                tmr-watchdog_Trigger      HASH(0x25e2098)   5309      1     5309  5309.00     12 HASH(wd_PresenceLocationMarko)
         structureVerbraucherWohnung        structure_Set   5188      2     5188  2594.00      0 HASH(structureVerbraucherWohnung); structureVerbraucherWohnung; off
                            rr_Marko         ROOMMATE_Set   4743      5     5997  1199.40      0 HASH(rr_Marko); rr_Marko; absent
       FHEMWEB:192.168.240.252:43750              FW_Read   4231      5     4315   863.00      0 HASH(FHEMWEB:192.168.240.252:43750)
              tmr-Twilight_fireEvent      HASH(0x1c66578)   3656      1     3656  3656.00     12 HASH(twilightStahnsdorf_sr_indoor)
            doifSetDisplayBrightness          DOIF_Notify   3163   2455     3777     1.54      0 HASH(doifSetDisplayBrightness); HASH(twilightStahnsdorf)
              notify_rr_InetFWstatus          notify_Exec   3117   2455     8631     3.52      0 HASH(notify_rr_InetFWstatus); HASH(rr_Marko)
         tmr-statistics_PeriodChange      HASH(0x2486660)   2870      4    10262  2565.50    378 HASH(STATISTIKEN)
      structureVerbraucherWohnzimmer        structure_Set   2468      2     2468  1234.00      0 HASH(structureVerbraucherWohnzimmer); structureVerbraucherWohnzimmer; off
                             WEBhook              FW_Read   2242      6     4493   748.83      0 HASH(WEBhook)
                         tmr-at_Exec      HASH(0x2dc3d50)   2200      7     6872   981.71     11 HASH(atGetDWD_CondWarnMaps)
            structureLichtWohnzimmer        structure_Set   2168      2     2168  1084.00      0 HASH(structureLichtWohnzimmer); structureLichtWohnzimmer; off
                         tmr-at_Exec      HASH(0x11ca8f0)   2047      1     2047  2047.00     14 HASH(atIsabelHandyFWstatusErlaubtWeek)
           buttonIsabelHandyFWstatus            dummy_Set   2030      3     2030   676.67      0 HASH(buttonIsabelHandyFWstatus); buttonIsabelHandyFWstatus; erlaubt
          notifyFirewall_IsabelHandy          notify_Exec   1865   2455     7501     3.06      0 HASH(notifyFirewall_IsabelHandy); HASH(buttonIsabelHandyFWstatus)


Irgenwie habe ich das Gefühl das es hackt. Die Leute sagen doch immer alles über 1000 also eine Sekunde ist kritisch. Ich habe hier nur große Zahlen    :-\
Was denkt ihr?



Grüße
Leon
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

ext23

Moin,

schade, ich dachte hinter dem Topic gibt es mehr Informationen ;-) Gibt es hier irgendwo ein Hinweis wie man das Apptime auswertet? Ich sehe da auch nicht so ganz durch. Mein FHEM spielt in letzter Zeit ziemlich verrückt mit zeitkritischen Sachen wie 1-Wire etc. Aber die Werte aus Apptime sagen mir nicht viel.

Wenn ich mal den folgenden Beispiel Auszug nehme:

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
Nextion01                                Nextion_Ready                         3000     4440   30280.30     6.82     0.00     0.00 13.10. 08:55:58 HASH(Nextion01)
KODI                                     KODI_Ready                            3000     4440   30273.60     6.82     0.00     0.00 13.10. 08:54:59 HASH(KODI)
tmr-OWID_GetValues                       HASH(0x72bac38)                       1598      124   42745.19   344.72  2861.54   247.77 13.10. 09:02:54 HASH(fl_iButton_gelb)
tmr-OWID_GetValues                       HASH(0x72bb1f0)                       1598      124   58474.05   471.56  3006.55   253.01 13.10. 08:56:39 HASH(fl_iButton_blau)
Notify_Schluessel_Anett                  notify_Exec                           1420       16   20955.08  1309.69     0.00     0.00 13.10. 09:02:54 HASH(Notify_Schluessel_Anett); HASH(fl_iButton_gelb)
Notify_Schluessel_Daniel                 notify_Exec                           1420       28   36629.70  1308.20     0.00     0.00 13.10. 08:56:39 HASH(Notify_Schluessel_Daniel); HASH(fl_iButton_blau)
tmr-at_Exec                              HASH(0x896f0d8)                        812        2    1623.02   811.51   884.01   491.15 13.10. 08:56:40 HASH(Timer_ba_Temp_Steuereinheit)
ba_Temp_Steuereinheit                    ECMDDevice_Set                         808        2    1617.11   808.56     0.00     0.00 13.10. 08:56:40 HASH(ba_Temp_Steuereinheit); ba_Temp_Steuereinheit; messen
HMLAN1                                   HMLAN_Read                             499      143    8589.90    60.07     0.00     0.00 13.10. 08:58:05 HASH(HMLAN1)


Was ist denn da das, worauf ich achten muss?

Count = Anzahl der Aufrufe des Moduls?
Total= Gesamtzeit die das aufgerufenen Modul in Anspruch genommen hat?
Average = Durchschnittliche Aufrufzeit des Moduls, also Total/ Count?

MaxDly = Maximale Verzögerung beim Aufruf des Moduls, sprich hier blockiert etwas?
AvgDly = Durchschnittliche Verzögerung beim Aufruf des Moduls, vermutlich eher weniger spannend zur Fehlersuche oder? Auch ein einmaliges MaxDly ist zu viel und bedeutet das etwas unsauber programmiert ist, richtig?

Ist mein Verständnis richtig? Oder muss ich auf noch mehr achten? Und das MaxDly sollte überall unter 1000 sein oder wie? Aber die Aussage ist ja auch schwammig, 30 Module mit 900 sind dann am ende auch reichlich Stillstand oder wie?

Wäre nett wenn mir jemand mehr Licht ins Dunkel bringen könnte.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

CoolTux

Ich habe immer nach average sortiert. Probier das mal. War glaube apptime average.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

ext23

Mhh ok, da ist bei mir alles recht klein, also im 800er Bereich.

Aber woran erkenne ich jetzt ob dieses Modul in ein extra thread ausgelagert ist und nicht blockiert oder ob es eben doch blockiert?

Das ist echt schwer unter FHEM bestimme Verhalten zu untersuchen. Mit zunehmender Anzahl von Geräten passieren komische Sachen bei mir. Ich merke es dann immer an meinen 1Wire iButtons wenn die toggeln. Aber da bin ich schon dran, das wird umgebaut und dann kann ich den rest auch in diesem Async Modus laufen lassen. Man merkt es natürlich auch wenn das Licht 3 Sekunden später angeht als erwartet.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

CoolTux

Zitat von: ext23 am 13 Oktober 2018, 09:48:09
Mhh ok, da ist bei mir alles recht klein, also im 800er Bereich.

Aber woran erkenne ich jetzt ob dieses Modul in ein extra thread ausgelagert ist und nicht blockiert oder ob es eben doch blockiert?

Das ist echt schwer unter FHEM bestimme Verhalten zu untersuchen. Mit zunehmender Anzahl von Geräten passieren komische Sachen bei mir. Ich merke es dann immer an meinen 1Wire iButtons wenn die toggeln. Aber da bin ich schon dran, das wird umgebaut und dann kann ich den rest auch in diesem Async Modus laufen lassen. Man merkt es natürlich auch wenn das Licht 3 Sekunden später angeht als erwartet.

/Daniel

Apptime zeigt Dir welche Funktion wie lange laufen und wie oft. Ist also schon mal ein guter Anfang wenn da alles unter 1s also unter 1000 liegt.
Es gibt noch ein weiteres Modul zum testen, mir fällt nur gerade der Name nicht ein. Es schreibt Dir ins Log wenn eine Funktion länger wie die von Dir eingestellte Zeit läuft.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

DS_Starter

ZitatEs gibt noch ein weiteres Modul zum testen, mir fällt nur gerade der Name nicht ein.

freezemon ?
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

CoolTux

Jepp genau das war es. Vielen Dank Heiko
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

ext23

Super vielen Dank, schau ich mir mal an. Kannte ich noch nicht.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

frank

die beiden notify_schlüssel finde ich schon beachtenswert.
während der beobachtungszeit durch apptime haben sie fhem maximal 1,42s blockiert. da der avg wert nicht viel kürzer ist, muss hier bei jedem aufruf eine entsprechende blockade stattfinden. also systematisch, was eventuell vermeidbar ist.

ob das für dein system problematisch ist, kannst nur du entscheiden. gelegentliche freezes, die keine anderen funktionen verzögern, könnte man ja vielleicht beibehalten. allerdings können auch viele kleine freezes hintereinander "unangenehm" werden.

auch können kurze freezes probleme bereiten, wenn sie zu zeiten auftreten, wenn es auf timing ankommt.

bei maxDly/avgDly wurden die funktionen durch fhem verzögert.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ext23

Zitat von: frank am 15 Oktober 2018, 16:27:34
bei maxDly/avgDly wurden die funktionen durch fhem verzögert.

Ja das sind genau die blöden 1-Wire iButtons, aber ich hab das jetzt umgebaut, ich hab ein HB-HM Gerät zwischen was die iButtons ausliest und an FHEM schickt, kein polling mehr, keine Hänger...

OK, also ist doch maxDly der interessante Wert auf den man achten sollte.
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)