FHEM neu aufgesetzt - Load > 5

Otto123 · 13 Mai 2020, 16:52:09

ZitatIch habe die einzelnen Module und Pakete nach und nach installiert bis die configDB zufrieden

das ist ein dünnes Brett ...

Ich meine, es gibt nicht immer Fehlermeldungen ...

1. verwendete Module in die commandref schauen was die brauchen
2. wenn das nicht reicht: Du kannst Dein altes System nach untersuchen was Du installiert hattest

Nicht ohne Nachdenken alles wieder installieren.

@Beta-User ja sorry - ich habe das damit gleichgesetzt:

Zitat├─10562 /usr/bin/perl fhem.pl configDB
├─10563 /usr/bin/perl fhem.pl configDB
├─10564 /usr/bin/perl fhem.pl configDB

Ist natürlich ein völlig falscher Gedanke - sorry!

Beta-User · 13 Mai 2020, 17:03:44

Hmm, das hatte mich auch erst irritiert, aber wenn man das "kennt" (nicht in der Menge...), ist es "normal" und ich gehe davon aus, dass das hier bei fhem.cfg ganz genauso wäre.

Aber eigentlich macht LogBD die DB auch wieder zu, zumindest, wenn man asynchron unterwegs ist (was afaik die "recommended"-Einstellung für viele Systeme ist). Hier sind es aber auch noch "viele" Datenbanken. Kommt mir komisch vor (müßte mal schauen, meine aber, bei mir ginge alles in eine rein?). Zugangsdaten sind jedenfalls scheinbar vorhanden, das wird es nicht gewesen sein.

Was offensichtlich nicht so recht will, wäre SONOS1. Das dürfte ein Netzwerkprozess sein, was bei "passender" Fehlkonfiguration schon mal gewaltig rumzicken kann. Vielleicht das mal näher beleuchten?

rudolfkoenig · 13 Mai 2020, 17:37:35

ZitatHängt aber vermutlich davon ab, ob es viele zu forkende Defs gibt (alles, was potentiell blocking ist...), und wie schnell da Antworten kommen (z.B. bei externen HTTPMODs).

Ich weiss zwar nicht, was "externer HTTPMOD" ist, aber HTTPMOD forkt nicht, soweit ich es sehe.
Das verwendete HttpUtils_NonblockingGet ist "single-threaded".
Sonst schaue ich nur zu, und staune, ohne eine Idee zu haben

Beta-User · 13 Mai 2020, 17:53:46

@Rudi: Danke für die Klarstellung. (Bedeutet, man sieht ein HttpUtils_NonblockingGetauch nicht in der Prozessliste?).

Bei mir taucht jedenfalls hin und wieder ein weiterer Prozess auf, aber das ist tatsächlich DBLog, soweit ich das beurteilen kann. Aber eben EIN weiterer Prozess, nicht einige weitere Prozesse.

(Ich hätte hier auch nichts geschrieben, wenn nicht was mMn. völlig falsches unter Verdacht genommen worden wäre...).

rudolfkoenig · 13 Mai 2020, 18:05:20

ZitatBedeutet, man sieht ein HttpUtils_NonblockingGet auch nicht in der Prozessliste?

Korrekt, es handelt sich dabei um FHEM-Interne Datenstrukturen, es wird ueber das Haupt-Select realisiert.
BlockingCall/fork ist nur dann berechtigt, wenn man viel Rechnen muss, alles andere ist Workaround oder "Bequemlichkeit".

valvak · 13 Mai 2020, 18:30:13

Also ich habe mal weiter rumprobiert

Sonos deaktiviert hat augenscheinlich erstmal keine Besserung gebracht. Allerdings hat ein disable auf alle DbLogs den Load langsam runterklettern lassen.

Habe dann eine Datenbank nach der anderen wieder eingeschaltet und ein "reducenbl 90 average" abgesetzt. Ich weiss nicht was ihn da gestört hat aber damit hab ich den Load wieder in den Griff bekommen.

Dafür kenn ich mich aber zu wenig mit Datenbanken aus was Backup/Restore betrifft. Hab bisher immer direkt die ganze Karte kopiert, nie nen DB Restore.

Ich überlege jetzt das Logging auf meinen NAS auszulagern.

Bin mit dem Thema aber noch nicht durch. Wenn ich das richtig sehe ist weiterhin 2-3x fhem.pl auf.
Aber vielleicht interpretier ich das nur falsch

Otto123 · 13 Mai 2020, 18:37:30

Mein Rat wäre: Auf SD Card keine Datenbanken betreiben. configDB ist eventuell ok da wird vielleicht nicht oft geschrieben, ich weiß es aber nicht.
DbLog schreibt aber ständig auf die gleiche Stelle. Das kann für SD Card nicht gut sein.

Entweder extern NAS oder auf eine HDD / SSD

mehrere fhem Prozesse sind mE relativ normal.

rudolfkoenig · 13 Mai 2020, 18:50:04

Ich wuesste gerne, was Leute, die nach eigenen Angaben sich nicht mit DB auskennen, motiviert, statt auf Dateien auf Datenanken zu setzen.

Beta-User · 13 Mai 2020, 20:00:59

Na ja, habe da so eine Vermutung: Kommt auch nicht mehr drauf an...
Wir beschäftigen uns ja im FHEM-Kontext mit allem möglichen, mit dem wir uns nicht wirklich auskennen. Linux. Perl. FHEM. Microcontroller. Perl. Datenbanken.

(Mein Plan ist, für Einsteiger ohne DB-Erfahrung deutlich davon abzuraten, schon gleich auf dem Pi.)

Was mich zusätzlich interessieren würde: Warum so viele DBLog-Devices. Ich habe das auch im Einsatz, aber eben EINES. Das macht für mich auch den Reiz aus: Es ist EIN Event-Handler, den man passend konfigurieren muß (ich habe immer noch gerne "alles beeinander" und würde vielleicht sogar auf FileLog zurückgehen, wenn man das eher als "dispatcher" für alles mögliche einsetzen könnte.)

@Otto123: Du solltest dich wirklich mal mit configDB auseinandersetzen. Bin noch unschlüssig, ob ich Einsteigern (sachte) nahelegen soll, ebenfalls eine sqlite-configDB-Lösung einzusetzen. Es wird nur gespeichert, wenn es was zu speichern gibt. Will sagen: SAVE + filewrite-Anweisungen (insbes. für Konfigurationsdaten mancher Module, .gplot-files usw.. So hat man bei einem Umzug auch alles beieinander und muß nichts zusammensuchen).

valvak · 13 Mai 2020, 21:45:47

Zitat von: Beta-User am 13 Mai 2020, 20:00:59
Was mich zusätzlich interessieren würde: Warum so viele DBLog-Devices. Ich habe das auch im Einsatz, aber eben EINES.

Ich hab das vor Jahren mal wegen den Plots gemacht. Ich fand die riesigen Dateien irgendwie nicht schön. Ja wieso so viele?! Keine Ahnung.
Die DEF für den DbLog für Temperatur ist schon so lang, ich find es kacke wenn da jetzt auch noch der Kram von dem Raspberry und DutyCycle mit drin ist. Oder wie kann man das besser regeln?

Code Auswählen

./dblog/dbtempfeucht.conf (ATemp_Mittelwert|ATemp_Mittelwert14|Temp_Heizung_.*|Temp_WW_.*|Aussentemperatur|raspHOME_Kasten|Garagentor|RaumTemp_Mittelwert|.*_Heizung.*|.*Sensor_Klima):(temperature|humidity|pressure|4.ACTUAL_TEMPERATURE).*

valvak · 13 Mai 2020, 21:49:19

Zitat von: rudolfkoenig am 13 Mai 2020, 18:50:04
Ich wuesste gerne, was Leute, die nach eigenen Angaben sich nicht mit DB auskennen, motiviert, statt auf Dateien auf Datenanken zu setzen.

Und grundsätzlich bin ich sehr technikaffin, durch die Techniker-Weiterbildung auf Abendschule hab ich auch grundsätzlich schon etwas Ahnung von SQL Statements. Nur eben echt wenig Datenbankverständnis wenn es riesige Datenbanken werden. Aber ich arbeite mich gern ich Sachen ein.

Das ist auch der Grund wieso ich hier bin und nicht bei openHab/iobroker. Ich habs mir abgeguckt, aber das ist mir zu sehr fern von C/C++. Ich fühl mich hier wohler. Man kann mehr tun und bekommt nicht alles serviert

rudolfkoenig · 13 Mai 2020, 21:52:48

Bitte nicht falsch einsortieren: ich meinte es nicht abwertend, ich suche die Motivation, in der Art: eine DB muss doch schneller/stabiler/etc sein.

Beta-User · 14 Mai 2020, 11:18:20

Auch von meiner Seite ist das durchaus ernsthaft gemeint.

Wenn ich das hier lese

Zitat von: valvak am 13 Mai 2020, 21:45:47
Ich hab das vor Jahren mal wegen den Plots gemacht. Ich fand die riesigen Dateien irgendwie nicht schön. Ja wieso so viele?! Keine Ahnung.
Die DEF für den DbLog für Temperatur ist schon so lang, ich find es kacke wenn da jetzt auch noch der Kram von dem Raspberry und DutyCycle mit drin ist. Oder wie kann man das besser regeln?

Code Auswählen Erweitern
./dblog/dbtempfeucht.conf (ATemp_Mittelwert|ATemp_Mittelwert14|Temp_Heizung_.*|Temp_WW_.*|Aussentemperatur|raspHOME_Kasten|Garagentor|RaumTemp_Mittelwert|.*_Heizung.*|.*Sensor_Klima):(temperature|humidity|pressure|4.ACTUAL_TEMPERATURE).*

kann ich das teils gut nachvollziehen:
Für jedes einzelne Device ein eigenes FileLog-Device und eine Vielzahl von kleinen Logfiles ist irgendwie auf den ersten Blick irritierend. Also neigt man dazu, zumindest ein paar Devices in eine größere file umzuleiten.
Das führt dann aber irgendwann dazu, dass das ganze beim Plotten zäh wird, man hat nur leider die Ursache dafür vergessen (bzw. kennt sie nicht). Dazu kommt, dass das plotreplace-feature nicht so groß beworben wird, so dass die Handhabung von "gemischten" Plots auch teils sehr unkomfortabel ist, weil man dann eine Ladung Plotfiles für jeden "Kleingruscht" braucht...
Kurz: Das ist nicht sehr übersichtlich. (Eine gute Idee, wie man das ggf. verbessern könnte, habe ich aber derzeit auch nicht anzubieten).

Die (vermutete) Vorgehensweise von @valvak, die "Groß-FileLog-Definitionen" 1:1 mit LogDB-Definitionen zu ersetzen, kann ich allerdings nicht nachvollziehen. DBLog ist nach meinem Verständnis grade "andersrum" gestrickt: per default wird _alles_ und ungefragt in _eine_ Datenbank geloggt. "Alles und ungefragt" ist mMn. suboptimal, aber warum nicht alles in eine Datenbank?
So, also mit einer einzigen Datenbank läuft das jedenfalls bei mir, (allerdings mit viel "DbLogExclude", was man immer bei neuen Devices auch nochmal absichern muß (es gibt da irgendwo auch einen Automatismus zum automatischen Exklude, den man aber finden muß). Die devspec sieht entsprechend noch viel "krautiger" aus, weil ich auch erst mal "sprechende Namen" für die Devices gewählt habe und bis heute nicht sicher sagen kann, ob das eine gute Idee war oder nicht...

(Insgesamt beschleicht mich hier der Verdacht, dass sehr viel mehr geloggt wird, als @valvak annimmt).

@valvak: Ich würde daher Rudi zustimmen, dass es vermutlich sinnvoller wäre, wieder mit FileLog zu arbeiten, das dann aber besser zu splitten und "plotreplace" genauer anzuschauen.
Wenn du die DB-Lösung umziehen wolltest (was definitiv besser wäre, als es auf dem Pi weiter zu betreiben, und wenn: bitte unbedingt die entsprechenden Optimierungsmöglichkeiten bei DBLog ansehen!), solltest du vorab nochmal die Experten fragen, ob nicht eine Datenbank dann die bessere Lösung wäre.

Otto123 · 14 Mai 2020, 11:34:43

Zitatdie Motivation, in der Art: eine DB muss doch schneller/stabiler/etc sein.

Und mMn ist eine DB auf ein und derselben Maschine nicht schneller als ein FileLog, im Gegenteil wenn man blöd geloggt hat ist es viel langsamer. Ich habe da ein paar Wochen rumprobiert, war interessant

aber der Aufwand wenn man es gut machen will ...

Aber jetzt ist die DB einmal da und die DEFs auch, da ist umziehen sicher einfacher und keine schlechte Idee.

Beta-User · 14 Mai 2020, 11:37:08

Zitat von: Otto123 am 14 Mai 2020, 11:34:43
Aber jetzt ist die DB einmal da und die DEFs auch, da ist umziehen sicher einfacher und keine schlechte Idee.

...nur dass damit noch nicht geklärt ist, ob die DEFs "gut" sind

. Ich würde fast wetten, dass nicht, und dass der TE daher sowieso nochmal neu nachdenken+konfigurieren muß. Von daher (ernsthaft): warum nicht "back to the roots"?