In Dieser Präsentation zeige ich Euch wie Ihr mit ein paar Konfigurationseinstellungen noch etwas aus Eurem MySQL-Server herausholen könnt. Dabei gehe ich speziell auf das filesorting ein.

1. T3CM12
Performance mit MySQL

2. +[werk] - Was machen wir?
●
Agentur - Firmenverbund
●
unabhängig, inhabergeführt
●
TYPO3 & Magento
●
Kiel, Hamburg, Aachen, Köln, Frankfurt, München
– team:inmedias
– www.kennziffer.com
– PAGEmachine
– Splendid
– creativestyle

3. Warum das Ganze?
●
SAP Export → MySQL
●
1.800.000 Datensätze
●
Bis zu 12 Filterkriterien
●
Jede Spalte sortierbar

4. Was werden wir machen?
●
Auflistung verschiedener MySQL-Parameter
●
Auswirkung der Parameter schätzen/fühlen
●
Der beste Wert für einen Parameter
●
Vorstellung einer Report-Extension

5. MySQL-Konfiguration
●
/etc/mysql/my.cnf
●
Abschnitt [mysqld]

6. query_cache
●
query_cache_type
●
query_cache_size
●
query_cache_limit
●
query_cache_min_res_unit

7. key_buffer
●
50% Regel
●
Summe aller Indizes
●
Reiner MySQL-Server: ~80%
●
Wichtig für MyISAM-Tabellen
●
Sollte nicht kleiner als 16-32MB sein

8. key_buffer TEST
●
480.000 Datensätze (Daten: 31MB/Index: 5MB)
●
16MB = 0.577510
●
32MB = 0.570650
●
64MB = 0.501239
●
128MB = 0.494927
●
256MB = 0.496414

9. table_cache
●
Öffnen von Tabellen kostet Zeit
●
Anzahl gleichzeitig geöffneter Tabellen im RAM:
– Opened_tables
– Open_tables
●
SHOW OPEN TABLES;
●
Tabellenheader (keine Daten!) = klein
●
Gilt für jede Verbindung
●
1000 Tabellen * 100 Verbindungen = 100.000

10. MySQL
Sortieren (filesorts)
2 Algorithmen stehen zur Verfügung
Ihr könnt nicht entscheiden!

11. Filesorts
●
Explain-Syntax informiert
– Extra = Using filesort
●
Wenn kein Index zur Verfügung steht
●
Naming: Egal ob im Speicher oder Dateiebene
●
Ein LIMIT wird NACH dem filesort ausgeführt

12. Algorithmus 1
●
Suche alle Datensätze, die zur Abfrage passen
●
Sortierschlüssel und Zeilenzeiger erstellen
– sort_buffer_size
– Wenn voll: Auslagern auf Dateiebene
▪ Sort_merge_passes
●
Dateien zusammenführen
●
Datei in sortierter Reihenfolge auslesen
– read_rnd_buffer_size
●
2mal die Datenbank abfragen

13. Algorithmus 2
●
Suche alle Datensätze, die zur Abfrage passen
●
Sortierschlüssel, Zeilenzeiger UND Spalten
●
sort_buffer_size schneller voll
●
Gefahr: Mehr I/O auf der Festplatte
●
Lösung: max_length_for_sort_data
●
1mal die Datenbank abfragen

14. Algorithmuswahl
●
Der 2-Stufige Algorithmus wird verwenden,
wenn:
– Die Gesamtgröße aller Spalten, die für eine Abfrage
benötigt werden, PLUS die ORDER BY-Spalten größer
ist als max_length_for_sort_data
– Irgendeine Spalte vom Typ TEXT oder BLOB ist
▪ Mit SUBSTRING() kann versucht werden den 1-
Stufigen Algerithmus auszulösen.

15. sort_buffer_size
●
Wird durch den CPU-Cache beeinflusst
●
Wenn voll: Sort_merge_passes++
●
Nicht verwechselt mit myisam_sort_buffer_size
– Nur relevant für REPAIR TABLE und CREATE INDEX
●
Wird immer vollständig verwendet
●
> 2MB könnte das Sortieren verlangsamen
●
http://inaugust.com/post/15
●
mmap <==> malloc

16. sort_buffer_size TEST
● 480.000 Datensätze
● 100MB = 0.863143 Sekunden
● 50MB = 0.814188 Sekunden
● 2MB = 0.542065 Sekunden (Standardeinstellung)
● 1MB = 0.507201 Sekunden
● 512KB = 0.498969 Sekunden
● 256KB = 0.496011 Sekunden
● 128KB = 0.501239 Sekunden
● 64KB = 0.700654 Sekunden

17. max_length_for_sort_data
●
ohne TEXT und BLOB
●
Indikator für Algorithmusauswahl

18. max_length_for_sort_data TEST
●
480.000 Datensätze
●
10240 Byte = 0.502896
●
2048 Byte = 0.505319
●
1024 Byte = 0.500584
●
512 Byte = 0.422704
●
256 Byte = 0.426195
●
128 Byte = 0.423405
●
64 Byte = 0.420210

19. read_rnd_buffer_size
●
Mit TEXT und BLOB
●
RAM (/) 1024
– 4GB (/) 1024 = max. 4MB

20. read_rnd_buffer_size TEST
●
480.000 Datensätze (+ 10 TEXT-Spalten)
●
4MB = 6.325305
●
2MB = 6.492217
●
1MB = 6.240868
●
512KB = 6.187837
●
256KB = 6.137172 (Standardeinstellung)
●
128KB = 6.182955
●
10KB = 6.287569 (min. 8200Byte)

21. max_sort_length TEST
●
1.800.000 Datensätze
●
4 = 2.409508
●
10 = 2.516746
●
20 = 3.256559
●
50 = 3.519731
●
100 = 3.536854
●
1024 = 3.524631 (Standardeinstellung)

22. read_buffer_size
●
http://www.mysqlperformanceblog.com/2007/09/1
●
Anpassen an Read-Ahead des Servers
●
Anpassen an das I/O-Subsystem des Servers
●
128KB scheint ein guter Wert zu sein

23. read_buffer_size TEST
●
480.000 Datensätze (+ 10 TEXT-Spalten)
●
10MB = 5.509637
●
2MB = 5.439128
●
1MB = 5.453352
●
512KB = 5.434408
●
256KB = 5.426407
●
128KB = 5.377650
●
10KB = 5.385319

24. read_buffer_size TEST
●
480.000 Datensätze (ohne TEXT-Spalten)
●
10MB = 0.520960
●
2MB = 0.518599
●
1MB = 0.517788
●
512KB = 0.512285
●
256KB = 0.495720
●
128KB = 0.499344
●
10KB = 0.498823

25. InnoDB Buffer
●
innodb_buffer_pool_size (Daten + Index)
●
innodb_log_buffer_size
– Was schaffte Eure Festplatte innerhalb einer Sekunde
zu schreiben? Standard von 8M ist OK.

26. InnoDB Buffer TEST
●
480.000 Datensätze (Daten: 46M/Index: 37M)
●
512MB = 0.764015
●
128MB = 0.771674
●
64M = 0.762305
●
32M = 0.839192
●
16M = 0.823517

27. innodb_additional_mem_pool_siz
e
●
Standard 1MB
●
Speichert Informationen der Daten
●
Speichert Strukturen der Daten
●
Wenn voll → Warnungen im Error log
– Raufsetzen auf 2MB
●
Fast kein Performancegewinn

28. innodb_flush_log_at_trx_commit
●
Sehr hoher Performancegewinn
●
Wert 1 (Standard)
– Commit → In Logdatei anfügen → Schreiben
●
Wert 0 (Daten weg bei MySQL-Absturz)
– Pro Sekunde wird der Buffer in die Logdatei geschrieben
●
Wert 2 (Daten weg bei OS-Absturz)
– Commit → In Logdatei anfügen → Pro Sekunde Logdatei
schreiben

29. Dumps zum Spielen
●
http://dumps.wikimedia.org/backup-index.html
●
Getestet mit enwikinews-[datum]-page.sql
– 480.000 Datensätze
●
Getestet mit Daten aus einem Kundenprojekt
– 1.800.000 Datensätze

30. Danke ...
●
für's Zuhören
●
für Rückfragen
●
für Applaus
●
an die Community
●
an die TYPO3-Entwickler
●
an das Catering :-)
Stefan Frömken | www.kennziffer.com GmbH