Abend!
Da ich meine Schachtelwirtschaft (Raspies) leid bin, habe ich meine Anwendungen auf meinem NAS konzentriert. Hierbei handelt es sich um einen passiv gekühlten I5 mit 8GB Speicher, also ausreichend groß :-)
Da ich auch noch andere DB-lastige Anwendungen habe, und die VOrteile des NAS voll ausspielen wollte, habe ich nun auf MySQL umgestellt. Die ca. 6Mio Einträge aus den letzten 3 Jahren SQLIte-DB hab ich bereits migriert.
Das Ergebnis ist ein Performancedisaster...Und nebenbei eines, welches ich nicht deuten kann. Top scheint recht unauffällig:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2857 mysql 20 0 310m 159m 6236 S 0,0 3,9 11:31.48 mysqld
2713 fhem 20 0 39300 23m 4624 S 0,0 0,6 0:05.98 perl
4577 admin 20 0 4988 1376 1012 R 0,0 0,0 0:01.53 top
18 root 20 0 0 0 0 S 0,0 0,0 0:00.15 kworker/3:0
2209 root 20 0 29104 1524 1096 S 0,0 0,0 0:00.35 rsyslogd
Ich habe trotz Suche nur einen Thread in den Anfängerfragen gefunden. Der hilft mit nur leider nicht wirklich weiter...Einzige Maßnahme darin heißt: DB leeren, und das will ich ja nun gerade NICHT.
Kann jemand helfen?
Danke und Grüße, Andi
Edit:
Disaster bedeutet - Seiten laden extremst langsam bis gar nicht. Ein KNX-Telegram braucht einige zig Sekunden, bis es rausgeht. Eine Umstellung zurück auf SQLite bringt abhilfe. Aber verstehen tu ich es nicht. Und lösen auch gerne :-)
Das Modul DbRep hat eine exportToFile und importFromFile Funktion, möglicherweise kannst Du damit die Daten von der einen in die andere DB transportieren.
Gruß!
Hm - das hab ich bereits anders erledigt.
Mein Problem ist schlicht, das FHEM in meiner Konfiguration nicht sauber auf MySQL läuft. Und ich hab grad null Ansatzpunkte, das einzugrenzen...
die Standard-Fragen bei lahmer DB:
- richtige storage engine ausgewählt?
- passende Indizes gesetzt?
- mal einen lahmen query mittels EXPLAIN profiled?
cheers,
-Christian
Es ist wahrscheinlich ein lange vorhandenes Problem wie das DbLog Modul arbeitet, siehe aktuelle Diskussion hier:
https://forum.fhem.de/index.php?topic=62626 (https://forum.fhem.de/index.php?topic=62626)
@Loredo: Merci - dann wird ja dran gearbeitet. Da bin ich guter Hoffnung...
@Christian: Du hast mich jetzt recht rasant abgehangen...Gibt's irgendwo einen "Referenzthread" in dem die von Dir genannten Maßnahmen weiter erläutert sind?
Hallo Andi291,
ich setze mich auch gerade mit der Log-Funktion des DbLog-Modula auseinander und habe hier https://forum.fhem.de/index.php/topic,62998.msg544482.html#msg544482 (https://forum.fhem.de/index.php/topic,62998.msg544482.html#msg544482) einen Diskussionsthread dazu aufgemacht. Loredo hat dich ja auch schon auf einen Link hingeweisen.
Ich betreibe die MySql auch auf einem Synology NAS und in der DB sind natürlich noch anderen DB's zusätzlich zu FHEM-Datenbanken enthalten.
Mit dem abgewandelten Modul in dem Link habe ich bei mir eine erhebliche Schreibbeschleunigung feststellen können.
Kannst ja auch mal testen ob du Vorteile erzielst.
Allerdings habe ich auf dem NAS auch DB-Parameter angepasst und verwende zur Analyse dieses Perl-Programm http://mysqltuner.com/ (http://mysqltuner.com/).
Es gibt dir Parameterempfehlungen. Vielleicht hilft auch das weiter.
Meine NAS siehst du in der Signatur. Ich habe den RAM auch auf 8GB gepimpt.
Gruß
Heiko
Zitat von: Andi291 am 20 Dezember 2016, 20:38:16
Die ca. 6Mio Einträge aus den letzten 3 Jahren SQLIte-DB hab ich bereits migriert.
Verrätst du uns wie? :)
Aber ja:
https://www.easyfrom.net/de/ (https://www.easyfrom.net/de/)
Version 8.2.07
Grüße, Andi
Hi zusammen,
habt ihr für mich Referenzwerte für eure "schnelle" Datenbank?
Bin hier auch etwas enttäuscht, habe die letzten Tage von FileLog auf DBLog migriert (über 23 Mio Einträge auf 6 Monate). Nun steht die Kiste :D
Aber kurz zu den Daten:
- Ras. Pi 3
- 1 GB RAM
- SDHC Karte für OS
- SSD über USB für /daten (z.B MySQL)
- importiert wurden gut 23 Millionen einträge (die letzten 6 Monate)
- hierbei konnte ich nach genaueren überprüfen ca 9 Millionen löschen
- innodb File hat ca 6 GB, exportierte Datenbank hat 1.2 GB.
- folgende DB Settings wurden schon etwas in die höhe korrigiert:
- innodb_buffer_pool_size = 256M
- query_cache_type = 1
- query_cache_limit = 2M
- query_cache_size = 64M
Wenn ich nun einen count(*) auf die History mache beispiel Monat August letzten Jahres, dauert dieses 1 Minute 20 Sekunden, bei ca 1.2 Mio Einträgen. MYSQL läuft in dieser Zeit auf 100% CPU last, ist nicht mal die SSD, hier ist der CPU am Anschlag. Dadurch habe ich stark die Vermutung, das ich wohl bei FileLog bleiben muss, bzw vielleicht nur teils teils.... Oder habt ihr einen Tip, das auf dem Ras. Pi auch erfolgreich zu betreiben? Wieviel Readings, Devices, Daten habt ihr in eurer Datenbank?
Einzelne GPlots die ich schon auf DBLog umgestellt haben, brauchen nun ca 5-10 mal so lange wie bei der FileLog... was auch nicht weiter verwunderlich ist, wenn die MYSQL die Daten nicht schneller bringt.
Besten Dank im vorraus....
Hallo Kaufe,
meine MySQL läuft auf einer Synology 415+, ist also nur nicht wirklich mit einem Raspi vergleichbar. Aber nur zur Info dauert der count(*) bei rund 4,5 Mio Datensätzen ca. 2 bis 4s.
Die Parameter sind zur Zeit:
innodb_buffer_pool_size = 300M
innodb_log_file_size=75M
innodb_additional_mem_pool_size = 24M
key_buffer_size = 10M
sort_buffer_size = 512K
read_buffer_size = 512K
read_rnd_buffer_size = 512K
query_cache_limit = 4M
query_cache_size = 64M
max_allowed_packet = 2M
table_open_cache = 1024
key_buffer = 256M
thread_cache_size = 4
join_buffer_size = 256K
Aber wenn du magst kannst du in diesem Thread
https://forum.fhem.de/index.php?topic=65860.new;topicseen#new
an Performancethemen mitwirken. JoeAllb hat sich eine recht umfangreiche Laborumgebnung aufgebaut.
Er kann sicherlich bessere Vergleichswerte mit dem Raspi beisteuern.
Grüße
Heiko
Dann kann das hier geschlossen werden? Die Lösung des anderen Thread sind scheint zu funktionieren, oder?
Hallo zusammen,
super danke, wir haben "mein" Problem im anderen Thread gelöst. Also wegen mir, müssen wir den Thread nicht offen halten.
@DS_Starter, danke für deine Werte.... helfen mir schon mal weiter beim tunen.