Author Topic: [DE] [solved] MySQL - Tuning (Read 2273 times)

agaida · « **on:** 2011/05/14, 15:08:16 »

Hi,
hat jemand von Euch eventuell ein paar aussagefähige Tools und eventuell Links zum Thema Performancetuning MySQL parat?. Besonders wichtig wäre mir InnoDB. Habe zwar das Web durchforstet, aber zu meinem Glück fehlt noch was zu Gegentesten.

Insgesamt bin ich eigentlich schon recht zufrieden, nur irgendwie bekomme ich das Schreiben noch nicht so schnell, wie ich es gern hätte. Danke.

ralul · « **Reply #1 on:** 2011/05/14, 19:10:15 »

nicht innoDB sondern myisam als backend nehmen ?
(keine Konsistenz Garantien)
Mit Konsistenz und Transaction Log soll PostgreSQL manchmal schneller sein.

agaida · « **Reply #2 on:** 2011/05/14, 19:57:36 »

Danke für den Rat, wenn ich könnte, hätte ich das so gemacht! Scherzkeks! :lol:

Das Leben ist kein Wunschkonzert, Chiliproject (Redmine-Fork) ist in heftigster Entwicklung, die Buben haben auf MySQL gesetzt und ich habe nicht die geringste Lust, unter Ruby-Programmierung Datenbanken zu tauschen, die ich genauso gut beherrsche. (Eigentlich gar nicht)

Abgesehen davon habe ich hackmysql.com gefunden, das hat schon mächtig geholfen. Es ist schon erstaunlich, wie flott das werden kann, wenn die Einstellungen halbwegs vernünftig gesetzt sind. Momentan will ich einfach mal versuchen, diesen blöden Server so weit hinzubekommen, dass ich mich daran machen kann, mir das SQL an sich mal unter die Lupe zu nehmen. Davon verstehe ich wieder ein wenig. In der Zeit möchte ich mit der Projektverwaltung natürlich so bequem und flink wie möglich arbeiten.

Auf jeden Fall hatten die Änderungen in Caches, Handles usw schon eine Auswirkung. Meine ausser Dienst gestellte Mediawiki-Installation läuft bereits handgestoppte 7-8x so schnell mit diesen Einstellungen. Wenn ich dann mal weiss, was ich da eigentlich gemacht habe, könnte man auch überlegen, dass in Form eines kurzen Artikels für die Nachwelt zu verewigen. Davor würde ich aber gerne einige hirnrissig hoch gesetzte Werte wieder auf Normalmass zurückfahren und statt dessen an der Quelle des Übels angreifen - die Queries.

Genau dazu suche ich noch Scripts, Benches und allgemeinverständliche Erläuterungen. Allzuviel hilfreiches gibt es da nicht wirklich. Falls also noch was einfällt, her damit. "Optimierungen" á la mehr Prozessor, mehr Speicher, SSD wollte ich eigentlich vermeiden. Das soll schon weiter auf meinem Atom und mechanischen Platten wohnen. Momentan kann sich das Kunstwerk 3G Speicher schlabbern, erst dann kommt der Riegel. Das sollte für eine Gesamtdatenmenge von 80M reichen. (wie die sich auch immer zusammensetzt)

EDIT: Lesen lernen bildet: Eines der besseren Scripts, die ich im Netz gefunden habe, gibt es natürlich auch als debian-Paket: mysqltuner!

ralul · « **Reply #3 on:** 2011/05/15, 02:10:13 »

Queries:
- Indexes machen bei den Queries, die am häufiger auftauchen.
- Queries so anordnen, dass das erste Query die meisten Zeilen wegfrisst, Subqueries haben weniger Arbeit.
- Vorbereiten zB: Wenn Du immer ein Additionsergebnis abfragen musst, und dies häufiger als einmal, kannst Du diese Additions schon beim Einsetzen einer neuen Zeile in einer extra Spalte anlegen. Bei manchen Datenbanken kann man aus einem Query einen Index machen, was im Fall der oben genannten Berechnung, einem Trigger mit extra Spalte gleichkommt.

agaida · « **Reply #4 on:** 2011/05/15, 13:24:22 »

Genau das werde ich prüfen, das Problem ist nur, dass ich das Projekt nicht programmiert habe und die Jungens das grade von Grund auf umstricken. Ich muss jetzt erst mal Bestandsaufnahme machen, was überhaupt stört. (neben MySQL an sich, da werd ich aber nichts anpacken). Du musst unterscheiden zwischen Mist, den man selbst verzapft und aktueller Entwicklung, die grade umgestrickt wird. Die Grundbegriffe der Datenverarbeitung haben die Jungs mehr als gut drauf, allerdings glaube ich nicht, dass sie sich um die Optimierung der bisherigen Datenbank ernsthafte Gedanken gemacht haben. Wozu auch. Wozu sollen sie eventuell obsolete Strukturen noch zeitaufwendig optimieren? Das kann man an den Stellen machen, die man selbst geplant und ausprogrammiert hat (natürlich schon mit dem groben Plan im Hinterkopf und im Projekt niedergelegt). Ich hab erst mal einen Marker auf slow queries gelegt, nicht indizierte joins kommen später, wenn ich einen Überblick habe. Bis dahin kann das Ding kartesische Produkte bauen, bis es schwarz wird.

agaida · « **Reply #5 on:** 2011/05/21, 09:11:20 »

So, ich war jetzt mal mutig und hab das Zeug ausgelastet und als myisam wieder eingelastet. Ein Konvertieren des Formats war nicht möglich, da hat sich mysql trotz force gewehrt, aber meine Wenigkeit und vi sind da ja flexibel. Dumpen, InnoDB durch MyISAM ersetzen, einlasten und alle Anwendungen laufen noch. Es ist fein, funktionierende Datensicherungen und Testsysteme zu haben. Damit fällt dann der InnoDB-Zweig aus der Optimierung raus, ich hab wieder ein wenig Speicher mehr zum Verbraten übrig. Die Vermutung mit den Indizes war zum großen Teil richtig, aber eigentlich nicht weltbewegend. Viel schlimmer ist, dass da Queries aufgebaut werden, die zwangsläufig temporäre Tabellen aufbauen. Dass soll eigentlich nicht sein, da muss ich mal hinterhersuchen. Falls sich das nicht vermeiden lässt, kommt Variante 2 der Optimierung zum Einsatz. Eine Vertex 3 und ein neues Atom-Board mit 4x Sata soll wohl grad noch finanziell drin sein, wenns eng wird.

agaida · « **Reply #6 on:** 2011/06/01, 09:21:58 »

Und abschließend zum Thema MySQL: Wenn man es dann schnell haben möchte, dann sollte man nicht wirklich auf Debian Pakete setzen. Ich habe mir beim Profilieren den Wolf geschrubbt - dabei ist die Lösung ganz einfach. Man nehme einfach die aktuellen Pakete für ein aktuelles Produkt. Keine Angst, so ein Teufelswerk gibt es nicht bei debian.

Oracle bietet erst seit einem halben Jahr MySQL 5.5 an, Percona auch. Ich habe noch in einem Blog zum Thema gelesen, dass der einzige Vorteil von debian wäre, dass man das Zeug per apt-get installieren könne

Das kann ich aber mit Percona auch. Die Repositories sind eingebunden, die Datensicherung ist gelaufen und ich schiesse mir grade fürchterlich ins Knie oder habe ohne viel Klimmzüge schlappe bestätigte 200 - 300 % mehr Performance.

Ich bin wirklich mal gespannt.