MySQL Performance Tuning / Query Cache

    Hallo,


    ich schreibe hier einfach mal zusammen wie man schnell und einfach mehr Performance aus dem MySQL Server heraus holen kann.
    Das bei PD-Admin mitgelieferte Packet ist ja weitestgehend Standard.
    Man sollte darauf achten die Werte an sein System anzupassen.


    Eigentlich handelt es sich nur um 3 kleine Änderungen.
    Wenn jemand mehr Tuning Tipps hat, immer her damit. :)
    Es wird also zu erst der MySQL Query-Cache aktiviert, die Speichergröße erhöht und die zulässige Verbindungs-Anzahl hoch gesetzt.


    Als erstes mit vim o.ä. Editor die MySQL Konfiguration öffnen:

    Code
    vi /usr/local/pd-admin2/etc/my.cnf


    Da sucht ihr nach "# The MySQL server".
    Bei vim geht das mit Shift /.
    Hier fügt ihr folgende Zeilen ein.

    Code
    set-variable = query_cache_size=1000000
set-variable = max_connections=2500


    Die erste Zeile setzt den Query-Cache auf 1000000 Byte.
    Die zweite setzt die Anzahl der max. gleichzeitigen Verbindungen von 100 auf 2500.
    Bei einem halbwegs gut gefüllten Host reicht 100 nie und nimmer aus.
    Die anderen Werte beliebig erhöhen. Das doppelte pro Wert kann nicht schaden. Je nach dem wie viel Arbeitsspeicher ihr habt.
    Achtung! Nicht zu hoch setzen! So wie unten schaut es ungefähr bei mir aus.


    Code
    set-variable = query_cache_size=1000000
set-variable = max_connections=2500
key_buffer = 64M
max_allowed_packet = 2M
table_cache = 256
sort_buffer_size = 8M
net_buffer_length = 8K
myisam_sort_buffer_size = 8M


    So, nun MySQL neu starten.

    Code
    svc -d /service/mysqld
/usr/local/pd-admin2/bin/mysqladmin \
   -p`cat /opt/pdadmin/etc/mysql_rootpw.conf` shutdown


    Code
    svc -u /service/mysqld


    Und schauen ob der Cache aktiv ist:


    Code
    mysql -p

    Anmelden. Root Passwort wird benötigt

    Code
    SHOW VARIABLES LIKE 'have_query_cache';

    Aha, wenn alles geklappt hat steht hier nun YES. :)

    Code
    SHOW STATUS LIKE 'Qcache%';

    Hier wird nun der Nutzungs-Status angezeigt.
    Mit "quit" abmelden.


    Das wars so weit. Bei unseren Systemen bringt der Query Cache auf jeden Fall eine Performance Verbesserung.
    Feedback willkommen.


    weiterführende Links zu dem Thema:


    http://dev.mysql.com/doc/refma…e/mysql-optimisation.html
    http://www.heise.de/ix/artikel/2003/02/040/
    http://dev.mysql.com/doc/refma…atus-and-maintenance.html

    Es wäre vielleicht noch Interessant zu wissen auf welcher Hardware und wieviel Hots pro Server du diese Konfiguration einsetzt.
    Ansonsten sind die gegebenen Werte eher dafür da seinen Server selbstmörderisch abzuschießen.

    Hallo,


    exakt diese Werte laufen seit ca. 2 Jahren auf z.b. einem P4 1.7, 2GB Ram sowie auf einem P4 2.8, 2GB Ram und auf diversen anderen Maschinen(Xeon, Opteron) mit angepassten Werten. VHost pro Server max. 100.
    Wobei auch wirklich sehr Lasten intensive Portale und Applikationen zum Einsatz kommen.
    Wie gesagt, jeder sollte die Werte auf seine Bedürfnisse anpassen.
    Die Werte dienen als Beispiel.


    Warum man seinen Server somit "selbstmörderisch abschießt" will mir nicht so recht klar werden. Bisher ist das jedenfalls noch nicht geschehen.
    Event. sollte man auf die Verbindungsanzahl von MySQL achten, aber da wir unseren MySQL Server nicht nach außen öffnen besteht da schon ein geringeres Risiko eines eventuell. Angriffes o.ä..

    Hey Lars,
    dsa mit dem Selbstmord war darauf bezogen dass ich nicht einfach irgendwelche Werte nehmen kann ohne das Hintergrundwissen deines letzten postes.
    Wenn ich beispielweise deine Werte annäherend übernehme dann hab ich eine Load jenseits von gut und böse. Sollte also um gottes willen keine schlechte Kritik sein.
    Ganz im Gegenteil. PD-Admin liegt recht schwer im System und so ist es schön wenn man Werte hat die man bisschen tunen kann :D

    Ne, is klar. :)
    Hab ich auch nicht so aufgefasst.
    Na hast Du event. mal Vergleichswerte?
    Wie gesagt, bisher gab es keine Probleme. Ich habe die Werte damals Schritt-für-Schritt erhöht und irgendwann so gelassen wie jetzt.

    wie macht man das wieder aus?!? mein ganzer server spuckt nur noch 504 Gateway Timeout seitdem ich das geändert habe...



    rauslöschen der zeilen reicht wohl nicht...



    ja kommt immer noch

    Code
    Gateway Time-out


The gateway did not receive a timely response from the upstream server or application.


    auch nach einen reboot ist das Noch immer an:


    Code
    mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+
1 row in set (0.00 sec)

    Möglicherweise hilft es den Wert wieder auf "0" zu setzten:


    query_cache_size=0
    query_cache_type=0


    Zitat

    Original von Shackattack
    Eine der hier beschriebenen Variablen ist nicht mehr gültig.


    Auf welchen Wert beziehst Du dich denn?

    Kurze Frage da dieses Tutorial ja schon etwas älter ist:
    Funktioniert dieses Tutorial auch in der aktuellen Version?
    Habe momentan einige performence-Probleme mit dem mySQL-Server....


    OS: Debian 5 (32bit)
    Installierte pd-admin-Version: v4.14
    Installierte Version d. Serverumgebung: 3-0.178

    Hallo, es handelt sich um einen vServer von Carrot-Server (d2)
    18 Domains
    14 MySQL-Datenbanken
    ~10 eMail-User
    ca. 10GB Traffic / Monat
    2,5 GB Festplattenspeicher werden für Webspace verbraucht


    Habe mittlerweile herausgefunden das es wohl auch am PHP liegt, weil wenn ich von cgiwraper auf mod_php umstelle alles ganz zackig läuft....

    Eigentlich sollte fast-cgi -> mod_php keine Großartigen Unterschiede im Speicherverbrauch machen, lediglich in der Anzahl der Prozesse ist mod_php
    sparsamer. Vielleicht ist es die Resourcenverwaltung vom vserver Host die
    euch die Probleme bereitet.


    Da Carrot-Server ohnehin nur VServer von Hetzner Weiterverkauft wie es
    aussieht wäre es bei 18 Domains wohl sinniger gleich einen X2 zu mieten ;)