Hallo Heiko,
seit einer Weile (8Wochen mindestens) liefern mit die DBReps keine Daten mehr.
Ich hatte mir das Beispiel von dir mit der PV Erzeugung uns Eigenverbrauch letztes Jahr mal nachgebaut, das hatte alle super funktioniert aber seit einer Weile eben nicht mehr.
Das Bringt mir Verbose 5.
2.03.08 16:50:02 1: DbRep Rep.Inverter.Erzeugung.Jahr -> BlockingCall DbRep_getInitData pid:29888 Timeout: process terminated
2022.03.08 16:51:07 3: DbRep Rep.Inverter.Erzeugung.Jahr - get initial structure information of database "fhem", remaining attempts: 2
2022.03.08 16:51:07 3: DbRep Rep.Inverter.Erzeugung.Jahr - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2022.03.08 16:51:07 5: DbRep Rep.Inverter.Erzeugung.Jahr - start BlockingCall with PID "30320"
2022.03.08 16:51:07 4: DbRep Rep.Inverter.Erzeugung.Jahr - Database connect - user: fhemuser, UTF-8 option set: yes
2022.03.08 16:54:07 1: DbRep Rep.Inverter.Erzeugung.Jahr -> BlockingCall DbRep_getInitData pid:30320 Timeout: process terminated
Die DB (MariaDB) liegt schon seit über einem halben Jahr auf einer Externen SSD, die Plots funktionieren auch ohne Probleme.
Hast du eine Idee woran es liegen kann?
Gruß
Max
Hallo Max,
Der parallele Prozess stirbt einfach ohne nähere Info zum Grund nach 3 Sekunden. Nun passiert es bei dir ganz am Anfang wenn die Verbindung zur DB aufgebaut wird, also bei einer ganz unspektakulären Aktion. Das macht es nicht leichter.
Typisch wäre so ein Abbruchverhalten wenn du generell zu wenig RAM verfügbar hast sodass der geforkte Perl Prozess stirbt.
Du könntest mit top auf Betriebssystemebene schauen wieviel Speicher Perl im Normalbetrieb verwendet und ob noch geügend freier Speicher vorhanden ist. Allerdings verwendet auch DbLog und viele andere Module auch parallele Prozesse die m.M. nach auch Probleme haben sollten in diesem Fall.
Grüße,
Heike
Hallo Heiko,
Das werde ich mal prüfen aber ich habe eine pi 4 mit 4gb RAM von denen selten mehr als 1gb belegt ist.
Was soll ich mit Top schauen?
Da sehe ich genau das das eigentlich genug RAM frei ist.
Gruß
Max
Naja, ob fhem (perl) z.B. 1GB benutzt und du hast nur 1,5 GB oder so.
Aber bei 4GB RAM kann da eigentlich kein Problem sein.
Dann findest du vielleicht einen Hinweis in /var/log/messages ?
Lösche doch bei dir mal die Zeile 2163 (mysql_enable_utf8 => $utf8).
Wie sieht es dann bei dir aus ?
Hallo Heiko,
hatte vergessen mir das hier weiter anzuschauen.
Also in Zeile 21635 hatte ich den Eintrag gefunden, war das der richtige?
Jedenfalls habe ich den Auskommentiert aber es hat sich leider nicht verändert.
2022.04.03 16:23:27 1: DbRep Rep.Inverter.Erzeugung.Monat -> BlockingCall DbRep_getInitData pid:28193 Timeout: process terminated
Gruß
Max
Ok, hätte mich ehrlich gesagt auch gewundert.
Wie steht denn das timeout Attribut ?
Das ist auf 180 gesetzt
Na dann stelle es deutlich höher oder lösche es einfach.
Der Standard ist schon lange 86400. Es soll nur dazu dienen dass die Nebenprozesse irgendwann mal abgeräumt werden wenn etwas schief geht.
Hallo Heiko,
Das mit dem Timeout war das Problem.
Kann es sein das die DB einfach zu groß geworden ist und es deswegen länger dauert?
Hatte ja schließlich mal mit den 180s geklappt.
Gruß
Max
Hallo Max,
Zitat
Kann es sein das die DB einfach zu groß geworden ist und es deswegen länger dauert?
Das kann man so global nicht sagen. Meine DB (MariaDB) ist mehr als 5 GB groß und der initiale Verbindungsaufbau dauert
nur ca. 100 ms.
2022.04.07 19:01:54.657 3: DbRep Rep.Dum.Energy - get initial structure information of database "fhem", remaining attempts: 3
2022.04.07 19:01:54.658 3: DbRep Rep.Dum.Energy - Connectiontest to database mysql:database=fhem;host=192.168.2.44;port=3306 with user fhem
2022.04.07 19:01:54.764 3: DbRep Rep.Dum.Energy - Initial data information retrieved - total time used: 0.0056 seconds
2022.04.07 19:01:54.770 3: DbRep Rep.Dum.Energy - Connectiontest to db mysql:database=fhem;host=192.168.2.44;port=3306 successful
LG
Hallo Heiko,
Bei mir dauert dir gesamte Abfrage etwa 5 Minuten.
Sind in deiner DB die Index angelegt ?
Du siehst es mit "set ... index list_all" im DbRep.
Hallo Heiko,
Das lief echt schnell durch.
Hier die Ausgabe.
Index found in database: ======================== Table: history, Idx: Search_Idx, Col: DEVICE, READING, TIMESTAMP
Gruß
Max
Wie lange dauert denn ein "get ... minTimestamp" ?
Das Reading sql_processing_time zeigt es.
Bei mir sind es 0.0036 s.
Bei mir sind es 258.6140, das ist ziemlich lang.
Ja das ist brutal langsam.
Führe bitte im DbRep aus:
set ... index recreate_Report_Idx
Möglicherweise mußt du dafür einen berechtigten User hinterlegen.
Schau dir dazu die HIlfe zum index Befehl an.