100% CPU Auslastung

[Puschel74]

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:

Wü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]

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]

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

[Puschel74]

Moin,

Wie 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]

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]

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]

Hallo,

Zitat robbe

Verwendet 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]

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]

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]

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