RootForum Community

Hallo,

nachedm ich mir jetzt schon jede Menge infos hier aus dem Forum reingezogen hab ( danke an die Autoren, bes. isotop und joe user) noch eine spezielle Frage.
Wie groß kann man den query chache gefahrlos einstellen. Habe den jetzt auf 128 MB hoch, bekomme aber immer noch:

Qcache free memory 78570440
Qcache hits 969694
Qcache inserts 128641
Qcache lowmem prunes 29838
Qcache not cached 2665
Qcache queries in cache 18724
Qcache total blocks 43307

oder kann ich diese low mem prunes gar nicht vermeiden?

Die maschine hat zwei gig, im moment ist ruhig

top - 10:52:27 up 1 day, 17:13, 1 user, load average: 1.12, 0.85, 0.76
Tasks: 128 total, 2 running, 126 sleeping, 0 stopped, 0 zombie
Cpu(s): 26.0% us, 2.7% sy, 0.0% ni, 70.3% id, 0.7% wa, 0.0% hi, 0.3% si
Mem: 2025624k total, 1427968k used, 597656k free, 5432k buffers
Swap: 3919840k total, 271724k used, 3648116k free, 278396k cached

Bei Last geht die load average leider auf 2-5 hoch.

Danke für alle Tipps.

Gruß
Harry

pangaea wrote:Wie groß kann man den query chache gefahrlos einstellen.

Der Query Cache ist ein globaler Puffer. Man kann ihn sehr groß machen, mindestens 4 GB groß. Allerdings macht das idR keinen Sinn.

Wenn man beim Query Cache lowmem_prunes sieht, dann sollte man im Auge behalten, wie oft diese auftreten. Also entweder FLUSH STATUS und dann nach 10 Sekunden SHOW SESSION STATUS, oder schlechter, einfach SHOW GLOBAL STATUS und Qcache_lowmem_prunes/Uptime ansehen.

Wenn mehrere lowmem_prunes pro Sekunde auftreten, ist der Query Cache zu klein und man sollte ihn größer machen.

Ein größerer Query Cache ist kein Wert an sich. Wenn man den Query Cache größer macht, dann ist das nur lohnend, wenn die Hitrate ebenfalls steigt. Die Hitrate ist (Qcache_hits/(Qcache_hits+Com_select))*100 Prozent und liegt bei den meisten Leute so bei 33%.

Verbessert sich die Hitrate nicht, indem man den Query Cache vergrößert, dann ist die Anwendung in dieser Form nicht für den Query Cache geeignet.

Dafür kann es mehrere Gründe geben:

Die Anwendung wiederholt keine Queries, sondern erzeugt jedesmal neue Queries (viele Inserts und Lowmem_prunes, aber niemals Qcache_hits). Es ist schon ausreichend, wenn die Schreibwese (select, SeLECT, SeLeCt) der Queries variiert oder wenn in der Query Kommentarfelder enthalten sind, die variabel sind (SELECT /* Query 4711 */ ... ).

Die Anwendung erzeugt Queries auf Tabellen, auf die häufig geschreiben wird (Viele Qcache_inserts, keine Prunes, wenig Hits).

Die Anwendung erzeugt Queries, die nicht cachebar sind, also entweder Funktionsaufrufe enthalten, die die Query uncachebar machen oder die Queries sind mit SQL_NO_CACHE markiert (Viele Qcache_not_cached, wenige inserts, wenige Prunes, wenige Hits).