Sie befinden sich hier: start » public:start » public:mysql

MySQL

Cluster Setup

Status Variablen interpretieren

Folgende Zusammenhänge kann/muss man betrachten um zu sehen, wie gut der Server konfiguriert ist. Ich setzte hierbei voraus, dass er einige Zeit unter normalen Bedingungen lief. Alles andere würde die Ergebnisse verzerren.

Die „Namen“ im folgenden sind entweder Status-Variablen oder konfigurations-Variablen. Letztere beginnen immer! mit einem kleinen Buchstaben ;)

mysql, index

Open_files vs. open_files_limit

Stößt der Server hier an eine Grenze, ist er oft mit FileIO öffnen/schließen beschäftigt. Die Anzahl wird allerdings stark durch die Anzahl der Datenbanken und deren Tabellenzahl bestimmt. (lineare Abhängigkeit)

An dieser Stelle ist die Doku des Betriebssystems zu konsultieren. Mehr als 1024 Dateien offen zu halten, ist für einen Datenbankserver durchaus sinnvoll.

Slow_queries

Ist die Anzahl der Anfragen, die länger als long_query_time (Default: 10s) dauerten Slow_queries sollte möglichst 0 sein.

Open_tables vs table_cache und Opened tables

Die Anzahl offener Tabellen sollte in den Tabellen Cache passen. Ansonsten kommt es auch hier zum häufigen FileIO. Wenn die Anzahl der insgesamt Geöffneten Tabellen hoch ist, zeigt dies auf ein Problem in der Vergangenheit.

Max_used_connections vs. max_connections

Wird die maximale Verbindungszahl erreicht, kann das folgendes bedeuten:

Es sind zu wenig Verbindungen erlaubt (max_connections muss erhöht werden)
Der Server ist ausgelastet und muss erweitert werden

In einem Dual Athlon 2,2GHz mit 2GB RAM und Apache/PHP5 im Parallelbetrieb haben sich 100 Verbindungen als gutes Mittelmaß bewährt.

Qcache_hits, Qcache_lowmem_prunes, Qcache_inserts

Diese Daten sind ein Indikator für das Ausnutzen des datenbankeigenen Abfragecaches. Gut ist, wenn es mehr Hits als Inserts gibt ;) Das Rauswerfen von Ergebnisse (Qcache_lowmem_prunes) aufgrund eines vollen Caches wird sich zwar nicht vermeiden lassen, ist aber ein Indiz für einen zu kleinen Cache. Hier ist ein Verhältnis von Qcache_lowmem_prunes:Qcache_insert von 1:10 noch ok.

Der Cache sollte mit query_cache_size angepasst werden. 64MB sollten es schon sein. Mit query_cache_limit wird die maximale zu cachende Ergebnisgröße definiert. Das Dilemma hier: Es passen nur wenige große Abfragen in den Cache, dafür aber viele kleine. Sind die kleinen nun besonders teuer, so muss man diese bevorzugen und die Großen ausklammern. Sind die kleinen Ergebnismengen sehr klein (<4kb), so kann man query_cache_min_res_unit entsprechend anpassen. Es steuert die Blockgröße für den Cache. Bei kleineren Ergebnissen kommt es zur Speicherfragmentierung.