Präsentation MySQL auf dem T3CM12

571 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
571
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
11
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Präsentation MySQL auf dem T3CM12

  1. 1. T3CM12Performance mit MySQL
  2. 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. 3. Warum das Ganze?● SAP Export → MySQL● 1.800.000 Datensätze● Bis zu 12 Filterkriterien● Jede Spalte sortierbar
  4. 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. 5. MySQL-Konfiguration● /etc/mysql/my.cnf● Abschnitt [mysqld]
  6. 6. query_cache● query_cache_type● query_cache_size● query_cache_limit● query_cache_min_res_unit
  7. 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. 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. 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. 10. MySQL Sortieren (filesorts)2 Algorithmen stehen zur Verfügung Ihr könnt nicht entscheiden!
  11. 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. 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. 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. 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. 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. 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. 17. max_length_for_sort_data● ohne TEXT und BLOB● Indikator für Algorithmusauswahl
  18. 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. 19. read_rnd_buffer_size● Mit TEXT und BLOB● RAM (/) 1024 – 4GB (/) 1024 = max. 4MB
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. Danke ...● fürs 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

×