Performance: Raspberry Pi SD-Karte & MySQL - KEINE gute Kombination

[Elektrofreak]

Hallo zusammen,

ich möchte mit euch ein paar Erfahrungen teilen, die Anderen vielleicht vor so manchem Problem verschonen könnten.

Zunächst einmal möchte ich mein Setup vorstellen, das ich bis letzte Woche verwendete. Ich habe ein Rapsberry Pi 3 mit einer 16GB micro-SD-Karte verwendet. FHEM lief mit einer MySQL-Datenbank und nur wenigen dbInclude-Einträgen (standartmäßiges logging deaktiviert). Damit dache ich, würde ich ein performantes System bekommen.

Nach knapp 6 Monaten die Ernüchterung: Das Betriebssystem wirft die SD-Karte bei den Backups aus. Das Dateisystem macht Probleme. Ich kontrolliere via iotop den Schreibzugriff auf die SD-Karte und stelle fest, dass ich durchschnittlich(!) zwischen 40 und 99% Auslastung der SD-Karte habe. Der Übeltäter ist der MySQL-Server.

Nun habe ich folgende Modifikationen gemacht: Zunächst habe ich eine neue SD-Karte verwendet und ein Backup eingespielt. Danach habe ich den MySQL-Server und alles Weitere deinstalliert, was ich nicht gebraucht habe. Außerdem habe ich eine RAM-Disk und ein wenig sicherheits-swap eingerichtet und den swappiness-Faktor stark heruntergesetzt, sodass nur im Notfall geswappt werden sollte. Nachdem ich einen softlink für das log-Verzeichnis und die Datenbank auf die RAM-Disk gelegt habe und ein Script zum sichern der RAM-Disk eingerichtet habe, konfigurierte ich FHEM für den Betrieb der SQLite-Datenbank um. Zu guter Letzt habe ich das event-min-interval-Attribut verwendet, um Datenbankzugriffe zu reduzieren.

Was soll ich sagen: es läuft viel schneller und mit deutlich weniger Schreibzugriffen. Die Verwendung von MySQL war wohl in Bezug auf die Schreibzugriffe keine gute Idee (soll ca. 6x so viele Zugriffe durchführen wie SQLite). Eine RAM-Disk ist gar nicht so schwierig und wird die Lebensdauer der SD-Karte sehr stark erhöhen. Man muss nur schauen, dass diese nicht voll wird. Ich habe jetzt erst einmal 512MB erlaubt. Gebraucht werden wenige MB pro Tag (viele davon nicht von der SQLite-DB sondern vom log).

Ich würde mich über eure Erfahrungen in dieser Hinsicht freuen und hoffe, gute Anregungen für andere Raspberry Pi-Benutzer geben zu können 

[Wernieman]

Es dürfte an "wenig-Speicher" des RasPi liegen, das mysql dir solche Probleme bereitet. Da ist eben der Vorteil von sql-light.

Nur ... gerade "wenig-Speicher" und Ramdisk .. sind nicht so meine Empfehlung. Zusätzlich bekommt man bei einem Crash keine Logdaten mehr (Wichtig!). Wenn man das aber im Hinterkopf hat, ist es kein Problem ..

[Elektrofreak]

Nur ... gerade "wenig-Speicher" und Ramdisk .. sind nicht so meine Empfehlung.

Genau, das ist ein ganz wichtiger Punkt. Ich habe aus diesem Grund auch einen swap erlaubt, obwohl der eigentlich kontraproduktiv ist. Er erhöht nämlich die Anzahl der Schreibzyklen der SD-Karte (aber reduziert sie merklich gegenüber SQLite direkt auf der SD-Karte). Dazu kommt, dass der Raspberry Pi 3 1GB RAM hat und im Normalbetrieb nur 160MB RAM benötigt werden. Es sind also noch gute 800MB frei, die von der RAM-Disk oder anderen Programmen belegt werden können.

Zusätzlich bekommt man bei einem Crash keine Logdaten mehr (Wichtig!). Wenn man das aber im Hinterkopf hat, ist es kein Problem ..

Das ist natürlich auch klar, war aber bis jetzt noch kein Problem. Man kann ja auch im Notfall die log-Dateien wieder auf der SD-Karte ablegen anstatt in der RAM-Disk. Im Normalbetrieb brauche ich das aber nicht und 1x Sicherung der Logs pro Tag reicht mir aus.

[Wernieman]

Ich weiß nicht, ob mysql für "nur 800MByte Speicher"  optimiert ist. Normalerweise haben DB-Server deutlich mehr (Wenn es nicht gerade eine mißbrauchte NAS ist ;o) )

bezüglich SWAP:
Meistens ist der io-Speicher um den Faktor 1000 langsamer als der RAM. Ein Server, der in den swap gerät, ist deshalb meistens nicht mehr produktiv. Aktuell wird swap nur eingerichtet, damit der Admin sich noch einloggen kann um den Server zu retten.

Blöderweise braucht man meistens die Logfiles, wenn man es nicht erwartet hatte. Wenn man es wieder "anschaltet" ist der Crash schon vorbei ... aber eventuell ist dieses auch eine "Berufskrankheit" meinerseits ;o)

[Jorge3711]

Grundsätzlich kann ich deine Beobachtung nicht teilen. Ich habe FHEM auf einem RPI 2 laufen inkl. MySQL auf dem gleichen Host. Das ganze läuft auf einer 16 GB SD-Karte. Meine ältesten Einträge in der history stammen von 10/2015. In die DB loggen 26 Devices, insgesamt habe ich ~4,2 Millionen Zeilen in der history und das System schurrt wie ein Kätzchen. Ich kann mit iotop keine Auffälligkeiten feststellen.

Ich habe eben ein "set logDB count" gemacht um die Zahlen zu aktualisieren. Während dieses Aufrufs verursachte die DB ca. 35% IO auf dem System und sank wieder auf 0% nach Abschluss der Abfrage.

[Elektrofreak]

Grundsätzlich kann ich deine Beobachtung nicht teilen. Ich habe FHEM auf einem RPI 2 laufen inkl. MySQL auf dem gleichen Host. Das ganze läuft auf einer 16 GB SD-Karte. Meine ältesten Einträge in der history stammen von 10/2015. In die DB loggen 26 Devices, insgesamt habe ich ~4,2 Millionen Zeilen in der history und das System schurrt wie ein Kätzchen. Ich kann mit iotop keine Auffälligkeiten feststellen.

Ich habe eben ein "set logDB count" gemacht um die Zahlen zu aktualisieren. Während dieses Aufrufs verursachte die DB ca. 35% IO auf dem System und sank wieder auf 0% nach Abschluss der Abfrage.

Ich vermute, dass die hohe iotop-Auslastung ggf. durch die defekte SD-Karte ausgelöst wurde (da das OS versucht, auf nicht defekte Sektoren zuzugreifen). Ich könnte die Sicherung testweise nochmal auf der Austauschkarte, die ich in ein paar Tagen vom Händler bekommen sollte, aufspielen.