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 ...)
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 ...)
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
onli am :
Dirk Deimeke am :
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 :
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)
Dirk Deimeke am :
bed am :
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 :
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 :
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 :
Dirk Deimeke am :
Phillip am :
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 :
Phillip am :
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.
Dirk Deimeke am :
Danke!
Phillip am :
Dirk Deimeke am :
Für auto_increment IDs gibt es keine andere Lösung, aber es lassen sich ja auch andere IDs vergeben.