Präsentation MySQL auf dem T3CM12

T3CM12

Performance mit MySQL

+[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

Warum das Ganze?

●
SAP Export → MySQL
●
1.800.000 Datensätze
●
Bis zu 12 Filterkriterien
●
Jede Spalte sortierbar

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

MySQL-Konfiguration

●
/etc/mysql/my.cnf
●
Abschnitt [mysqld]

query_cache

●
query_cache_type
●
query_cache_size
●
query_cache_limit
●
query_cache_min_res_unit

key_buffer

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

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

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

MySQL

Sortieren (filesorts)

2 Algorithmen stehen zur Verfügung

Ihr könnt nicht entscheiden!

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

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

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

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.

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

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

max_length_for_sort_data

●
ohne TEXT und BLOB
●
Indikator für Algorithmusauswahl

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

read_rnd_buffer_size

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

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)

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)

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

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

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

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.

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

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

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

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

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

Präsentation MySQL auf dem T3CM12

Weitere ähnliche Inhalte

Ähnlich wie Präsentation MySQL auf dem T3CM12 (20)

Präsentation MySQL auf dem T3CM12