michi bloggt!

wie bereits erwähnt nahm ich an einem von MySQL AB angebotenen Workshop über Performance Tuning & Optimization teil. Vortragender war Kristian Köhntopp (Blog). Die Teilnehmer, etwa 20 an der Zahl, kamen erstaunlicherweise fast gar nicht aus der Web-Programmierung.

Gründsätzliche Messages des Seminars:
* Optimiere erst dann wenn auch Optimierungsbedarf besteht
* Stell dir eine Test-Umgebung zum Benchmarken zusammen, und verwende "echte" Daten, "echte" Requests und "echte" Server. Philosophieren ob ein bestimmter Index so oder so definiert werden sollte, nützt gar nichts. Benchmarke es am besten selber.
* Es gibt einen Sättigunspunkt, ab dem die Performance zusammenbricht, und es gilt diesen im vorhinein zu bestimmen, um keine bösen Überraschungen erleben zu müssen.

Hier nun ein paar etliche unsortierte Notizen vom Seminar:
* "Dont over-optimize", ansonsten läuft man Gefahr zwar für den vorliegenden Spezialfall gut aufgestellt zu sein, aber bei geringfügigen Veränderungen der Daten, bzw der Requests in Schwierigkeiten zu kommen
* Mit munin lassen sich auch Mysql Key Figures monitoren (siehe hier)
* Datenbanken lieben Hauptspeicher. Sobald man mehr als 3 GB eingebaut hat, sollte man unbedingt 64bit CPUs mit aktuellen 2.6er Kernel verwenden
* Datenbanken lieben schnelle Festplatten. RAID-5 ist aber überhaupt keine gute Idee, da kleine random writes sehr langsam sind. Besser sind viele (billige) Platten im RAID-10. Benchmarke das RAID mittels SysBench.
* Jeder Thread/Connection hat seinen eigenen Speicher. Daher Connection Pooling.
* MySQL Query Cache verwendet LRU-Mechanimus (genauso wie Helma; macht also in Kombination mit Helma DB-Mapping nur selten sind). Um diesen aber verwenden zu können, muss man seinem Connector/J mit useServerPrepStmts=false konfigurieren.
* Der Query-Cache lässt sich mittels SQL_CACHE bzw SQL_NO_CACHE für einzelne Queries aus- bzw ein-schalten.
* sobald (table_locks_immediate / table_locks_waited) < 100 sollte man über InnoDB anstatt MyIsam nachdenken, da dann die Table-Locks ständig zu unnötigen Wartezeiten führen. Auf twoday.net liegt dieser Wert etwa bei 200, dennoch gibt es etliche andere potentielle Gründe für InnoDB (vor allem der nächste Punkt).
* InnoDB sortiert Daten nach Primary Key. Ist daher performanter wenn ein Datensatz über den Primary Key accessed wird (wie das bei Helma eben ständig der Fall ist). Ausserdem enthält der Indexbaum im Gegensatz zu MyIsam ebenfalls bereits den Primary Key. Daher werden Abfrage a la 'Select TEXT_ID from AV_TEXT where TEXT_F_SITE=123' komplett aus dem Index heraus beantwortet, ohne die Datentabelle zu bemühen. In MyIsam müsste man hierfür einen kombinierten Index auf (TEXT_F_SITE, TEXT_ID) legen.
* Lese und verstehe "How MySQL Uses Indexes"
* Make your indexes as small (and as few) as possible: Vermeide Indizes auf UTF-8 Columns (dreimal so groß wie iso-8859-1 columns). Optimizer muss sich vor jeder Query entscheiden welcher Index verwendet werden soll -> kostet CPU.
* Make your data as small as possible: Verwende nur UTF-8 wenn wirklich notwendig. Verwende "NOT NULL" und "unsigned" bei den Datentypen-Deklarationen.
* Vermische nicht OLTP und OLAP im Datenbank-Design!
* Konvertierung einer Tabelle in InnoDB aus Optimierungsgründen zweimal ausführen. Sprich 'ALTER TABLE .. engine=InnoDB; ALTER TABLE .. engine=InnoDB;'
* Primary Key für InnoDB-Tabellen sollte möglichst klein sein.
* Linux' Disk-Cache, welcher für MyIsam (nicht aber von InnoDB) entscheidend ist, verwendet ebenfalls LRU und arbeitet auf Block-Ebene (meine gegenteilige Annahme hier war also falsch)
* Man kann für InnoDB die Transaktionssicherheit mittels 'innodb_flush_log_at_trx_commit=0' ausschalten, und somit die Performance deutlich erhöhen.
* MySQL Cluster (NDB) ist etwas für Leute mit fetter Geldbörse. Erstens da man sämtliche Daten im RAM halten muss. Zweitens weil man gut beraten ist, MySQL Support hierfür anzufordern. Und zu guter Letzt sollte man auch besser auf Mysql 5.1 warten, bzw sogar 5.2.
* Es gibt neben MyIsam und InnoDB noch andere interessante Storage Engines: CSV, Memory, Archive
* De-Normalisierung zwecks Performance-Optimierung ist in Ordnung, aber man sollte immer ein Skript zur Verfügung haben, welches die Daten-Konsistenz wiederherstellt.
* Partitioning erlaubt es Tabellen kleiner zu machen. Klassischer Anwendungsfall für twoday.net wäre es z.b. alle Tables nach zugehöriger Site zu partitionieren. Dieses Feature sollte man aber auch besser erst ab 5.1 verwenden.
* Indizes können Performance verschlechtern. Ein Index welcher das Resultset nicht zumindest auf ein Zwanzigstel reduziert, ist eher kontraproduktiv. (z.b. ein Index auf Geschlecht, oder aber auch auf TEXT_PROTOTYPE). Bei der Index-Optimierung sollte man stets 'EXPLAIN SELECT..' ausführen, und dann auch noch sein Benchmarking-Setup verwenden, anstatt zu mutmassen.
* DRBD ist eine gute Alternative zu einen MySQL Master/Master-Setup um Ausfallssicherheit zu gewinnen.
* Logge auf eine separate Partition. Bevorzugtes Filesystem: reisferfs. Mounten mit 'notail,noatime'.

Und hier noch ein paar vom Vortragenden empfohlene Blogs rund um MySQL:
* http://mysqlperformanceblog.com
* http://www.planetmysql.org/
* http://de.planetmysql.org/
* http://jan.kneschke.de/blog/