[GELÖST]dbLog//mySQL verursachen langsames FHEM

[eldrik]

Hi,

Hast du auch die empfohlenen Indizes auf den Tabellen angelegt?

Greetz
Eldrik

[Pythonf]

Code Auswählen Erweitern

+-----------+--------------+------+-----+-------------------+-----------------------------+
| Field     | Type         | Null | Key | Default           | Extra                       |
+-----------+--------------+------+-----+-------------------+-----------------------------+
| TIMESTAMP | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| DEVICE    | varchar(32)  | YES  |     | NULL              |                             |
| TYPE      | varchar(32)  | YES  |     | NULL              |                             |
| EVENT     | varchar(512) | YES  |     | NULL              |                             |
| READING   | varchar(32)  | YES  |     | NULL              |                             |
| VALUE     | varchar(32)  | YES  |     | NULL              |                             |
| UNIT      | varchar(32)  | YES  |     | NULL              |                             |
+-----------+--------------+------+-----+-------------------+-----------------------------+
7 rows in set (0.00 sec)

mysql> show fields from frontend;
+-----------+-------------+------+-----+-------------------+----------------+
| Field     | Type        | Null | Key | Default           | Extra          |
+-----------+-------------+------+-----+-------------------+----------------+
| ID        | int(11)     | NO   | PRI | NULL              | auto_increment |
| TIMESTAMP | timestamp   | NO   |     | CURRENT_TIMESTAMP |                |
| TYPE      | varchar(64) | YES  |     | NULL              |                |
| NAME      | varchar(64) | YES  |     | NULL              |                |
| VALUE     | text        | YES  |     | NULL              |                |
+-----------+-------------+------+-----+-------------------+----------------+
5 rows in set (0.00 sec)

mysql> show fields from history;
+-----------+--------------+------+-----+-------------------+-----------------------------+
| Field     | Type         | Null | Key | Default           | Extra                       |
+-----------+--------------+------+-----+-------------------+-----------------------------+
| TIMESTAMP | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| DEVICE    | varchar(32)  | YES  | MUL | NULL              |                             |
| TYPE      | varchar(32)  | YES  |     | NULL              |                             |
| EVENT     | varchar(512) | YES  |     | NULL              |                             |
| READING   | varchar(32)  | YES  |     | NULL              |                             |
| VALUE     | varchar(32)  | YES  |     | NULL              |                             |
| UNIT      | varchar(32)  | YES  |     | NULL              |                             |
+-----------+--------------+------+-----+-------------------+-----------------------------+
7 rows in set (0.01 sec)

mysql>


Eigentlich ja.

[Wernieman]

Das können Dir nur die passenden Entwickler beantworten. Sorry, bin "draußen"

[McCavity]

@pythonf: Du schriebst vor ein paar Beiträgen "Charting Frontend" - ich habe FHEM auf einem wesentlich schwachbrüstigeren RasPi laufen (den ich aber auch ganz schön quäle, siehe unten ), aber ebenfalls mit MySQL, DBLog und Charting Frontend (das einzige, was ich zur Performanceverbesserung verändert habe, ist, daß ich statt der SD eine externe Festplatte verwende (die SD ist nur bootdevice).

Frage: hast Du Dein Charting Frontend irgendwo im Browser parallel offen? Speziell die Übersichtsseite mit mehreren Charts und Auto-Update eingeschaltet? Ich habe festgestellt, daß mein FHEM extrem zäh wird, sobald er eine der Grafiken aktualisiert. Ich muß allerdings auch dazu sagen, daß ich mich um die Performance im Moment wenig kümmere, da ich "mein" System noch entwickle. So läuft zum Beispiel auch noch ein Browser (im X-Windows System...), der über HDMI einen Floorplan anzeigt (mit Wetterinformation und einem .jpg von der Webcam), der alle Minute einmal aktulisiert. Solche Spielereien gedenke ich zum Performancegewinn abzuschalten bzw. auszulagern, aber zum Testen läuft momentan halt alles auf einem kleinen RasPi, den ich zu allem Überluß noch nicht einmal übertaktet habe (ich bin da sehr konservativ). Aber obwohl ich den kleinen ganz schön knechte, kommt er mit den meisten Aufgaben recht flüssig zurecht - bis die wirklich Rechenintensiven Plots und Charts drankommen, dann stößt er an seine Grenzen.

Zwischenfrage an die Entwickler (ich habe nicht selbst in den Sourcecode geschaut, da traue ich mich nicht ran ); Kann FHEM eigentlich Multithreading in irgendeiner Form? Mir kommt es so vor als käme es jedesmal in die Bredouille, wenn mehrere Dinge gleichzeitig zu erledigen sind (speziell bei den eh ressourcenhungrigen Grafiken fällt das auf, dann, habe ich den Eindruck, werden auch andere Tasks verzögert (bis zu dem Punkt, daß mein HMLAN sich disconnected, weil der Keepalive nicht rechtzeitig kommt).

Mit diesen Information könntest Du ja mal versuchen, alle Instanzen, die irgendwo auf das Charting Frontend zugreifen, zu schließen - wenn ich das richtig verstanden habe, dürfte das Charting Frontend keine oder so gut wie keine Ressourcen brauchen, wenn es nicht gerade irgendwo angezeigt wird (speziell mit eingeschaltetem Auto-Update auf den Grafiken).

Vielleicht war da ja ein brauchbarer Hinweis drin, ansonsten wäre ich mit meinem Latein auch am Ende...

LG

McCavity

[ojb]

@pah:
Das sollte ironisch gemeint sein, nichts für ungut ... 

[Pythonf]

Nein, es ist nur eine instanz von fhem geöffnet. Und wie schon erwähnt sobald ich dblog deaktiviere läuft es perfekt, daran scheint es also leider nicht zu liegen, denn das charting frontend verwende ich nur selten

[Wuppi68]

logge mal NUR in history und versuche es dann ...
es scheint, das mysql ein wenig länger braucht um current zu aktualisieren

[Wernieman]

und noch eine "Kleinigkeit":

Kannst Du uns bitte geben:
- /etc/mysql/my.cnf
- innoDB oder MyISAM-Tabellen? in mysql "how create table TABELLE;"

Hast Du eigentlich genug Freien Speicher?

[ThorstenH]

Versuche mal, die Tabellen zu löschen und neu zu erstellen. Wenn das wieder eine Zeitangabe hilft, liegt es vielleicht an der Menge der geloggten Daten. Mit jedem insert oder Bull insert müssen die Indizes aktualisiert werden, was je nach Tabellengrösse etwas dauert. Dazu kommt noch das speichern der eigentlichen Daten in der Tabelle.

Ich hatte das schon mal und habe daher dblog deaktiviert. Meines Erachtens sollte dblog die Daten in der Tabelle asynchron zum fhem Main Thread speichern, damit die zeitkritische Verarbeitung von sensordaten, triggern, notifies, usw. nicht negativ beeinflusst werden.

Ich weiß nicht, ob das inzwischen so gemacht wird.