Query Cache > 2 GB möglich?

[juelz]

Hallo,

ich nutze MySQL 5.0.32 unter Debian etch. Ich wollte nun einen relativ großen Query Cache einstellen, jedoch ist aus irgendwelchen Gründen kein Query Cache größer als 2 GB möglich:

Code: Select all

mysql> show variables like "query%";
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_alloc_block_size       | 8192     | 
| query_cache_limit            | 16777216 | 
| query_cache_min_res_unit     | 512      | 
| query_cache_size             | 0        | 
| query_cache_type             | ON       | 
| query_cache_wlock_invalidate | OFF      | 
| query_prealloc_size          | 8192     | 
+------------------------------+----------+
7 rows in set (0.00 sec)

Wenn ich in der my.cnf genau 2048M eintrage, dann funktioniert es noch. Wenn ich aber beispielsweise 3072M eintrage, so bleibt obiger Wert bei query_cache_size auf 0.
Woran kann das liegen? Ist ein Query Cache > 2 GB nicht möglich, gibt es irgendwelche Beschränkungen?

Vielen Dank schonmal im Voraus!

[Joe User]

Ähm, Du weisst, wozu der Query-Cache gedacht ist? Du weisst, wie stark Dein Query-Cache ausgelastet ist? Du kennst den Unterschied zwischen einem 32Bit und 64Bit MySQLd?

Wofür benötigt ein Hobby-Admin einen Query-Cache >256MB?

[juelz]

Ähm, Du weisst, wozu der Query-Cache gedacht ist? Du weisst, wie stark Dein Query-Cache ausgelastet ist? Du kennst den Unterschied zwischen einem 32Bit und 64Bit MySQL?

Ja. Das System nutzt einen i686 Kernel, allerdings mit PAE. Ich dachte, dass hier die 4 GB Grenze auch für die Prozesse nicht gilt.

Edit: Habe gerade folgendes von Isotopp gelesen:
"Es gibt zwar so was wie PAE/AWE, aber reden wir da nicht drüber - wir haben 2007, und es gibt keinen Grund, mit gefesselten Beinen über die Ziellinie zu hüpfen, wenn man stattdessen richtig rennen kann. Es gibt zwar PAE-Code in MySQL, aber der ist per Default nicht enabled, in den MySQL-eigenen Binaries nicht vorhanden und schlecht getestet. Selbst wenn das alles anders wäre, würde man PAE nicht wollen, sondern gleich richtig 64 Bit machen wollen - PAE ist langsam und hat haarige Tatzen."

Ich werde wohl an dieser Stelle meine PAE-Strategie noch einmal überdenken...

[Joe User]

Kannst Du meine Fragen 1, 2 und 4 beantworten?

[juelz]

Ähm, Du weisst, wozu der Query-Cache gedacht ist?

Ja.

Du weisst, wie stark Dein Query-Cache ausgelastet ist?

Ja, laut tuning-primer.sh etwa 99,9 %.

Du kennst den Unterschied zwischen einem 32Bit und 64Bit MySQLd?

Habe ich mit dem letzten Posting Update beantwortet.

Wofür benötigt ein Hobby-Admin einen Query-Cache >256MB?

Ist der Sinn & Zweck wichtig? Es gibt eine Tabelle mit etwa 30 Mio. Datensätze an Kundendaten. Dementsprechend ist der Query Cache ausgelastet.

[Joe User]

Dürfen wir mal den Output von tuning-primer.sh und/oder mysqltuner.pl sehen?

[oxygen]

Da wäre ich auch neugierig.

[juelz]

Ich habe die Kiste in 64 bit Ausführung neu installiert. Sobald ich erste Ergebnisse von tuning-primer.sh zeigen kann, werde ich sie hier veröffentlichen.

[isotopp]

ich nutze MySQL 5.0.32 unter Debian etch. Ich wollte nun einen relativ großen Query Cache einstellen, jedoch ist aus irgendwelchen Gründen kein Query Cache größer als 2 GB möglich

Du willst keinen Query Cache nennenswert größer als 128M einstellen. Bedenke, daß der Kram bei jedem Insert/Update/Delete/Replace auch ausgefegt werden muß. Stelle stattdessen ausreichend große Key Buffer bzw InnoDB Buffer Pools ein.

[juelz]

Stelle stattdessen ausreichend große Key Buffer bzw InnoDB Buffer Pools ein.

Das habe ich bereits getan, habe mich da weitesgehend an das tuning-primer.sh Skript gehalten. Ich bin dort aber auf ein Problem gestoßen. Laut Bug#5731 bereitet ein key buffer > 4 GB auch auf 64 Bit Systemen Probleme (uint statt size_t). Dieses Problem wurde bisher erst in der Enterpriseversion (5.0.52) von MySQL gefixt. Ich habe mir aus dem Bugreport einen Patch gesucht und meinen MySQLd händisch gepatcht und neukompiliert, allerdings habe ich nun das Gefühl, dass der key buffer nun weniger verwendet wird, als vorher. Weisst du etwas über das Problem?

Ich habe den key_buffer_size deshalb erstmal auf genau 4 GB eingestellt (da meine Indizes der relevanten Tabelle bereits etwas mehr als 4 GB ausmachen, da teilweise umfangreiche Volltextindizes). Siehe Ausgabe:

Code: Select all

KEY BUFFER
Current MyISAM index space = 4 G
Current key_buffer_size = 3 G
Key cache miss rate is 1 : 158
Key buffer fill ratio = 53.00 %
Your key_buffer_size seems to be fine

mysql> show variables like "key_%";
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| key_buffer_size          | 4194304000 | 
| key_cache_age_threshold  | 300        | 
| key_cache_block_size     | 1024       | 
| key_cache_division_limit | 100        | 
+--------------------------+------------+
4 rows in set (0.00 sec)

Dein Argument mit dem Query Cache leuchtet mir auch ein, das hatte ich so ohne weiteres noch nicht bedacht. Was soll ich aber davon halten, dass der mysqld x tausend Queries immer aus dem Query Cache entfernen muss, nur weil dieser zu klein ist?

[isotopp]

Dieses Problem wurde bisher erst in der Enterpriseversion (5.0.52) von MySQL gefixt. Ich habe mir aus dem Bugreport einen Patch gesucht und meinen MySQLd händisch gepatcht und neukompiliert, allerdings habe ich nun das Gefühl, dass der key buffer nun weniger verwendet wird, als vorher. Weisst du etwas über das Problem?

Nein, ich weiß nix von Änderungen, die Du am Code gemacht hast, noch kann ich zu Deinen Gefühlen Stellung nehmen. Wenn Du Messungen hättest, könnte man über diese Zahlen reden und was sie möglicherweise bedeuten.

Die Änderungen in 5.0.52 sind recht umfassend getestet worden (darum sind sie erst in 5.0.52 und nicht bereits vorher gemacht worden), es ist vielleicht besser, wenn Dir einen 5.0.5x Originalsource ziehst und übersetzt statt möglicherweise unvollständige Patches zu verwenden, insbesondere wenn Du sie in ihren Auswirkungen nicht überblickst und Dich da auf Gefühle verlassen mußt. Soweit ich das überblicke gab es da mal eine Initiative von Jeremy Cole und Freunden unter dem Namen "Dorsal Source", die so was gemacht haben, und einige Distributionen bauen auch selber von aktuelleren Trees.

Du schreibst weiter:

Code: Select all

KEY BUFFER
Current MyISAM index space = 4 G
Current key_buffer_size = 3 G
Key cache miss rate is 1 : 158
Key buffer fill ratio = 53.00 %

Deine Miss-Ratio ist unter 1:300, was schlecht ist, aber Dein Key Buffer ist nur 50% voll. Demnach ist Dein Server kalt (neu gestartet?) und die Ratio ist wertlos (noch nicht stabilisiert). Bitte messe dies noch mal mit einem warmen Server.

Dein Argument mit dem Query Cache leuchtet mir auch ein, das hatte ich so ohne weiteres noch nicht bedacht. Was soll ich aber davon halten, dass der mysqld x tausend Queries immer aus dem Query Cache entfernen muss, nur weil dieser zu klein ist?

Bring doch erst mal Dein Schema in Ordnung (in 3NF). Wenn es dann noch Schmerzen macht reden wir weiter.