Normalerweise stehe ich irgendwelchen Scripten, die Performanceverbesserungen einer Datenbank versprechen kritisch gegenüber. Zuviele Seiteneffekte sind zu beachten. Alleine schon die unterschiedliche Struktur der auf den Datenbankserver aufsetzenden Anwendungen lassen es sehr schwierig erscheinen, alles mit einem Script erschlagen zu wollen. Mein bester Freund ist Studium der Literatur der Datenbank, Beobachtung des Laufzeitverhaltens und etwas gesunder Menschenverstand. Damit bin ich bisher ganz gut gefahren.

Nun hat mich mein Kumpel auf tuning-primer.sh aufmerksam gemacht. Dieses Script wurde von Matthew Montgomery, einem MySQL Mitarbeiter geschrieben. Ich habe das Script auf meine vorhandene Installation auf dem virtuellen Rootserver laufen lassen und habe nach und nach einige der Empfehlungen des Scriptes umgesetzt und die Ergebnisse abgewartet. Vorteilhaft an dem Script ist, das es keine Änderungen selber durchführt, sondern nur Empfehlungen ausspricht zusammen mit einer Erläuterung. Beim auswerten kam ich dann schon mal an einen Punkt, wo ich merkte, das ich bisher offensichtlich die Namen der Variablen nicht immer richtig interpretiert hatte sondern mir meine eigenen Zusammenhänge vorgestellt hatte, die aber offensichtlich mit der Wirklichkeint eben nichts gemein hatten ;-) Aber ganz so schlimm war es dann doch nicht.

Das einzige wiklich auffällige war der Table Cache. Da habe ich wie eben geschrieben auch nicht die Zusammenhänge richtig begriffen.

TABLE CACHE
Current table_cache value = 128 tables
You have a total of 978 tables
You have 128 open tables.
Current table_cache hit rate is 0%, while 100% of your table cache is in use
You should probably increase your table_cache

Die Empfehlung ist etwas schwammig formuliert, ich habe mittlerweile dort einen Wert von 1000 eingestellt. Nun können also alle Tabellen gecached werden, das Script ist zufrieden und ich bin es auch :-)

Das Script schaut zuerst nach der Laufdauer der Datenbank und warnt bei Laufzeiten von <48 Stunden davor sich auf die Empfehlungen zu verlassen, weil die Datenbasis zu klein ist. Das ist auch sehr sinnvoll, denn temporäre Spitzen sollten schon mal im Beobachtungszeitraum vorgekommen sein, damit man nicht zu knapp kalkuliert. Das Script gibt Empfehlungen für:

  • Slow Query Log
  • Max Connections
  • Worker Threads
  • Key Buffer
  • Query Cache
  • Sort Buffer
  • Joins
  • Temp Tables
  • Table (Open & Definition) Cache
  • Table Locking
  • Table Scans (read_buffer)
  • Innodb Status
  • Fazit: Das Script ist sehr hilfreich, es hilft vor allem denjenigen die sich nicht so tief mit der Materie beschäftigen wollen und schnelle Ergebnisse brauchen. Etwas Vorsicht sollte man aber dennoch walten lassen, vor allem, wenn es sich um ein Produktivsystem handelt, denn man hat schnell einen Tippfehler gemacht, den man erst langwierig suchen muss, bevor die Datenbank wieder hochfährt :-)

    Script download:tuning-primer.sh

    No comments

    Add Comment

    E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

    To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
    CAPTCHA

    Standard emoticons like :-) and ;-) are converted to images.
    BBCode format allowed
    Markdown format allowed