Geschwindigkeit MySQL - I/O

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusammen,

    meinem Raspberry Pi betreibe ich nun bereits geraume Weile. Vor allem dient er mir als Webserver für einfache Sachen wie Roundcube und SabreDAV. In letzter Zeit scheint aber der Zugriff immer langsamer zu werden. Da ich eigentlich bis auf Updates seit gut 6 Monaten keine Software installiert habe, vermute ich das dies auf die immer größer werdende Datenbank zurückzuführen ist. Diese ist aktuell noch auf der normalen SD Karte abgelegt, von der der PI auch bootet. Also hab ich heute mal geschaut, wie schnell die SD eigentlich Daten speichern kann. Nach etwas Googlen zu diesem Thema habe ich dann versucht eine Datei auf die SD Karte zu schreiben und die Zeit zu messen. Dazu bin ich in das Webserver Root Verzeichnis gewechselt und bin mit "dd if=/dev/zero of=tempfile bs=1M count=100 conv=fdatasync,notrunc" auf eine Geschwindigkeit von 5,7MB/s gekommen. Wenn ich das richtig sehe, scheint das ein normaler Wert zu sein. Führe ich das mehrmals durch, schwankt der Wert zwischen 3,7MB/s bis 7,5MB/s.

    Über USB sind sowohl ein USB Stick, als auch eine normale HDD angeschlossen. Führe ich den gleichen Befehl auf dem Stick aus, komme ich auf 4,7MB/s und auf der HDD auf 25,9MB/s.

    Rein theoretisch würde das ja bedeuten, das ich das Webroot und die Datenbank auf die HDD auslagern sollte und dann damit um einiges schneller wäre. Aber ist das auch praktisch so? Lohnt sich das? Oder sollte man lieber einen schnelleren USB Stick anstecken und das Webroot + Datenbank dort ablegen? Ich weiß nicht, wo die Gefahr größer ist, das mir eventuell HDD, Stick oder SD Karte wegen zu vieler Schreib/Lesezugriffe irgendwann mal den Dienst verweigern...

    Was würdet ihr empfehlen?

  • 5,7MB/s ist nicht unbedingt ein "normaler" Wert... Wie auch bei SSD's gibts natürlich auch bei SD Karten unterschiedlich schnelle... Meine guten SD Karten schaffen 15MB/s.
    Siehe dazu auch FAQ => Nützliche Links / Linksammlung => Schreib-/Lesegeschwdigkeiten: SD-Karte vs. USB-Speicherstick

    Wenn deine Datenbank langsamer wird und du die Größe vermutest, kann die natürlich schneller werden durch einen schnelleren Datenträger.... Allerdings ignorierst du dann nur ein mögliches Problem, eine Lösung würde vorsehen die Ursache zu finden. Denn was ist wenn deine Datenbank noch größer wird und dann selbst auf deine HDD ablahmt, baust du dann nen Raid um das auszugleichen? :-/

    Entweder deine Datenbank ist defekt, dann repariere sie - das kann nie schaden einfach mal drüber latschen zu lassen ...
    Oder deine Datenbank ist schlecht organisiert, bzw die Tabellen, oder deine Abfragen ....
    Oder dein MySQL ist schlecht/unpassend konfiguriert ...


    PS: NAND-Flash stirbt wegen Abnutzung schneller als Magnetscheiben. Abnutzen tun bei NAND-Flash aber nur Schreibzugriffe.

  • Das die DB größer geworden ist, liegt daran, das zum einen in letzter Zeit aus 1 User nun 7 geworden sind und zum anderen habe ich Datenbanken nochmals geklont und unter anderem Namens als Kopie abgelegt. Hintergrund ist, das ich bevor ich eine neue Version von SabreDAV oder Roundcube aktiv nutze, ich erst mal testen will, ob alle Clients noch damit klar kommen. Ich bin da an der Stelle speziell bei SabreDAV ein gebranntes Kind. Vor allem in Bezug darauf, das nun noch mehr Familienmitglieder SabreDAV nutzen, ist es mir wichtig, das ein Upgrade ohne Probleme über die Bühne geht. Es war schwer genug meine Familie zu überzeugen die anscheinend heile "Google-Welt" zu verlassen und von Alternativen zu überzeugen. Wenn dann da etwas nicht geht, sind die schneller zu Google zurück, als man bis 3 zählen kann und zurück kommt dann mit Sicherheit keiner :) Daher immer erst der Test mit einer Kopie vom aktuellsten Datenbestand, was mehr oder weniger doppelte Daten bedeutet.

    Was die Abfragen betrifft, bin ich gerade wegen der Qualität der Abfragen von NextCloud direkt zu SabreDAV gewechselt. Laut meinen Beobachtungen sind das bei NextCloud noch etliche Abfragen mehr als bei purem SabreDAV. Da ich aber nun kein Programmierprofi bin und auch ehrlich gesagt keine Lust dazu habe, so etwas selber zu beheben, bleibt mir nicht mehr übrig als nach einer aus meiner Sicht besseren Alternative zu greifen. Bei den Entwicklern stößt man zwar nicht gänzlich auf Taube Ohren, denen ist das Problem bewusst, es ändert sich aber nur extrem zäh etwas daran.

    Ansonsten werd ich wohl nicht umhin kommen die MySQL Config zu überarbeiten und anzupassen. Bisher war ich mit der Leistung im Großen und Ganzen eigentlich zufrieden und habe daher nur wenige Anpassungen vorgenommen, auch weil ich keine Extra Tools installieren wollte, um Performancetipps zu MySQL zu bekommen. Gibt ja da das ein oder anderen Tool dafür. Ich bin der Meinung das jede zusätzliche Applikation zumindest potentiell auch eine zusätzliche Quelle für Ärger ist (in welcher Form auch immer). Keep it simple... Zum Anderen ist das System zumindest laut htop eigentlich kaum ausgelastet. Das bewegt sich alles im normalen Bereich von 10 bis maximal 65% im Schnitt, zumindest was Speicher und CPU betrifft. Daher geht meine Vermutung halt in die Richtung I/O Performance.

    Wie auch immer. Mehr User sind jedenfalls keine geplant, das sollte jetzt soweit passen. Klar kommen da mal noch hier und dort Daten hinzu aber für die DB ist das eher Kleinkram. Ob da ein User nun 500 oder 700 Kontakte oder Termine hat, macht kaum einen spürbaren Unterschied. Zumindest seh ich das aktuell so.

    Dennoch würde ich gerne eure Meinung darüber hören, wo ihr Webroot + DB unterbringen würde. Auf direkt auf der SD oder auf einem schnelleren Stick oder auf der HDD... MySQL optimieren, kann ich gerne zusätzlich machen.

    BTW: Als SD kommt eine 16GB Sandisk Extreme® microSD™ UHS-I (SDSQXNE-016G-GN6MA) zum Einsatz. Ich hatte eigentlich gehofft, das die Performance damit recht gut ist, dem scheint aber nicht so zu sein.

  • Ja habe ich. Sehr intensiv sogar. Aber ändert nichts an der grundsätzlichen Frage. OK, dann versuche ich es mal anders: Würdest du selbst meigrafd, bei einem PI der lediglich für Termine und Kontakte Sync da ist Webroot und/oder DB auf HDD auslagern oder USB Stick oder alles auf der SD belassen?

    Files werden pro Tag nur wenige Kilobytes synchronisiert, das fällt kaum ins Gewicht. Diese lagern aber auch auf der angeschlossenen HDD und nicht auf der SD Karte, das hat aber andere Gründe. Mir geht es bei deiner Antwort nur um das Abwägen zwischen reinem Speed und Datensicherheit. Rein theoretisch ahne ich die Antwort aber ich würds dennoch gerne hören. Sorry, wenn das komisch rüber kommt.

    BTW: Ich hab auch überlegt auf DAVical oder Radicale zu wechseln aber das bringt mir nur Nachteile. Radicale schreibt leider alles dateibasiert, die Gefahr das bei einem Verbindungsabbruch die Daten hierdurch korrupt werden, ist mir zu groß. DAViCal hingegen verwendet soweit ich weiß PostgreSQL und ich will eigentlich kein zweites DB System auf dem kleinen Ding haben, nur wegen einer solchen Kleinigkeit. Zum anderen hatte ich bisher mit PostgreSQL noch nie etwas zu tun und scheue den Lernaufwand bezüglich der Konfiguration und Optimierung auf dem Pi.

  • Hallo,

    der Raspi ist nun mal keine Leistungsrakete und kein I/O Wunder, dazu ist die Anbindung der Schnittstellen zu dünn.

    Das ein größer werdenden DB die Raspi bremst kann schon sein. MySQL (und PostgreSQL und Oracle und ...) cachen ja Daten im Speicher. Wenn der knapp wird (was beim Raspi ja rel. schnell geht), dann müssen mehr Daten direkt von der SD geholt werden, was langsamer ist.

    Bei DB-Servern gilt aber auch heute noch: viel hilft viel, besonders beim RAM. Sprich: wenn du Leistung nicht mehr reicht, dann solltest du IMHO eher die Hardware aufrüsten und einen schnelleren Rechner als den Raspi nehmen. Oder, Plan B, die DB auf einen eigenen Raspi das dedizierten DB-Server auslagern, wo nur MySQL drauf läuft. Bei letzterem ist es IMHO aber auch nur eine Frage der Zeit, wann das zu langsam ist.

    Gruß, noisefloor

  • Kannst du etwas zum aktuellen Mengengerüst der DB schreiben?

    Wenn die Performance merkbar nachlässt, deutet das zunächst einmal darauf hin, dass

    • der Speicherzugriff (zu) langsam ist (wobei MySQL/MariaDB versucht, die Daten im Cache zu halten)
    • Indexe fehlen oder suboptimal gesetzt sind: gern wird an den Indexen gespart oder diese nur auf ein Feld gesetzt.
    • Lass dir doch mal von der DB den Zugriffsplan ausgeben, oft sieht man da schon, wo ein "full table scan" gemacht wurde und der geht immer auf die Performance.
    • evtl. auch bestimmte cache-parameter der DB zu knapp sind

    phpmyadmin ist oft eine große Hilfe, zeigt die aktuellen Einstellungen und die Auslastung direkt an.

  • Wie gesagt würde ich erst mal versuchen herauszufinden woran das liegt und wenn ich die Ursache kenne über eine Lösung nachdenken.

    Du schreibst zum Beispiel: Mittlerweile seien es 7 Benutzer
    .... die eine eigene Datenbank haben? Oder wie darf man das verstehen? Wenn jeder Benutzer eine eigene Datenbank hat und Deine Probleme erst seit kurzem auftraten, vielleicht hängt das ja mit einem dieser Benutzer zusammen was der mit seiner Datenbank anstellt?

    Vielleicht ist deine Vermutung, dass die Ursache "auf die immer größer werdende Datenbank zurückzuführen ist" auch falsch? Wenn es schlicht gar nix mit der Datenbank selbst zu tun hat, sondern zB. mit einer sterbenden SD Karte?

    Temporär die Datenbank auszulagern um zu gucken ob es dadurch besser wird, kann jedenfalls nicht schaden.

    Ich versteh aber auch noch nicht die Zusammenhänge wieso du auch "Webroot" verschieben willst, das eine hat mit dem anderen nämlich eigentlich nichts zu tun? :s

  • Sorry, das ich erst jetzt wiederkomme, hatte die letzten Tage zu viel um die Ohren. Nein, natürlich hat nicht jeder seine eigene DB. Mit Usern meinte ich neue User die evtl. auch mal zeitgleich auf den Termine/Kontakte-Sync zugreifen. Alle Nutzen die Nginx+MySQL Kombi mit der gleichen DB und dem gleichen Webroot, es sind lediglich ein paar User mehr. Die Chance das sie zeitgleich etwas tun ist gering aber vorhanden. An eine sterbende SD glaube ich nicht. Die 16GB Sandisk Extreme microSD UHS-I ist vor ca. 6 Monaten neu gekauft wurden. Direkt bei Amazon, vermutlich also auch kein Fake. Ich hoffe mal die Qualität war in Ordnung. Seitdem wurde lediglich das Image neu darauf installiert und sonst halt der normale Betrieb. Hier und da mal ein Update vom System, kaum Belastung durch das Webroot vom Nginx. Wie oft die DB schreibt, kann ich hingegen nicht sagen aber ich nehme mal an, das hält sich in Grenzen.

    Das Webroot will ich nur deswegen mit verschieben, damit noch ein paar Schreibzugriffe/Lesezugriffe mehr wegfallen. Sämtliche Logfiles wandern ohnehin seit Ersteinrichtung in eine Ramdisk. Zweck war es nur das Ganze etwas zu beschleunigen und nach Möglichkeit die Lebensdauer der SD noch weiter zu verlängern.

    Da ich gestern ohnehin etwas am System schrauben musste habe ich mal innodb_buffer_pool_size auf 700 gesetzt. Das hat zumindest gefühlt für eine Verbesserung gesorgt. Ich beobachte das die nächsten Tage nochmal. Falls ich nun keine Seiteneffekte wegen zu knappen Speicher bei Nginx oder PHP habe, lasse ich das so und gut ist. Wenn doch muss ich noch mal anderweitig schauen ob ich an den Einstellungen schrauben kann. Aber bisher habe ich seit ca. 24h keine Probleme feststellen können.

    Am WE hab ich etwas mehr Zeit mich mal mit dem detaillierten Tuning von MySQL zu beschäftigen, dazu fehlt mir in der Woche leider die Zeit.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!