FHEM in Docker - CPU Lastspitzen

[tobelix]

Ich habe FHEM im offiziellen Docker Image auf einem rpi3b+ laufen. Einmal als Produktivsystem 24/7 und einmal als Testsystem, das ich nur bei Bedarf hochfahre.
Ich hatte kürzlich das Testsystem ein paar Tage laufen weil ich ein paar neue Sachen implementiert und getestet habe. Auf einmal ist imr aufgefallen, dass der komplette rpi extrem langsam wurde. Also habe ich angefangen zu analysieren was da los ist und der Container mit dem FHEM Testsystem hat eine extrem große CPU-Last. Hab dann mal ein paar Devices deaktiviert weil ich da ziemlich viel rumgespielt habe und teilweise gar nicht mehr weiß was ich gemacht habe. Das hat geholfen.

Habe mir dann im Portainer mal die Statistiken angeschaut und dabei ist mir aufgefallen, dass es im Container regelmäßig CPU Lastspitzen gibt.
Du darfst diesen Dateianhang nicht ansehen.

Im Produktivsystem habe ich das auch, aber ein bisschen schwächer - obwohl da eigentlich mehr läuft.
Du darfst diesen Dateianhang nicht ansehen.

Weiß jemand woran das liegt oder wie ich herausfinden kann was da so viel CPU Kapazität braucht? Im Log und Event Monitor kann ich nichts erkennen.

[tobelix]

Wenn niemand eine Idee hat wie ich herausfinden könnte woran das liegt, kann jemand bestätigen ob es bei euch diese Lastspitzen auch gibt?

[Wernieman]

Das dürfte nicht am Docker, sondern an Deinem FHEM liegen ....

[tobelix]

wie könnte ich herausfinden woran das liegt? Logfile und Eventmonitor zeigt nichts.
Apptime ist längste max Laufzeit 144ms.

[Wernieman]

Analyse Deiner Config ... mehr weiß ich auch nicht ....

P.S: rufst Du Durch ein externes Gerät eine Seite mit vielen Grafen auf?

[M.Schulze]

wie könnte ich herausfinden woran das liegt? Logfile und Eventmonitor zeigt nichts.
Apptime ist längste max Laufzeit 144ms.

Du kannst doch CPU begrenzen. Dann wirst du schon merken wo es hakt. Ich habe aktuell 20m bis Limit 40m eingestellt. Also Mindestanforderung und fürs debuggen.

[Wernieman]

Und P.S. für die Interessanten Leute ist der Thread Titel dafür nicht gut ... die werden den Thread nicht lesen ...

[kadettilac89]

Weiß jemand woran das liegt oder wie ich herausfinden kann was da so viel CPU Kapazität braucht? Im Log und Event Monitor kann ich nichts erkennen.

das Ganze wiederholt sich alle paar Sekunden. Geht mal  in den Container und beobachte die Prozesse mit top.

In den Container kommst du vom Linux mit ... s. u. fhem heißt mein Container, Name entsprechend ändern

Code Auswählen Erweitern

docker exec -it fhem bash
Im Contianer dann

Code Auswählen Erweitern

top
Das sollte sich automatisch aktualisieren. Kopiere mal 2 bei denen die CPU hoch ist und einmal wenn CPU niedrig ist. Am besten <Snapshot 1 = CPU hoch, Snapshot 2 = CPU low, Snapshot 3 = CPU high

Sollte in etwa so aussehen

Code Auswählen Erweitern

top - 21:07:33 up 4 days, 19:21,  0 users,  load average: 1,98, 1,91, 1,91
Tasks:  19 total,  1 running,  18 sleeping,  0 stopped,  0 zombie
%Cpu(s):  1,7 us,  1,6 sy,  0,0 ni, 96,1 id,  0,6 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :  15843,4 total,  4681,4 free,  4997,7 used,  6164,3 buff/cache
MiB Swap:  8192,0 total,  8123,7 free,    68,2 used.  11000,4 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TIME+ COMMAND
      1 root      20  0  14736  3712  2816 S  0,0  0,0  18:26.90 entry.sh
  24279 fhem      20  0  328608 239152  15488 S  0,0  1,5  56:43.01 perl
  24281 fhem      20  0  102172  43580  2432 S  0,0  0,3  1:08.23 perl
  24282 fhem      20  0  102172  43452  2432 S  0,0  0,3  1:07.24 perl
  24283 fhem      20  0  102172  43452  2432 S  0,0  0,3  1:07.33 perl
  24284 fhem      20  0  119944  72252  5248 S  0,0  0,4  1:29.65 perl
 996728 fhem      20  0  957624 105056  35712 S  0,0  0,6  1:06.41 fhem-co+



Wenn du das Rauskopieren nicht schaffst kannst du auch im  Batchmode testen, dann wird die Ausgabe immer unten angehängt

Code Auswählen Erweitern

top -b -n 100

[tobelix]

Sorry dass es so lange gedauert hat. Kam Urlaub dazwischen.

CPU hoch:

Code Auswählen Erweitern

top - 20:36:21 up 351 days,  1:06,  0 users,  load average: 2,04, 1,45, 0,84
Tasks:  10 total,   2 running,   8 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26,4 us,  8,0 sy,  0,1 ni, 65,0 id,  0,1 wa,  0,0 hi,  0,3 si,  0,0 st
MiB Mem :    976,7 total,     68,3 free,    574,3 used,    334,2 buff/cache
MiB Swap:   1972,0 total,   1556,8 free,    415,2 used.    345,9 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
10669 root      20   0    3216   1832   1284 R  11,0   0,2   0:00.33 jq
10599 root      20   0    1504    384    340 S   6,0   0,0   0:00.18 sh
 4516 fhem      20   0  120744 103540   8948 S   1,7  10,4   0:20.38 perl
    1 root      20   0    8236   2556   2320 S   1,3   0,3   0:04.79 entry.sh
 4560 fhem      20   0   64980  38200   2308 S   0,3   3,8   0:00.25 perl
10613 root      20   0    7616   2668   2428 S   0,3   0,3   0:00.01 health-check.sh
 5885 root      20   0    7748   2872   2548 S   0,0   0,3   0:00.19 bash
10454 root      20   0   10304   2720   2312 R   0,0   0,3   0:00.02 top
10667 root      20   0    7616   1320   1080 S   0,0   0,1   0:00.00 health-check.sh
10677 root      20   0    6392    388    344 S   0,0   0,0   0:00.00 sleep

CPU Normal:

Code Auswählen Erweitern

top - 20:39:19 up 351 days,  1:09,  0 users,  load average: 1,43, 1,25, 0,86
Tasks:   6 total,   1 running,   5 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4,9 us,  5,8 sy,  0,0 ni, 89,2 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Mem :    976,7 total,     41,0 free,    575,2 used,    360,6 buff/cache
MiB Swap:   1972,0 total,   1557,1 free,    414,9 used.    346,4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    1 root      20   0    8236   2560   2320 S   1,3   0,3   0:06.78 entry.sh
 4516 fhem      20   0  120744 103548   8948 S   1,3  10,4   0:22.15 perl
10454 root      20   0   10304   2720   2312 R   0,3   0,3   0:00.18 top
 4560 fhem      20   0   64980  38200   2308 S   0,0   3,8   0:00.36 perl
 5885 root      20   0    7748   2872   2548 S   0,0   0,3   0:00.19 bash
13871 root      20   0    6392    360    316 S   0,0   0,0   0:00.00 sleep

CPU hoch

Code Auswählen Erweitern

top - 20:38:49 up 351 days,  1:09,  0 users,  load average: 0,90, 1,15, 0,82
Tasks:  10 total,   2 running,   8 sleeping,   0 stopped,   0 zombie
%Cpu(s): 40,6 us, 10,9 sy,  0,1 ni, 48,2 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Mem :    976,7 total,     54,2 free,    574,4 used,    348,2 buff/cache
MiB Swap:   1972,0 total,   1557,1 free,    414,9 used.    347,1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
13242 root      20   0    1504    428    384 S   5,3   0,0   0:00.16 sh
13309 root      20   0    3216   1832   1284 R   4,3   0,2   0:00.13 jq
 4516 fhem      20   0  120744 103548   8948 S   1,7  10,4   0:21.85 perl
    1 root      20   0    8236   2560   2320 S   1,0   0,3   0:06.45 entry.sh
 4560 fhem      20   0   64980  38200   2308 S   0,0   3,8   0:00.34 perl
 5885 root      20   0    7748   2872   2548 S   0,0   0,3   0:00.19 bash
10454 root      20   0   10304   2720   2312 R   0,0   0,3   0:00.15 top
13248 root      20   0    7616   2656   2416 S   0,0   0,3   0:00.00 health-check.sh
13304 root      20   0    6392    384    340 S   0,0   0,0   0:00.00 sleep
13307 root      20   0    7616   1344   1104 S   0,0   0,1   0:00.00 health-check.sh


Habs jetzt eine Weile beobachtet. Es is immer das gleiche. Sobald die 4 Prozesse dazu kommen, geht die CPU hoch. Obwohl es in top jetzt viel weniger ist als in Portainer angezeigt wird. Die Anzeige in Portainer ist vllt auch nicht genau.

Habe auch mal mein Test und Prodsystem verglichen. Im Prod startet der jq Prozess nicht. Weiß jemand was den Prozess aufrufen könnte? Ich hab ein JsonMod Device. Das habe ich deaktiviert. jq startet trotzdem.

[Wernieman]

jq ist ein shell Programm .... habe noch nie gesehen, das es so viel Last "verbrät", dabei verwende ich es gerne.

Soweit ich weiß (und das ist jetzt bitte nicht sicher *) ), verwendet jsonmod kein jq, sondern arbeitet direkt in perl. Rufst Du eventuell irgendwo jq auf?

*) Stichwort "Gefährliches Halbwissen"

[herrmannj]

Korrekt. Jdonmod verwendet ja nicht

[tobelix]

ich wüsste nicht, dass ich es irgendwo aufrufe. Das Programm kannte ich vorher nicht, musste erst googeln was es macht.
Kann ich irgendwie protokollieren lassen von was es aufgerufen wird?

[kadettilac89]

du hast ein Testsystem. Vielleicht findest du damit die Aufrufliste.

https://wiki.fhem.de/wiki/Strace_verwenden


Die PID von fhem findest du <docker_files>/fhem/log/fhem.pid

Damit das in Docker geht musst du das einschalten sonst bekommst du permission denied o. ä.

Code Auswählen Erweitern

securityContext:
          capabilities:
            add: [ "SYS_PTRACE" ]


[tobelix]

Hat funktioniert. Aber jq taucht im Logfile nicht auf. Daraus schließe ich, dass es nicht von FHEM aufgerufen wird. Da in dem Docker Container ja eigentlich nichts anderes als FHEM läuft, bin ich nun etwas ratlos.
Da es im Produktivsystem ja nicht auftaucht, werde ich denke ich das Testsystem einfach mal neu aufsetzen... ist zwar auch ein bisschen Arbeit, aber ewig den Fehler suchen bringt ja auch nix 

[P.A.Trick]

jq wird im im docker-healtcheck script verwendet. Siehe dazu https://github.com/fhem/fhem-docker/blob/dev/src/health-check.sh . Das sollte mMn aber nicht für die Lastspitzen verantwortlich sein.