Run "FLUSH QUERY CACHE" periodically to defragment

U

Unifex

New Member
Ich bekomme auf einem System mit relativ vielen Besuchern folgende Meldung im Tuningprimer:

Query Cache is 21 % fragmented
Run "FLUSH QUERY CACHE" periodically to defragment the query cache memory
If you have many small queries lower 'query_cache_min_res_unit' to reduce fragmentation.

Das nächtliche optimieren der Tabellen scheint darauf keinen Einfluss zu haben.

Mein Wert für query_cache_min_res_unit = 2K

Ich meine viel kleiner geht es nicht mehr :)

Nach dem Flushen ist das System merklich schneller.

Was kann ich tun?
 
In dem Fall wäre zu prüfen, ob der Query-Cache überhaupt Sinn macht und es nicht besser wäre, ihn zu deaktivieren. Alternativ überarbeitet man die Queries so, dass sie sich effektiver Cachen lassen.
 
Es gibt beratungsresistente Entwickler welchen man einfach mit einem kleinen Cronjob zu einer wieder flotten Anwednung verhelfen kann in dem mann den Query Cache regelmäßig flushed. Alle 4h zB. Wirkt in manchen Konstellationen Wunder.
 
Eine einfache Zeile mit dem richtigen Code wäre glaube ich nicht so aufwendig gewesen wie diese Antwort :cool:
 
Unifex said:
Eine einfache Zeile mit dem richtigen Code wäre glaube ich nicht so aufwendig gewesen wie diese Antwort :cool:
Click to expand...

Haette aber deutlich weniger Lerneffekt erzielt 8-)

Man kann auch mal Danke sagen fuer die hilfreichen Antworten und sich dann nicht noch beschweren
 
Joe User said:
Warum nicht die Ursache beseitigen, statt an den Symptomen herumzupfuschen?
Click to expand...
Dazu muss er aber mehr an der eingesetzten Software samt SQL analysieren als nur den Tuningprimer anzuwerfen.
Und dazu wartet er vielleicht auf eine fertige Lösung von uns.
 
Na ja, ein Forum ist ja auch dafür da um Lösungen zu erfragen von Leuten die Erfahrener sind.

Ich selber bertreibe selber drei große Foren und Antworten wie "ließ mal in Google" oder so, hasse ich da genauso wie hier weil sie nicht zielführend sind.

Wer keine Lösung geben möchte um die er höflich gebeten wurde, soll es doch einfach lassen und nicht bei den nicht so erfahrenen Leuten den "Oberchecker" raushängen lassen.

@Joe User

An welchen Parametern macht man denn Fest, ob ein Query Cache Sinn macht? Die Querys selber kann ich nicht verändern, weil das eine Fremdsoftware ist.
 
und Antworten wie "ließ mal in Google" oder so, hasse ich da genauso wie hier
Click to expand...
Ich kann im Thread keine Referenz auf Google finden.

Wenn du GwenDragon's Links in umgekehrter Reihenfolge Kombinierst (ein Cronjob bauen welches Mysql aufruft und dieses wiederum den FLUSH Befehl durchführt) solltest du an einem der möglichen Ziele sein.

An welchen Parametern macht man denn Fest, ob ein Query Cache Sinn macht?
Click to expand...
Ein Querycache macht in fast allen Fällen Sinn. Er soll aber recht klein (ein paar MB) sein da ansonsten die Zeit welche zum Suchen der Query draufgeht höher ist als das parsen selber wäre. In Percona's MariaDB Ableger von Mysql wird das im Process List mit "waiting for cache_mutex" festgelegt, Mysql sind es einfach wartende Anfragen.

Ich habe +-20MB mit (glaube ich) 1KB Resolution als Cache festgelegt und bislang sind die Wait-locks auf die Mutex sind nicht mehr aufgetreten.

Viele "Howto"'s empfehlen Caches mit einigen Hundert(!) MB Grösse was aber in vielen Fällen sehr kontraproduktiv ist.

Das nächtliche optimieren der Tabellen scheint darauf keinen Einfluss zu haben.
Click to expand...
Nach Optimieren oder DUmps solltest du den Cache flushen um diesen nicht mit wenig benötigten inhalten aus dem Optimizer/Dump gefüllt zu haben.
 
Nachdem für Anfänger gewünscht wird, wie ein Cronjob für jede Stunde eingefügt wird:
1. Als root einloggen
2. crontab -e aufrufen
3. Im Editor folgende Zeile hinzufügen:
Code: 
@hourly (echo FLUSH QUERY CACHE | mysql --user=root --password=PASSWORD)>/dev/null 2>&1
eingeben
4. Speichern

Und mit crontab -l kannst du dir die Jobs anzeigen lassen.

@Unifex
Das nächste mal bitte auch mal selbst dazu schreiben, was du schon weißt und was du genau möchtest.
Nicht jede kann erahnen, wie viel du weißt, wie viel Zeit du investieren willst oder ob du eine fertige Lösung von uns willst.
 
Last edited by a moderator:
d4f said:
Ein Querycache macht in fast allen Fällen Sinn. Er soll aber recht klein (ein paar MB) sein da ansonsten die Zeit welche zum Suchen der Query draufgeht höher ist als das parsen selber wäre.....

Ich habe +-20MB mit (glaube ich) 1KB Resolution als Cache festgelegt und bislang sind die Wait-locks auf die Mutex sind nicht mehr aufgetreten.

Viele "Howto"'s empfehlen Caches mit einigen Hundert(!) MB Grösse was aber in vielen Fällen sehr kontraproduktiv ist.
Click to expand...


Das sind ein paar gute Hinweise. Mein Cache ist mit 2 GB definiert.
Momentan genutzt wird "nur" 204 MB. Current query_cache_min_res_unit = 2 K

Ich glaube 20 MB könnte da etwas klein sein. Die Res Unit könnte ich natürlich noch auf 1kb setzen. Vielleicht hilft das noch etwas.
 
Einen Benchmark habe ich noch nicht laufen lassen.

Ich schaue jetzt schon die ganze Woche immer mal alle paar Stunden auf den Server und checke auf Fragmentation um das irgendwie an einem Ereignis fest zu machen aber seit zwei Tagen ist das Ergebnis 0%.

Dabei wurden in den zwei Tagen sicher nichts anderes gemacht als alle die Tage und Wochen zuvor.

Von den Zugriffen auch nicht viel weniger.

Ich vermute dass diese ganze Sache auch was mit einigen Blockaden meines SQL Servers zu tun hat. Mache ich mal 4 Wochen nichts, springen auf einmal die Anzahl Threats nach oben und die Anzahl der Connection steigt max 150 auf fast 1000.

Der SQL Server ist dann richtig beschäftigt (dicht).

Vielleicht hat die Fragmentation des Query Speichers was damit zu tun.
Ich beobachte das mal weiter und vielleicht komme ich ja noch drauf.
 
You must log in or register to reply here.
Back
Top