Simone: Innodb Performance

Hallo,

Ich betreibe eine größere Website. Mit steigenden Besucherzahlen habe ich in den letzten Jahren immer wieder die Seite / Quelltext MySQL optimieren müssen. Seit ca. 3 Wochen arbeitet ein Cluster bestehend 4 Server und ein Datenbankserver MySQL um die Abfragen abdecken zu können.
Der serverload der Cluster ist ok und hat auch noch Platz ...
Leider steigt jetzt der Datenbankserver in Spitzenzeiten immer wieder aus.
Die dB Abfragen lassen sich nicht weiter optimieren.

Jetzt denke ich über ein Umstieg auf inno dB nach.
Was würde ihr als Alternatives Datenbanksystem empfehlen.

Danke Sinone

  1. Tach!

    Leider steigt jetzt der Datenbankserver in Spitzenzeiten immer wieder aus.
    Die dB Abfragen lassen sich nicht weiter optimieren.
    Jetzt denke ich über ein Umstieg auf inno dB nach.

    Ich bin skeptisch, dass ein Wechsel der Engine den entscheidenden Performance-Gewinn bringt, so dass der Server wieder ausreichend Platz hat. Du solltest das aber zunächst im Labor nachstellen und dann mit Tools wie Apaches "ab" messen, ob sich die Anzahl der Requests pro Zeiteinheit steigern lässt.

    Was würde ihr als Alternatives Datenbanksystem empfehlen.

    Vielleicht einfach nur auch da clustern. MySQL bringt ein nicht allzuschwer aufzusetzendes Replikatonssystem mit. Damit lassen sich zumindest die Lese-Abfragen recht einfach verteilen.

    Ansonsten sollten sich doch zumindest ein paar sicher eher allgemein gehaltene Performance-Benchmarks im Netz finden lassen. Wenn dir dabei ein System ins Auge fällt, das angeblich besser abschneidet, dann versuch es in deinem Labor einzubinden und miss die Unterschiede unter deinen konkreten Bedingungen nach. Vielleicht ergibt sich dann ein ähnliches Bild wie im Benchmark oder auch ein ganz anderes.

    dedlfix.

    1. Moin!

      Leider steigt jetzt der Datenbankserver in Spitzenzeiten immer wieder aus.
      Die dB Abfragen lassen sich nicht weiter optimieren.
      Jetzt denke ich über ein Umstieg auf inno dB nach.

      Ich bin skeptisch, dass ein Wechsel der Engine den entscheidenden Performance-Gewinn bringt, so dass der Server wieder ausreichend Platz hat. Du solltest das aber zunächst im Labor nachstellen und dann mit Tools wie Apaches "ab" messen, ob sich die Anzahl der Requests pro Zeiteinheit steigern lässt.

      Ein Wechsel der Storage-Engine kann enorm viel Potential haben, oder auch nicht. MyISAM hat kein vernünftiges Locking implementiert, jeder Schreibzugriff in einer Tabelle sperrt die gesamte Tabelle für parallele Lesezugriffe. Wenn also gleichzeitig geschrieben und gelesen wird, ist das hinderlich, und InnoDB mit seinem Locking auf Datensatzebene ist da deutlich besser geeignet.

      Was würde ihr als Alternatives Datenbanksystem empfehlen.

      Vielleicht einfach nur auch da clustern. MySQL bringt ein nicht allzuschwer aufzusetzendes Replikatonssystem mit. Damit lassen sich zumindest die Lese-Abfragen recht einfach verteilen.

      Replikation löst das Problem nicht, bietet aber eine Methode an, drumherum zu arbeiten. Wenn man die Einschränkungen der Lösung kennt, kann man eventuell damit leben.

      Im Kern ist Replikation nur ein Doppelverarbeiten jeglicher schreibender SQL-Queries sowohl auf dem Master, als auch auf dem oder den Slaves. Das bedeutet, dass die Probleme des Lockings hier genauso auftreten werden, denn anders als durch Schreibzugriffe kriegen die Slaves ihre Daten nicht aktualisiert. Weil das Schreiben allerdings nicht zwingend sofort erfolgen muss, können die Slaves hinter dem aktuellen Datenbestand des Masters hinterherhinken - man arbeitet auf den Slaves also nicht zwingend mit aktuellen Daten.

      Deshalb bringt es z.B. Probleme, wenn man in seiner DB-Zugriffslogik einfach zwei Verbindungen zum Master und zum Slave aufmacht und alle SELECTs auf dem Slave ausführt. Weil die Schreibzugriffe nicht zwingend schon ausgeführt wurden, wenn das Programm weiterläuft, kann man beim nachfolgenden Lesen der Daten (auf dem Slave) schon mal von einem veralteten Datenstand überrascht werden. Session-Daten in so einer Datenbank zu speichern ist definitiv keine gute Idee.

      Ansonsten sollten sich doch zumindest ein paar sicher eher allgemein gehaltene Performance-Benchmarks im Netz finden lassen. Wenn dir dabei ein System ins Auge fällt, das angeblich besser abschneidet, dann versuch es in deinem Labor einzubinden und miss die Unterschiede unter deinen konkreten Bedingungen nach. Vielleicht ergibt sich dann ein ähnliches Bild wie im Benchmark oder auch ein ganz anderes.

      Ohne zu analysieren, wo das Problem genau liegt, kann man keine pauschalen Hilfen anbieten. Allerdings klingt es relativ vernünftig, zunächst von MyISAM auf InnoDB umuzusteigen, sofern das keine Features beeinträchtigt, die derzeit von MyISAM benutzt werden. Im Zweifel wäre ja auch ein teilweiser Umzug möglich.

      - Sven Rautenberg

      1. Moin Sven,

        Ich bin skeptisch, dass ein Wechsel der Engine den entscheidenden Performance-Gewinn bringt, so dass der Server wieder ausreichend Platz hat. Du solltest das aber zunächst im Labor nachstellen und dann mit Tools wie Apaches "ab" messen, ob sich die Anzahl der Requests pro Zeiteinheit steigern lässt.

        Ein Wechsel der Storage-Engine kann enorm viel Potential haben, oder auch nicht. MyISAM hat kein vernünftiges Locking implementiert, jeder Schreibzugriff in einer Tabelle sperrt die gesamte Tabelle für parallele Lesezugriffe.

        Hinzu kommt, dass mit InnoDB erst wichtige Features wie Transaktionen möglich werden. Ein Umstieg ist potentiell also immer sinnvoll.

        Im Kern ist Replikation nur ein Doppelverarbeiten jeglicher schreibender SQL-Queries sowohl auf dem Master, als auch auf dem oder den Slaves.

        Das ist eine Möglichkeit, Synchronisation zu betreiben.

        Weil das Schreiben allerdings nicht zwingend sofort erfolgen muss, können die Slaves hinter dem aktuellen Datenbestand des Masters hinterherhinken - man arbeitet auf den Slaves also nicht zwingend mit aktuellen Daten.

        Hier wirds komisch.

        Das hängt stark von der verwendeten Replikations-Methode ab. Was du  meinst, ist asynchrone Replikation. Da gibt es aber durchaus noch synchrone und die sog. „streaming replication.“ Bei der synchronen wird nach dem COMMIT gewartet, bis alle Slaves alle Daten geschrieben haben. Es wird also nie der Fall auftreten, dass du ein erfolgreiches COMMIT hast aber auf den Slaves veraltete oder unvollständige Daten. Bei der Streaming Replication wird ein gewisser Zeitraum (im Bereich von wenigen 100 Millisekunden) garantiert.

        Natürlich werden durch synchrone Replikation die Schreibzugriffe massiv verlangsamt. Du kannst dafür aber problemlos die SELECTs auf Slaves verteilen.

        Und dann gibt es da natürlich noch die diversen Ansätze von Multi-Master Replication mit ihren diversen Ansätzen von Konflikt-Behandlung.

        Ohne zu analysieren, wo das Problem genau liegt, kann man keine pauschalen Hilfen anbieten.

        Richtig.

        LG,
         CK

  2. Hi

    Von welchen Zahlen in Sachen Benutzer, Menge an Daten etc reden wir hier?

    Leider steigt jetzt der Datenbankserver in Spitzenzeiten immer wieder aus.

    Wie äussert sich das genau? Abfragen laufen extrem lang, der Datenbankserver nimmt keine Anfragen mehr entgegen oder stürzt sogar komplett ab (der mySQL Daemon oder die gesamte  Kiste). Gibt's Fehlermeldungen? Wie viele gleichzeitige Verbindungen laufen denn grad auf dem Datenbankserver? Werden die auch alle wieder ordentlich aufgeräumt?

    Vielleicht ist auch die Hardware unterdimensioniert? Wie sieht die Infrastruktur aus?

    Die dB Abfragen lassen sich nicht weiter optimieren.

    Das halte ich für ein wildes Gerücht, selbst wenn die Abfragen in sich schon optimal sind, so lässt sich an anderen Dingen wie Indizes oder der Art wie, wie viel und wie oft Daten abgefragt werden.

    Jetzt denke ich über ein Umstieg auf inno dB nach.
    Was würde ihr als Alternatives Datenbanksystem empfehlen.

    Evt. NoSQL als Caching Layer zwischen Datenbank und Webserver.

    BTW: Ich betreibe hier mehrere Server (MS SQL 2012) mit einem gesamt Datenvolumen von 13 TB und täglichem Traffic von etwa 2 TB. Das sind im Schnitt etwa 240 gleichzeitige aktive Verbindungen von Programmen auf die Datenbankserver. Von den Servern ist seit 12 Monaten keiner in die Knie gegangen durch die Last, CPU Auslastung in Spitzenzeiten bei 70% und im Durchschnitt bei 25%. Klar werden allerlei Performance Probleme berichtet, dass Abfragen zu lange dauern etc. Aber diese Probleme stammen von ein paar dämlichen C++ Programmierern, die denken, sie müssten erstmal die ganze Tabelle mit 150mio Records laden um dann selbst ein WHERE und ein SUM in ihrem eigenen Code zu machen.

    Du siehst also, es gibt viele Stellen an denen sich noch optimieren lässt.

    Cheers, Frank

    1. Hallo Frank,

      Ich bin leider kein IT Mensch ;o) meine Server sind gemanagte.
      Aber ich denke die Leute sind gut wo ich die Seite und den Cluster zu liegen habe. Zumindest hatte ich in den letzten Jahren immer das Gefühl gut aufgehoben zu sein.

      Habe mal nachgesehen...1.522,629 GB

      1.522,629 GB sagt die Traffic Auswertung Monat 12

      Der Support meinte das der Datenbankserver es "nicht mehr schafft" ...
      Als Alternative könnte ein leistungsfähiger Server in Frage kommen.

      Bei einem Ausfall ist der Server für eine bestimmte Zeit nicht erreichbar

      Bei der Optimierung habe ich damals jede Abfrage untersucht und entsprechende Indexes angelegt. Das war ein großer Aufwand.
      Naja hat ja auch zwei Jahre was gebracht. Jetzt ist die Datenbank gewachsen Größe derzeit 3,9 Gi ich habe das Gefühl Mysql stößt zunehmend an seine Grenzen...

      Und erhoffe mir mit einer Umstellung auf Inno einen Leistungsschub

      1. Server traffic: In diesen Tabellen wird der Netzwerkverkehr dieses MySQL-Servers seit dessen Start aufgeführt.

        Traffic 1 ø pro Stunde
        Empfangen 154 MiB 28 MiB
        Gesendet 4,841 MiB 890 MiB
        Insgesamt 4,995 MiB 918 MiB
        Verbindungen ø pro Stunde %
        max. gleichzeitige Verbindungen 982 --- ---
        Fehlgeschlagen 2 0,37 0,00%
        Abgebrochen 0 0,00 0,00%
        Insgesamt 255 k 46,96 k 100,00%
        Abfragestatistik: Seit seinem Start wurden 1,570,727 Abfragen an diesen MySQL-Server gesandt.

        Insgesamt ø pro Stunde ø pro Minute ø pro Sekunde
                         1,571 k 288,81 k 4,81 k 80,23

      2. Hi,

        Der Support meinte das der Datenbankserver es "nicht mehr schafft" ...

        Vernünftiger Support sollte sich spezifischer ausdrücken können, um das Problem zusammen mit dem Kunden eingrenzen zu können – das setzt aber voraus,

        Ich bin leider kein IT Mensch

        – dass auch der Ansprechpartner beim Kunden einer mit entsprechendem Know-How ist.

        Und ggf. gibt es das auch nicht als „Standard“-Support mit irgendeinem 08/15-Hostingpaket – ggf. wirst du/deine Firma da also auch erst mal ein bisschen in die Tasche greifen müssen, damit der Support sich das für dich/euch genauer anschaut.

        Als Alternative könnte ein leistungsfähiger Server in Frage kommen.

        Sagt der Support?

        Na dann sollte er diese Aussage auch mit nachvollziehbaren Logs etc. belegen können.

        Andernfalls versucht er entweder nur, eigene Inkompetenz damit zu überspielen, oder sich das Problem von allein lösen zu lassen, in dem man einfach mehr Hardware drauf wirft (dafür kämen dann Kompetenz- oder Kostengründe in Frage).

        MfG ChrisB

        --
        RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
        1. Hi ChrisB,

          Ich bin mit dem Hoster Service zufrieden wenn auch nicht ganz billig.

          Meine Fragestellung richtet sich in erster Linie darauf ob sich eine Umstellung auf InnoDB lohnt.

          Das was ich an Benchmarks gelesen habe klingt aus meiner Sicht vielversprechend. Ich benötige eine Volltextsuche und Inno wurde dementsprechend "aufgerüstet"

          1. Hi,

            Meine Fragestellung richtet sich in erster Linie darauf ob sich eine Umstellung auf InnoDB lohnt.

            Das ist die gleiche Fragestellung wie die, ob sich für Person X ein größeres Auto „lohnt“.

            Ohne X und eine Menge weiterer Umstände zu kennen – die ggf. auch erst mal *untersucht* werden müssen, wenn X sie nicht sofort benennen kann – ist eine solche Fragestellung nicht zielführend beantwortbar.

            MfG ChrisB

            --
            RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
            1. Hi,

              @Das ist die gleiche Fragestellung wie die, ob sich für Person X ein größeres Auto „lohnt“.

              Das kann man so oder so sehen...

              Aber ich denke es wird für mich inno werden

              http://blogs.innodb.com/wp/2011/07/innodb-fts-performance/
              http://dev.mysql.com/tech-resources/articles/mysql-5.6-rc.html

              Danke an Euch insbesondere an Frank

              1. Na dann ist ja die Entscheidung schon gefällt?!

                Das Problem kann dann noch sein, dass zwar die InnoDB Engine gut ist aber der Server in Sachen Hardwareleistung hinterherhinkt. Keine Ahnung ob es da noch spezifische Konfigurationsoptionen gibt.

                Der Vergleich mit einem Auto ist nicht unangebracht, du brauchst keine Porsche Motor in einem VW Trabant. Und keinen Trabant-Motor in einem LKW.

                'Leistungsfähigerer Server' klingt auch schwammig. Für gewöhnlich gibt es 4 Bereiche, die zusammenspielen müssen:

                ( ) CPUs - um zum einen genügend Reserven für Requests zu haben oder falls parallele Abfragen unterstützt werden, diese auch parallel zu verarbeiten

                ( ) RAM - Arbeitsspeicher, desto mehr Daten aus Tabellen und Indizes im Arbeitsspeicher sind, desto schneller können sie durchsucht und ausgeliefert werden, idealerweise hat man mehr RAM als die Datenbank gross ist. :-)  Und das Betriebssystem brauch sicher auch noch ein paar Reserven.

                ( ) Disk - Abgesehen von der Ausfallsicherheit bei Medien ist es von Vorteil, ein schnelles IO Subsystem zu haben, falls nämlich Daten von Disk nachgeladen werden müssen (z.b. Volltextsuchekataloge), dann sollte dies so schnell als möglich geschehen.

                ( ) Netzwerk - Redundante Erreichbarkeit, einerseits gut gegen den Ausfall einer Netzwerkverbindung oder eines Switches, andererseits kann man da dann auch mittels Teaming und Dynamic Link Aggregation (IEEE802.3ad) weitere Skalierbarkeit und Bandbreite schaffen. Oder man macht die mySQL Verbindungen dann alternierend mit 2 verschiedenen IPs.

                "Tell me where it hurts". Dazu müsste man allerdings noch deutlich mehr Zahlen haben um zu wissen, wo optimiert werden kann/muss. Deine Traffic/Uptime Statistik ist da nicht mal ein Grundstein. Was sagen denn die Logs deiner "grossen" Webseite? Die wird doch sicherlich Fehler und Warnungen irgendwo hinschreiben? Wenn der Datenbankserver aussteigt sollte sich das theoretisch ja in einer Fehlermeldung auf/in der Webseite äussern? mysql_connect() failed oder so.

                Wenn ich 'n blauäugigen Tipp abgeben müsste, dann würde ich sagen, die Programmierung hinter der Webseite macht viel zu viele Datenbankabfragen.

                BTW "Cluster", was ist denn das für einer genau? Oder isses einfach nur 'n Load Balancer?

                Wenn dein Provider dir da technisch nicht helfen kann oder helfen will, dann sollte er zukünftig auch nicht mehr für dich in Frage kommen. SRSLY!

                Cheers, Frank

                1. Na dann ist ja die Entscheidung schon gefällt?!

                  Ja ich denke das ist der richtige Weg.
                  Hatte ohnehin vor den Datenbestand neu aufzubauen.

                  @Hardware es muss sich rechnen
                  Klar gibt es tolle Maschine (Porsche)
                  Wenn ich groß und stark bin Kauf ich mir einen
                  Bis dahin fahre Fiat ;o) und komme etwas später ans Ziel habe aber was von der Landschaft

                  Und Fiat hat auch nachgelegt
                  Habe einen Artikel gefunden mit SSD das ist sehr interessant.

                  Danke an alle für die Anregungen.
                  Datenbankcluster für Lesezugriff zwei IPs

                  BTW "Cluster", was ist denn das für einer genau? Oder isses einfach nur 'n Load Balancer?

                  Ja,load Balance per Hardware

                  Das Teil hatte mal 25.000 gekostet

                  Wenn dein Provider dir da technisch nicht helfen kann oder helfen will, dann sollte er zukünftig auch nicht mehr für dich in Frage kommen. SRSLY!

                  Muss mich selber erstmal informieren um mitreden zu können
                  Ein Konzept erstellen. Wie du richtig abgeleitet hast ist die Anwendung /Website Datenbank intensiv (Suchmaschine) von daher die vielen Abfragen

                  Danke dir nochmal ;o)
                  Arbeitest du gewerblich?

                  Für mich ist es ein Hobby aber dafür Menschen auch Geld aus ;o)

                  1. Hallo,

                    Wie du richtig abgeleitet hast ist die Anwendung /Website Datenbank intensiv (Suchmaschine) von daher die vielen Abfragen

                    ah ja, eine "Suchmaschine", dazu fällt mir grad folgender Artikel im Netz ein: 10 Dinge, die man nicht mit relationalen Datenbanken machen sollte.

                    @Hardware es muss sich rechnen

                    Ja, man sollte dann aber auch nach einem ausgewogenen System schauen.

                    Datenbankcluster für Lesezugriff zwei IPs

                    BTW "Cluster", was ist denn das für einer genau? Oder isses einfach nur 'n Load Balancer?
                    Ja,load Balance per Hardware
                    Das Teil hatte mal 25.000 gekostet

                    Das ist keine Spezifikation. :-)

                    Arbeitest du gewerblich?

                    Wie auch immer diese Frage gemeint ist? Arbeite ich? Ja, muss ich. Noch. In diesem Bereich? Ja. Gewerblich? Ich habe kein eigenes Gewerbe, ich prostituiere mich hauptsächlich für einen einzelnen Arbeitgeber. :-)

                    Cheers, Frank

              2. Tach!

                Aber ich denke es wird für mich inno werden

                Bedenke, dass Volltextsuche in InnoDB die Version 5.6 von MySQL voraussetzt. Diese ist noch nicht als Stable Release verfügbar. Und selbst wenn, dann dauert es seine Zeit, bis der Support in den Linux-Distributionen dafür vorhanden ist. Wenn du MySQL 5.6 einsetzen willst, musst du also eine alternative Installationsquelle suchen, die fertige Pakete für deine Distribution anbietet, oder es zu Fuß installieren. Zu letzterem kommt hinzu, dass du dann die Updates auch zu Fuß überwachen und einspielen (lassen) musst.

                dedlfix.

                1. Hi,

                  Hmmmm , jetzt bin ich etwas irritiert ...

                  Ich dachte es sei schon so weit !
                  Danke für diese Info

                  Bedenke, dass Volltextsuche in InnoDB die Version 5.6 von MySQL voraussetzt. Diese ist noch nicht als Stable Release verfügbar.

  3. Hallo,

    Jetzt denke ich über ein Umstieg auf inno dB nach.
    Was würde ihr als Alternatives Datenbanksystem empfehlen.

    Vielleicht verstehe ich das Thema nicht richtig.

    Aber ist InnoDB nicht seit einiger Zeit Standard bei MySQL (statt MyISAM), weil Oracle dort hohe Performancezuwächse realisieren konnte?

    Demnach wäre zumindest dieser Umstieg sinnvoll.

    Gruß, Daniel