100% CPU Auslastung

Torben · 15 April 2014, 20:27:16

Hallo,
ich habe fast täglich das Problem, dass die CPU-Auslastung meines Odroid U2 mit XUbuntu (3.8.13.19 Kernel) durch fhem auf 100% geht. Als wesentliche Module nutze ich nur Sonos und FB_Callmonitor. Ein System kann ich hinter dem Aufhängen nicht finden, es hat nicht mit bestimmten Aktionen von Sonos oder dem Callmonitor zu tun. Nachdem ich im Forum geschaut habe, habe ich durch strace den Aufruf gefunden, der die Probleme macht. Ich weiß nur nicht, wodurch er aufgerufen wird.

Code Auswählen

sudo strace -p 2449 liefert
Process 2449 attached - interrupt to quit
read(12, "", 256)                       = 0
read(12, "", 256)                       = 0
read(12, "", 256)                       = 0
... (im ms-Takt)

Code Auswählen

ls -l /proc/2449/fd liefert
insgesamt 0
lrwx------ 1 root root 64 Apr 15 05:09 0 -> /dev/null
lrwx------ 1 root root 64 Apr 15 05:09 1 -> /dev/pts/10
lrwx------ 1 root root 64 Apr 15 05:09 10 -> socket:[358476]
lrwx------ 1 root root 64 Apr 15 19:39 12 -> socket:[357509]
lrwx------ 1 root root 64 Apr 15 05:09 2 -> /dev/pts/10
l-wx------ 1 root root 64 Apr 15 05:09 3 -> /opt/fhem/log/fhem-2014-04.log
lrwx------ 1 root root 64 Apr 15 05:09 4 -> socket:[356667]
lrwx------ 1 root root 64 Apr 15 05:09 5 -> socket:[358474]
lrwx------ 1 root root 64 Apr 15 05:09 6 -> socket:[358475]
l-wx------ 1 root root 64 Apr 15 05:09 7 -> /opt/fhem/log/fhem-2014-04.log
lr-x------ 1 root root 64 Apr 15 05:09 8 -> /dev/urandom
lr-x------ 1 root root 64 Apr 15 05:09 9 -> /opt/fhem/log/fritzTelefonbuch.xml

Kann mir jemand anhand der Daten einen Tipp geben?

Schöne Grüße
Torben

P.A.Trick · 15 April 2014, 22:19:24

Steht denn etwas im fhem-2014-04.log ?

Torben · 16 April 2014, 19:29:42

Hallo,

ich habe mal verbose 5 eingestellt und bekomme als letztes:

Code Auswählen

2014.04.16 06:56:26 4: Connection closed for FHEMWEB:192.168.178.62:53302
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53309 GET /fhem/pgm2/style.css
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53310 GET /fhem/pgm2/svg.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53311 GET /fhem/pgm2/fhemweb.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53312 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53313 GET /fhem/pgm2/fhemweb_noArg.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53309 GET /fhem/pgm2/fhemweb_slider.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53310 GET /fhem/pgm2/fhemweb_svg.js
2014.04.16 06:56:26 4: Connection accepted from FHEMWEB:192.168.178.62:53314
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53314 GET /fhem/pgm2/fhemweb_multiple.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53311 GET /fhem/pgm2/fhemweb_textField.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53309 GET /fhem/pgm2/fhemweb_time.js
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53310 GET /fhem/pgm2/dashboard_style.css
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53309 GET /fhem/images/default/fhemicon.png
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53310 GET /fhem/images/default/icoEverything.png
2014.04.16 06:56:26 4: HTTP FHEMWEB:192.168.178.62:53309 GET /fhem?XHR=1&inform=type=status;filter=&timestamp=1397624185650
2014.04.16 06:57:06 4: Connection closed for FHEMWEB:192.168.178.62:53309
2014.04.16 06:57:14 4: Connection closed for FHEMWEB:192.168.178.62:53311
2014.04.16 06:57:14 4: Connection closed for FHEMWEB:192.168.178.62:53313
2014.04.16 06:57:14 4: Connection closed for FHEMWEB:192.168.178.62:53314
2014.04.16 06:57:14 4: Connection closed for FHEMWEB:192.168.178.62:53312
2014.04.16 06:57:14 4: Connection closed for FHEMWEB:192.168.178.62:53310

Der Fehler ist aber wohl gegen 07:10 aufgetreten, wenn ich mir die Prozesslaufzeit ansehe:

Code Auswählen

 PID TTY      STAT   TIME COMMAND
 9189 ?        R    717:27 perl fhem.pl fhem.cfg

Das passt auch etwa zu den Prozessinfos:

Code Auswählen

sudo ls -l /proc/9189/fd
insgesamt 0
lrwx------ 1 root root 64 Apr 16 07:09 0 -> /dev/null
lrwx------ 1 root root 64 Apr 16 07:09 1 -> /dev/pts/5
lr-x------ 1 root root 64 Apr 16 07:09 10 -> /opt/fhem/log/fritzTelefonbuch.xml
lrwx------ 1 root root 64 Apr 16 07:09 11 -> socket:[681026]
lrwx------ 1 root root 64 Apr 16 07:09 2 -> /dev/pts/5
l-wx------ 1 root root 64 Apr 16 07:09 3 -> /opt/fhem/log/fhem--16-2014-04.log
lrwx------ 1 root root 64 Apr 16 07:09 5 -> socket:[678648]
lrwx------ 1 root root 64 Apr 16 07:09 6 -> socket:[678649]
l-wx------ 1 root root 64 Apr 16 07:09 7 -> /opt/fhem/log/fhem-2014-04.log
lr-x------ 1 root root 64 Apr 16 07:09 8 -> /dev/urandom
lrwx------ 1 root root 64 Apr 16 07:09 9 -> socket:[678650]

Strace liefert nun ständig:

Code Auswählen

read(11, "", 256) = 0

robbe · 28 April 2014, 18:18:30

Hallo,

ich hab gestern auf die aktuelle Version aktualisiert und ebenfalls das Problem mit 100% CPU Auslastung. Die Datenbankanbindung habe ich bereits deaktiviert, da ich bei vorherigen Update-Versuchen immer die als Ursache angenommen habe.
Kann es sein, dass vielleicht alte Einstellungen der Grund für das Problem sind? Ich hatte vorher eine ca. 2 Jahre alte Version in Verwendung und musste nach dem Update meine Homematic-Steckdosen neu anlernen damit sie richtig funktioniert haben. Aufgrund der gewachsenen Einstellungsdatei wäre es natürlich praktischer, wenn ich nur anpassen müsste, als alles neu aufbauen.
Verwendet wird bei mir Homepage und Max! auf einem Rechner mit Core2Duo mit Debian 6.

Danke für jeden Hinweis.

Gruß Stefan

:~# strace -c -p 32205
Process 32205 attached - interrupt to quit
^CProcess 32205 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.22 0.000890 0 293241 select
39.78 0.000588 0 293239 read
0.00 0.000000 0 2 write
0.00 0.000000 0 3 stat
------ ----------- ----------- --------- --------- ----------------
100.00 0.001478 586485 total

P.A.Trick · 28 April 2014, 19:30:58

Kannst du mal die Größe der Logs posten?

robbe · 28 April 2014, 19:46:47

Gerne....

insgesamt 685M
-rw-r--r-- 1 root root 3,3K 14. Sep 2013 ActionDetector-2012.log
-rw-r--r-- 1 root root 34K 31. Dez 19:41 ActionDetector-2013.log
-rw-r--r-- 1 root root 30K 28. Apr 18:30 ActionDetector-2014.log
-rw-r--r-- 1 root root 2,0K 27. Apr 20:30 CUL_HM_HM_ES_PMSw1_Pl_24A09B-2014.log
-rw-r--r-- 1 root root 294K 28. Apr 19:43 CUL_HM_HM_ES_PMSw1_Pl_24A09B_Pwr-2014.log
-rw-r--r-- 1 root root 2,0K 27. Apr 20:32 CUL_HM_HM_ES_PMSw1_Pl_24A11A-2014.log
-rw-r--r-- 1 root root 343K 28. Apr 19:44 CUL_HM_HM_ES_PMSw1_Pl_24A11A_Pwr-2014.log
-rw-r--r-- 1 root root 301K 28. Apr 19:44 CUL_HM_HM_ES_PMSw1_Pl_24A160_Pwr-2014.log
-rw-r--r-- 1 root root 590 27. Apr 22:34 CUL_HM_HM_LC_SW1_PL2_1BE4CC-2014.log
-rw-r--r-- 1 root root 885 27. Apr 22:44 CUL_HM_HM_LC_SW1_PL2_1BE6A1-2014.log
-rw-r--r-- 1 root root 885 27. Apr 22:42 CUL_HM_HM_LC_SW1_PL2_1BE945-2014.log
-rw-r--r-- 1 root root 892 27. Apr 22:39 CUL_HM_HM_LC_SW1_PL2_1BF17E-2014.log
-rw-r--r-- 1 root root 892 27. Apr 22:37 CUL_HM_HM_LC_SW1_PL2_1BF18B-2014.log
-rw-r--r-- 1 root root 889 27. Apr 22:45 CUL_HM_HM_LC_SW1_PL2_23D3AC-2014.log
-rw-r--r-- 1 root root 336K 14. Sep 2013 Dim_Kueche-2012.log
-rw-r--r-- 1 root root 2,9M 31. Dez 21:56 Dim_Kueche-2013.log
-rw-r--r-- 1 root root 253K 28. Apr 18:30 Dim_Kueche-2014.log
-rw-r--r-- 1 root root 435K 14. Sep 2013 Dim_Schlafzimmer-2012.log
-rw-r--r-- 1 root root 3,4M 31. Dez 19:09 Dim_Schlafzimmer-2013.log
-rw-r--r-- 1 root root 227K 28. Apr 18:30 Dim_Schlafzimmer-2014.log
-rw-r--r-- 1 root root 3,5M 14. Sep 2013 fenster_bad-2012.log
-rw-r--r-- 1 root root 41M 31. Dez 23:59 fenster_bad-2013.log
-rw-r--r-- 1 root root 14M 28. Apr 19:44 fenster_bad-2014.log
-rw-r--r-- 1 root root 610K 14. Sep 2013 fhem-2012-11.log
-rw-r--r-- 1 root root 1,1M 14. Sep 2013 fhem-2012-12.log
-rw-r--r-- 1 root root 374K 14. Sep 2013 fhem-2013-01.log
-rw-r--r-- 1 root root 1,6M 14. Sep 2013 fhem-2013-02.log
-rw-r--r-- 1 root root 3,7M 14. Sep 2013 fhem-2013-03.log
-rw-r--r-- 1 root root 3,5M 14. Sep 2013 fhem-2013-04.log
-rw-r--r-- 1 root root 2,2M 14. Sep 2013 fhem-2013-05.log
-rw-r--r-- 1 root root 345K 14. Sep 2013 fhem-2013-06.log
-rw-r--r-- 1 root root 321K 14. Sep 2013 fhem-2013-07.log
-rw-r--r-- 1 root root 318K 14. Sep 2013 fhem-2013-08.log
-rw-r--r-- 1 root root 1,3M 30. Sep 2013 fhem-2013-09.log
-rw-r--r-- 1 root root 606K 1. Nov 01:02 fhem-2013-10.log
-rw-r--r-- 1 root root 320K 30. Nov 23:58 fhem-2013-11.log
-rw-r--r-- 1 root root 313K 31. Dez 23:58 fhem-2013-12.log
-rw-r--r-- 1 root root 606K 31. Jan 23:58 fhem-2014-01.log
-rw-r--r-- 1 root root 1,6M 28. Feb 23:59 fhem-2014-02.log
-rw-r--r-- 1 root root 3,7M 31. Mär 23:59 fhem-2014-03.log
-rw-r--r-- 1 root root 6,2M 28. Apr 19:45 fhem-2014-04.log
-rw-r--r-- 1 root root 65K 28. Apr 18:30 fhem.save
-rw-r--r-- 1 root root 8,8M 14. Sep 2013 heizung_arbeitszimmer-2012.log
-rw-r--r-- 1 root root 99M 31. Dez 23:59 heizung_arbeitszimmer-2013.log
-rw-r--r-- 1 root root 34M 28. Apr 19:44 heizung_arbeitszimmer-2014.log
-rw-r--r-- 1 root root 7,1M 14. Sep 2013 heizung_bad-2012.log
-rw-r--r-- 1 root root 83M 31. Dez 23:59 heizung_bad-2013.log
-rw-r--r-- 1 root root 29M 28. Apr 19:44 heizung_bad-2014.log
-rw-r--r-- 1 root root 7,4M 14. Sep 2013 heizung_kueche-2012.log
-rw-r--r-- 1 root root 85M 31. Dez 23:59 heizung_kueche-2013.log
-rw-r--r-- 1 root root 30M 28. Apr 19:44 heizung_kueche-2014.log
-rw-r--r-- 1 root root 8,4M 14. Sep 2013 heizung_schlafzimmer-2012.log
-rw-r--r-- 1 root root 95M 31. Dez 23:59 heizung_schlafzimmer-2013.log
-rw-r--r-- 1 root root 32M 28. Apr 19:44 heizung_schlafzimmer-2014.log
-rw-r--r-- 1 root root 2,0K 14. Sep 2013 max_cube-2012.log
-rw-r--r-- 1 root root 194K 31. Dez 23:58 max_cube-2013.log
-rw-r--r-- 1 root root 58K 27. Apr 20:21 max_cube-2014.log
-rw-r--r-- 1 root root 0 14. Sep 2013 max_eco_schalter-2012.log
-rw-r--r-- 1 root root 6,1K 14. Sep 2013 max_eco_schalter-2013.log
-rw-r--r-- 1 root root 61K 28. Apr 19:44 max_eco_schalter-2014.log
-rw-r--r-- 1 root root 148K 14. Sep 2013 Motion_Flur-2012.log
-rw-r--r-- 1 root root 2,1M 31. Dez 23:44 Motion_Flur-2013.log
-rw-r--r-- 1 root root 708K 28. Apr 19:44 Motion_Flur-2014.log
-rw-r--r-- 1 root root 3,2K 28. Apr 19:19 pw_Arbeitszimmer-2014.log
-rw-r--r-- 1 root root 3,3K 28. Apr 19:05 pw_Kuehlschrank-2014.log
-rw-r--r-- 1 root root 1,8K 28. Apr 18:30 pw_Waschmaschine-2014.log
-rw-r--r-- 1 root root 6,9K 14. Sep 2013 Remote01-2012.log
-rw-r--r-- 1 root root 74K 31. Dez 22:00 Remote01-2013.log
-rw-r--r-- 1 root root 30K 27. Apr 23:44 Remote01-2014.log
-rw-r--r-- 1 root root 218 14. Sep 2013 Remote01_Btn_01-2012.log
-rw-r--r-- 1 root root 1,4K 22. Sep 2013 Remote01_Btn_01-2013.log
-rw-r--r-- 1 root root 0 13. Jan 22:43 Remote01_Btn_01-2014.log
-rw-r--r-- 1 root root 872 14. Sep 2013 Remote01_Btn_02-2012.log
-rw-r--r-- 1 root root 1,9K 22. Sep 2013 Remote01_Btn_02-2013.log
-rw-r--r-- 1 root root 0 13. Jan 22:43 Remote01_Btn_02-2014.log
-rw-r--r-- 1 root root 830 14. Sep 2013 Remote01_Btn_03-2012.log
-rw-r--r-- 1 root root 16K 31. Dez 16:49 Remote01_Btn_03-2013.log
-rw-r--r-- 1 root root 8,1K 27. Apr 23:10 Remote01_Btn_03-2014.log
-rw-r--r-- 1 root root 3,5K 14. Sep 2013 Remote01_Btn_04-2012.log
-rw-r--r-- 1 root root 25K 31. Dez 22:00 Remote01_Btn_04-2013.log
-rw-r--r-- 1 root root 7,1K 27. Apr 23:44 Remote01_Btn_04-2014.log
-rw-r--r-- 1 root root 22K 31. Dez 19:41 Sensor_Arbeitszimmer_Fenster-2013.log
-rw-r--r-- 1 root root 17K 28. Apr 18:30 Sensor_Arbeitszimmer_Fenster-2014.log
-rw-r--r-- 1 root root 22K 31. Dez 11:54 Sensor_Bad_Fenster-2013.log
-rw-r--r-- 1 root root 25K 28. Apr 18:30 Sensor_Bad_Fenster-2014.log
-rw-r--r-- 1 root root 19K 30. Dez 15:31 Sensor_Kueche_Fenster_1-2013.log
-rw-r--r-- 1 root root 23K 28. Apr 18:30 Sensor_Kueche_Fenster_1-2014.log
-rw-r--r-- 1 root root 4,5K 24. Okt 2013 Sensor_Kueche_Fenster_2-2013.log
-rw-r--r-- 1 root root 5,2K 28. Apr 18:30 Sensor_Kueche_Fenster_2-2014.log
-rw-r--r-- 1 root root 12K 14. Sep 2013 Sensor_Schlafzimmer_Fenster-2012.log
-rw-r--r-- 1 root root 77K 31. Dez 11:54 Sensor_Schlafzimmer_Fenster-2013.log
-rw-r--r-- 1 root root 30K 28. Apr 18:30 Sensor_Schlafzimmer_Fenster-2014.log
-rw-r--r-- 1 root root 21K 14. Sep 2013 Sensor_Tuer-2012.log
-rw-r--r-- 1 root root 254K 31. Dez 22:01 Sensor_Tuer-2013.log
-rw-r--r-- 1 root root 103K 28. Apr 18:30 Sensor_Tuer-2014.log
-rw-r--r-- 1 root root 217K 31. Dez 22:00 Sw_Arbeitszimmer_Lmp_Fenster-2013.log
-rw-r--r-- 1 root root 68K 28. Apr 18:30 Sw_Arbeitszimmer_Lmp_Fenster-2014.log
-rw-r--r-- 1 root root 212K 31. Dez 22:00 Sw_Arbeitszimmer_Lmp_Sofa-2013.log
-rw-r--r-- 1 root root 67K 28. Apr 18:30 Sw_Arbeitszimmer_Lmp_Sofa-2014.log
-rw-r--r-- 1 root root 892 27. Apr 22:32 Sw_Kuche_2-2014.log
-rw-r--r-- 1 root root 916K 31. Dez 21:56 Sw_Kueche_1-2013.log
-rw-r--r-- 1 root root 200K 28. Apr 18:30 Sw_Kueche_1-2014.log
-rw-r--r-- 1 root root 79K 14. Sep 2013 Sw_Kueche-2012.log
-rw-r--r-- 1 root root 1,8K 18. Sep 2013 Sw_Kueche_2-2013.log
-rw-r--r-- 1 root root 725K 28. Apr 18:30 Sw_Kueche_2-2014.log
-rw-r--r-- 1 root root 892 27. Apr 22:27 Sw_Kueche_3-2014.log
-rw-r--r-- 1 root root 189K 31. Dez 02:32 Sw_Schlafzimmer_1-2013.log
-rw-r--r-- 1 root root 59K 28. Apr 18:30 Sw_Schlafzimmer_1-2014.log
-rw-r--r-- 1 root root 25K 14. Sep 2013 Sw_Schlafzimmer-2012.log
-rw-r--r-- 1 root root 2,1K 14. Sep 2013 Sw_Schlafzimmer_2-2013.log
-rw-r--r-- 1 root root 88K 28. Apr 18:30 Sw_Schlafzimmer_2-2014.log
-rw-r--r-- 1 root root 808K 28. Apr 18:30 Sw_Schlafzimmer_3-2014.log
-rw-r--r-- 1 root root 934K 14. Sep 2013 Temp_Arbeitszimmer-2012.log
-rw-r--r-- 1 root root 11M 31. Dez 23:59 Temp_Arbeitszimmer-2013.log
-rw-r--r-- 1 root root 3,3M 28. Apr 19:44 Temp_Arbeitszimmer-2014.log
-rw-r--r-- 1 root root 9,0M 31. Dez 23:59 Temp_Aussen_1-2013.log
-rw-r--r-- 1 root root 3,0M 28. Apr 19:44 Temp_Aussen_1-2014.log
-rw-r--r-- 1 root root 737K 14. Sep 2013 Temp_Aussen-2012.log
-rw-r--r-- 1 root root 2,7M 31. Dez 23:58 Temp_Aussen_2-2013.log
-rw-r--r-- 1 root root 2,2M 28. Mär 08:41 Temp_Aussen_2-2014.log
-rw-r--r-- 1 root root 8,3M 31. Dez 23:58 Temp_Bad-2013.log
-rw-r--r-- 1 root root 2,7M 28. Apr 19:44 Temp_Bad-2014.log
-rw-r--r-- 1 root root 8,9M 31. Dez 23:56 Temp_Kueche-2013.log
-rw-r--r-- 1 root root 2,9M 28. Apr 19:44 Temp_Kueche-2014.log
-rw-r--r-- 1 root root 10M 31. Dez 23:58 Temp_Schlafzimmer-2013.log
-rw-r--r-- 1 root root 3,2M 28. Apr 19:43 Temp_Schlafzimmer-2014.log

ph1959de · 28 April 2014, 19:49:43

Bei mir war SYSMON das Problem. Details weiß ich nicht, aber es hat mich einige Zeit gekostet, bis ich das auf dieses Modul zurückführen konnte. Die Meldungen im Log waren nicht wirklich hilfreich.

Falls ihr auch SYSMON benutzt, wäre es vielleicht einen Versuch wert, das mal rauszunehmen (disable=1 hat nicht ausgereicht).

Peter

robbe · 28 April 2014, 19:56:31

Ich habe das in meinem Fall nicht wissentlich aktiviert. Finde auch keine Hinweise dazu in der fhem.cfg

Puschel74 · 28 April 2014, 20:03:00

Hallo,

ZitatFalls ihr auch SYSMON benutzt, wäre es vielleicht einen Versuch wert, das mal rauszunehmen (disable=1 hat nicht ausgereicht).

Dann sollte man das auch so dem Modulautor mitteilen

Das wäre der Beitrag zu SYSMON
http://forum.fhem.de/index.php/topic,17201.315.html
Evtl. wäre dann noch ein Link hier her hilfreich - dann muss nicht alles neu geschrieben und erklärt werden.

Grüße

P.A.Trick · 28 April 2014, 20:05:14

-rw-r--r-- 1 root root 14M 28. Apr 19:44 fenster_bad-2014.log
-rw-r--r-- 1 root root 34M 28. Apr 19:44 heizung_arbeitszimmer-2014.log
-rw-r--r-- 1 root root 30M 28. Apr 19:44 heizung_kueche-2014.log
....

Du solltest mal prüfen, was in diesen Megalogs steht. Vielleicht hast du vergessen event-on-change zu setzen?

robbe · 28 April 2014, 20:11:49

Hi,
diese Logs sollen alle Daten speichern. Die größten Logs habe ich bei der Temperaturmessung und der Heizung. Dadurch kann ich mir die Werte mit einer langen Historie anzeigen lassen. Offen gesagt habe ich bis jetzt noch nichts mit "event-on-change" gemacht. Könnte ich dieses Szenario damit auch abdecken?

P.A.Trick · 28 April 2014, 20:17:58

Naja erst einmal müssen wir dein FHEM entlasten, oder das war doch die Aufgabe?
Wenn du alles mögliche in die Logs schreibst, dann belastet das u.U. FHEM sehr.
event-on-change .* in dem jeweiligen Device als Attribut gesetzt, schreibt dann nur noch Werte hinein wenn sich etwas ändert.
Das andere ist - wie häufig werden die Daten in das Log geschrieben?

robbe · 28 April 2014, 20:21:37

Die 2012er Version hatte mit den Log-Dateien keine Probleme gehabt. RAM habe ich auch noch 3,5 GB frei. Die Probleme treten erst nach einem Update auf. Als ich 2013 mal ein Update probiert hatte war das der gleiche Effekt. Die 100% Auslastung sieht man auch erst nach 12h oder mehr. Jetzt läuft der mit gewohnten 0,x % CPU Auslastung auf einen von 2 Kernen.

Das Update ist notwendig, da ich sonst nicht die neue Homematic Zwischenstecker nutzen kann.

Puschel74 · 28 April 2014, 20:22:34

Hallo,

ich einer "langen History" werden dich vermutlich die ganzen Werte weniger interessieren bzw. sind eher unnötig (meine Meinung!).

Einen Tagesplot schau ich mir mit allen Werten an.
Das geht rauf bis zu einem Wochenplot.
Ab einem Wochenplot interssieren mich nur noch die Tageshöchst-, und Tiefstwerte.
Und alles ab einem halben Jahr schau ich mir nur noch die Monatswerte an.

Was jetzt nicht heisst das ich die überflüssigen Datenbankeinträge lösche

Vielleicht will ich mir ja in einem Jahr (oder wann auch immer) die Werte von heute anschauen - dann nehm ich natürlich wieder die Werte die mir meine Sensoren intervallmässig liefern.

Grüße

robbe · 28 April 2014, 20:27:22

Würde es von Vorteil sein, wenn ich die "Jahresdatei" in "Tagesdateien" splitten lasse? Falls ja, wie könnte ich dies konfigurieren?

Puschel74 · 28 April 2014, 20:28:48

Hallo,

Benutzt du FileLog?
Wobei - das ist egal (mehr oder weniger).

Ich lass eben alles in eine Datenbank loggen.
Für die Plots nehm ich dann die Werte die mir sinnvoll erscheinen.
d.h. es werden dann auch nur! die Werte in der DB abgefragt die ich im Plot sehen will.

FileLog macht für mich persönlich schon länger keinen Sinn mehr da
a) ich heute nicht weiß welche Werte ich morgen in einem! Plot darstellen will (inkl. rückwirkend bis zum define des dbLog)
b) ich nicht mit Tages-, Wochen- ... Logdateien "rumstrampeln" will.

Grüße

Edith: Das soll jetzt aber KEINE! negative Kritik an FileLog sein - auch wenn es sich so lesen lässt.

Edith2:

ZitatWürde es von Vorteil sein, wenn ich die "Jahresdatei" in "Tagesdateien" splitten lasse?

Mit Tagesdateien kannst du dann aber in der Zeit nicht zurück "reisen".

robbe · 28 April 2014, 20:45:29

DB hatte ich gleichzeitig mit Filelog bis zum Update angehabt. Der hat die Plotdaten aber immer aus dem Filelog entnommen.

DB-Login hatte ich durch die folgende Konfiguration aktiviert:
define logdb DbLog ./db.conf .*:.*

Sonst ist überall noch Filelog an. Z.B. hier:
define FileLog_Temp_Aussen_1 FileLog ./log/Temp_Aussen_1-%Y.log Temp_Aussen_1:T:.*

Wie bekomme ich es hin, dass nur noch DB genutzt wird?

robbe · 28 April 2014, 21:09:50

Gibt es eigentlich eine Möglichkeit herauszufinden ob die Logfiles die eigentliche Ursache sind?

Puschel74 · 29 April 2014, 05:33:09

Moin,

ZitatWie bekomme ich es hin, dass nur noch DB genutzt wird?

Indem du die Plotdefinitionen von FileLog auf dein logdb umstellst.
Wie das geht (gehen kann) findest du im SYSMON-Beitrag - dort sind einige Plots für DBLog gepostet.
Die *.gplot-Dateien müssen auch leicht angepasst werden.

Deine FileLog-Definitionen kannst du dann löschen.

Grüße

robbe · 01 Mai 2014, 10:46:37

Hallo,
ich habe bevor ich auf DB umstelle mal folgenden Ansatz gewählt und alle Logdateien gelöscht und neu begonnen. Dadurch sind ja keine Altlasten und riesige Logdateien für das System mehr da. Leider führt es ebenfalls zu den 100% CPU Auslastung nach einigen Stunden. So wie ich das verstanden habe müsste ja das System solange sauber laufen bis die Logdateien zu groß werden. Ist scheinbar hier nicht der Fall und das Problem besteht wohl woanders. Habt ihr zufällig noch weitere Ideen?

Danke

robbe · 10 Mai 2014, 12:00:46

Hier mal ein Erfahrungsbericht was ich gemacht hab...

FHEM neu gezogen und entpackt
Einstellungsdatei neu aufgebaut und alles angelernt.
FileLog umgestellt auf DbLog.

Weiterhin ist nach ca. 3 Stunden die CPU auf 100%.

Update und Co durchgeführt.

Ich behelfe mir jetzt damit, dass ich jede 2h FHEM automatisch neustarten lassen. Nicht schön, aber so geht es.

Puschel74 · 10 Mai 2014, 19:23:44

Hallo,

Zitat robbe

ZitatVerwendet wird bei mir Homepage und Max! auf einem Rechner mit Core2Duo mit Debian 6.

siehe Sig - ich verwende für FHEM einen RasPi.
Ich gehe mal davon das dein System meinem RasPi überlegen ist (logischerweise) aber ich hab keine 100% Auslastung durch FHEM.
Ich hab sqlite3 als DB installiert und logge ALLES von meinen Sensoren in die DB.
Zur Zeit noch über RasPi und USB-HDD aber wenn ich mal mehr Zeit habe wandert FHEM auf mein Cubieboard2 mit SATA-HDD.

Tut mir leid das ich nicht mehr beitragen kann als nur ein
FHEM auf einem RasPi läuft (bei mir und auch bei anderen) einwandfrei.

Grüße

robbe · 18 Mai 2014, 11:38:44

Hallo,

vielen Dank für die Hilfe. Ich glaub ich habe das Problem nun eingrenzen können. Ich habe nun auch einen Raspberry Pi aufgesetzt und hatte ebenfalls das gleiche Problem. Durch den Befehl "apptime max" konnte ich schauen was eigentlich gerade FHEM sperrt. In meinem Fall war es das Max!-Steuerungsmodul. FHEM sieht noch die Verbindung, scheinbar ist diese aber abgerissen. Wenn ich manuell die Verbindung reconnecten lasse ist das Problem direkt wieder verschwunden. Als Workaround lasse ich alle 5 Minuten die Verbindung neu aufbauen. Zudem habe ich die Firmware des Cubes aktualisiert, da meine über 2 Jahre alt ist. Aktuell läuft das System bereits über einen Tag rund, während ich sonst nach 2-3 Stunden die 100% CPU Situation hatte.
Als Datenbank verwende ich auf dem Pi gerade MySQL. Meine alte Datenbank konnte ich aber leider nicht mehr verwenden. Diese hatte einen Umfang von über 1,1 GB und FHEM hat erstmal unendliche Zeit in der DB rumgesucht. Möglicherweise ebenfalls, weil sich über die Zeit irgendwas geändert hat oder die Datenmenge einfach zu groß ist. Mit einer neuen und anfänglich leeren DB geht es bis jetzt problemlos. Jetzt muss sich zeigen ob MySQL auf dem Pi die richtige Wahl ist.

hgw77 · 20 September 2018, 22:43:49

vielen Dank für die Antwort, gerade bin ich auf das gleiche Problem gestoßen. Irgendwie war mein FHEM immer wieder sehr sehr langsam und dann wiederrum reagierte er wieder wie gewohnt "Rattenschnell". Ein Blick in Top zeigte mir das der Fhem immer mal wieder für einige Zeit auf 100% lief und in dieser Zeit einfach nichts reagierte. Sehr schlecht wenn man was in dieser Zeit schalten wollte. Ich schaue mir das jetzt schon eine Weile an und wurde aus der Sache nicht schlau den die eigentliche load auf dem System war im Null-Komma Bereich. Nun habe ich hoffentlich den schuldigen der für dieses Verhalten verantwortlich ist gefunden. Es ist auch hier das MAX Modul. Habe die aktuelle Software auf dem Maxcube drauf und ein regelmäßiger reconnect bringt hoffentlich jetzt Besserung

hgw77 · 22 September 2018, 07:57:19

Leider habe ich das Problem das nach einem reconnect das polling an den maxcube nicht mehr geht. Sprich es kommen keine Daten mehr

Jedoch habe ich jetzt eine andere Lösung für mein Problem. Ich habe die "ondemand" option aus der maxcube defintion entfernt und seitdem scheint sich das Problem mit dem immer langsam werdenen Fhem erledigt zu haben. Dadurch hat zwar der fhem den Cube voll belegt aber da ja bei mir nur der Fhem auf den Cube zugreift kann ich damit leben