Query Cache sinnvoll?

froemken

froemken

Neuer Benutzer
Beiträge
3
Hallo zusammen,

im Internet finden sich unglaublich viele Informationen zum Thema QueryCache. Damals per default aktiviert und in den neueren MySQL-Versionen wieder deaktiviert. Das Problem sind die verändernden Queries, die die "alten" Einträge auf dem QC wieder entfernen müssen.

Aber WANN macht die Verwendung des QC Sinn?

Ich persönlich würde vom Gefeühl her sagen: Je mehr SELECT als UPDATE/DELETE/INSERT-Abfragen wir haben desto eher sollte man den QC verwenden.

Aber WAS wäre ein gutes Indiz dafür den QC zu aktivieren?

Ich habe Euch mal ein paar Daten zusammen gestellt:

------------------------------------------------------------------------------

Insert: 13271875
Update: 11355025
Delete: 1681774
Select: 167385719
Uptime: 389021

Summe verändernder Queries: 26308674

68 verändernde Queries (UPDATE/INSERT/DELETE) pro Sekunde
431 Selects pro Sekunde

Jede ~6te Query durchsucht den QueryCache, um betreffende Cacheeinträge zu löschen

Ca. 7000 Tabellen verteilt auf ca. 150 Datenbanken.

------------------------------------------------------------------------------

Hin und wieder kommt es vor, dass Queries bis zu 4 Sekunden im Modus "Waiting for query cache lock" verbleiben. Ich empfinde es als extremst viel und würde in unserem Fall sagen, dass der QC bei uns sehr wenig Sinn macht.

Wie seht Ihr das?

Stefan
 
Werbung:
Naja. Auf einem Managed Server habe ich nur beschränkte Möglichkeiten. Ich kann zwar einen Redis entpacken und kompilieren, aber ich kann ihn nicht systemweit installieren. Ich kann auch mit CronJobs immer wieder prüfen, ob dieser noch läuft und bei Bedarf wieder neu starten, aber ich kann solche Cachemechanismen nicht mit dem MySQL-Server verknüpfen. Hier fehlen dann wirklich die benötigten Rootrechte.
 
froemken schrieb:
Naja. Auf einem Managed Server habe ich nur beschränkte Möglichkeiten. Ich kann zwar einen Redis entpacken und kompilieren, aber ich kann ihn nicht systemweit installieren. Ich kann auch mit CronJobs immer wieder prüfen, ob dieser noch läuft und bei Bedarf wieder neu starten, aber ich kann solche Cachemechanismen nicht mit dem MySQL-Server verknüpfen. Hier fehlen dann wirklich die benötigten Rootrechte.
Zum Vergrößern anklicken....

Das ist dann aber wieder ein Zeichen von schlechten Support des Hosters. Ich arbeite für 2 Marken, beide dedizierte managed Server, bei beiden wäre das kein Thema. (auch wenn beide Marken an sich sehr unterschiedlich sind)
 
Also der Support des Hosters ist der Hammer. Vielleicht mag im Portfolio die Installation eines MemCache für den QueryCache fehlen, aber ich bin von der Umgebung sehr begeistert. Also ich mag jetzt wegen einem fehlenden Feature nicht wechseln. Mir fehlt das "Gefühl" für die Masse der Daten. Sind 500 Abfragen viel? Sind 500 Abfragen für einen QC von 128MB zu viel? Würde es bei 500 Abfragen Sinn machen den QC zu deaktivieren, weil eh ständig die Hälfte wieder invalidiert wird? Oder sind wir mit 500 Abfragen auf jeden Fall in dem Bereich in dem man sich mal über ein MemCached-Backend Gedanken machen sollte?
 
froemken schrieb:
Sind 500 Abfragen viel? Sind 500 Abfragen für einen QC von 128MB zu viel? Würde es bei 500 Abfragen Sinn machen den QC zu deaktivieren, weil eh ständig die Hälfte wieder invalidiert wird? Oder sind wir mit 500 Abfragen auf jeden Fall in dem Bereich in dem man sich mal über ein MemCached-Backend Gedanken machen sollte?
Zum Vergrößern anklicken....

Da sind noch immer viel zu viele Unbekannte, um das beantworten zu können.
 
Werbung:
Das hängt auch davon ab, was für eine Software mit der Datenbank arbeitet, also ob ordentlich prepared wird (und damit ein Cache greifen kann) oder ob das grauslige Selects jedesmal neu zusammengebastelt werden.
Meiner Erfahrung nach wird der QC bei Mysql häufig überbewertet und oft viel zu gross angelegt, sodass sich das Ding ständig mit sich selbst beschäftigt (Query rein, Query raus).
 
Zurück
Oben