Skip to content

Datenbanktuning ...

So, ich habe mal ein wenig Datenbanktuning betrieben. Das Blog sollte jetzt deutlich schneller reagieren. Eine wirklich grosse Hilfe ist das MySQL Performance Tuning Primer Script von Sundry einem Mitarbeiter von MySQL.

Die meisten Variablen können Online mittels "set global variablenname=wert" gesetzt werden, wobei Wert auch ein Ausdruck wie "32*1024" sein kann.

Die dauerhaften Änderungen an den Variablen gehören bei Ubuntu und Debian in das Verzeichnis /etc/mysql/conf.d (man muss nur in den seltensten Fällen Original-Konfigurationsdateien verändern). ACHTUNG: Dort funktionieren die Ausdrücke nicht, dort müssen Werte gesetzt werden. (Macht nicht den gleichen Fehler wie ich ...)

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

onli am :

*Dein Blog lädt jetzt schon sehr schnell. Aber war das vorher so viel langsamer? Wo spürt man die Verbesserungen am ehesten?

Dirk Deimeke am :

*Für meinen Geschmack war es einfach zu langsam.

Dann habe ich mir das Slow-Query-Log angeschaut und noch zwei Indexes ergänzt. Die Masse hat das aber nicht gebracht, danach habe ich dann an den Speichereinstellungen gedreht und durch das Skript prüfen lassen.

Jetzt geht es deutlich besser.

Hannes am :

*Ich lass das Skript jeden Monat mal laufen und schau, was es mir Vorschlägt.
Man sollte vllt noch dazu sagen: MySQL muss mindestens 24h gelaufen sein, sonst sind die Vorschläge des Skripts nicht so ideal. Also je länger MySQL lief, desto besser arbeitet das Skript (da is zb. prüft wieviele Verbindungen maximal stattfanden, etc)

bed am :

*und auch 48 Stunden können nicht immer ausreichend sein.
Kurze Spitzen sind ja nicht immer innerhalb zwei Tagen, sondern kommen sporadisch vor. Wenn man nicht Gefahr laufen will, das Besucher mysql Fehler bekommen, sollten man die Einstellungen auch ruhig zweimal überdenken :-)
mtop z.B. ist auch ganz nützlich ...
http://zockertown.de/s9y/index.php?/plugin/tag/Datenbanken

Dirk Deimeke am :

*Gebe Dir Recht (ich bin DBA ...).

Allerdings ist die generelle Frage, wofür Du optimierst.

Niemand soll Fehler bekommen, ist die eine Option.

Es soll keine kurzen Spitzen geben, die andere.

Die Wahrheit liegt - wie eigentlich immer - in der Mitte.

Phillip am :

*Von wegen Performance:
http://www.dotdeb.org/2008/08/25/using-the-google-perftools-to-speed-up-your-mysql-server/

Mit nem besseren melloc geht der mysql auch schneller ;-)
angeblich 15-20 % :-)

Dirk Deimeke am :

*Habe ich mir angeschaut, gibt es leider nicht für Hardy und kommt daher nicht in Frage.

Phillip am :

*http://www.codership.com/en/products/galera_replication
teste ich seit heute mit den den daten einer 10 GB Foren/Messages etc Datenbank.
Wenn man mal syncrone MySQL Replication sehen will die problemlos funktioniert. Und abgesehen von den Kommunikationskosten sklaliert das ding wohl recht linear ;-) wenn man mal nix zu tun hat im job weil man sich für ein paar Stunden mit einen sehr kleinen shellscript ersetzt und ein paar Server übrig hat ;-)

Dirk Deimeke am :

*Und was genau ist der Vorteil gegenüber den eingebauten Replikationsmechnismen, die ebenfalls synchron arbeiten können?

Phillip am :

*Das sich neue oder ausser sync geratene cluster nodes automatisch auf den neuesten stand bringen und in der Zeit in für querys erreichbar sind.

automatisches auto increment management. heisst das du dich nicht mehr um auto increment offsets bei parallelen inserts auf mehreren db nodes kümmern musst.
muss man aber nicht benutzen und dann werden die inserts aber sequentiel.

Phillip am :

*auserdem beherscht mysql nur asyncrones repizeieren in der master/slave oder master/master beziehung. nur mysql cluster unterstützt syncrone replikation. und das sklaiert alles anderen als linear bei inserts.

Dirk Deimeke am :

*Die Frage ist, ob man überhaupt "echte synchrone" Transaktionen möchte. Damit wäre ein insert/update/delete erst abgeschlossen, wenn es auf dem letzten Synchronisationsmitglied durch ist und das kann bei grösseren Infrastrukturen eine Menge Zeit beanspruchen.

Für auto_increment IDs gibt es keine andere Lösung, aber es lassen sich ja auch andere IDs vergeben.

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen