verschiedenes: Handler_read, Slow_queries, krumme Werte

[mcweb]

Hallo liebe Serversupportforennutzer,

ich test zur Zeit verschiedene MYSQL Konfigurationen und bin zu dem Schluss gekommen, dass sich aus Sicht des Webseitenbesucher die Query times nur marginal unterscheiden. Zumindest was die mysql Abfragegeschwindigkeit beim surfen auf meinen gehosteten Seiten angeht.
Bei ausgeschaltetem query Cache hab ich bei einer speziellen Seite die eine recht umfangreiche Abfrage startet immer ~3.5 Sekunden. Bei eingeschaltetem Q-Cache 0.1.

natürlich will ich die wichtigen Größen...
join_buffer_size
sort_buffer_size
record/read_rnd_buffer_size
read_buffer_size
...möglichst gering haben um eine theoretische maximale RAM-Auslastung bei voller Besucherzahl im Rahmen zu halten.

Der Server verfügt über 2GB RAM, Apache2 ist auf 100 Max Connections und arbeitet mit PHP5+fCGId+suexec (child prozesse deaktiviert).
Postfix+dovecot, ClamAV, Spamd, Webmin und Teamspeak sind ebenfalls aktiv.

folgende Werte werden bei einem sparsamen Speichersetup auch nach einer kurzen Laufzeit ziemlich hoch...

MySQL server has been running for [B]0 days, 4 hours, 8 minutes and 23 seconds[/B].

Handler_read_rnd [COLOR="Red"]290 k[/COLOR]

The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.

Handler_read_rnd_next [COLOR="Red"]116 M[/COLOR]

...kann sich das negativ auf die Stabilität auswirken oder andere schlechte Folgen haben?

was ich auch etwas seltsam finde ist folgendes

Slow_queries: [COLOR="Red"]1,645[/COLOR]

die slow query time habe ich auf 10 Sekunden, was eigentlich ja zu hoch ist. Ist jetzt vielleicht eine ungenaue Aussage aber wäre nie aufgefallen das irgend eine Seite auf dem Server so lang braucht um zu laden (ohne caching). An was könnte das noch liegen das er jede paar Sekunden einen slow Query verbucht? Blöd gefragt: kann das auch an langsamen Connections von anderen Besuchern liegen?

Hab gerade folgende my.cnf

key_buffer_size = 192M
thread_stack = 256K
thread_cache_size = 32
max_connections = 100
table_cache = 2048
thread_concurrency = 2
join_buffer_size = 128K
read_buffer_size = 128K
read_rnd_buffer_size = 256K
sort_buffer_size = 2M
tmp_table_size = 128M
max_heap_table_size = 128M
query_cache_limit = 16M
query_cache_size = 128M
query_cache_type = 1
query_cache_min_res_unit = 512
myisam_sort_buffer_size = 32M
myisam_recover = FORCE,BACKUP
max_allowed_packet = 32M

Wenn ich folgendes einstelle

join_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 2M

hab ich zwar

Handler_read_rnd

und

Handler_read_rnd_next

niedriger. Aber von der Performance macht das überhaupt keinen merklichen Unterschied, weshalb ich natürlich lieber das sparsame Setup bevorzuge. Oder würde man das erst bei einer stärkeren Auslastung des Servers oder anderen Bedingungen bemerken?

Und warum stellt es für die read_buffer_size 126 976 Bytes = 124 kilobytes ein, für die read_rnd_buffer_size 252 statt 256 und den sort buffer auf 1.99999237 megabytes statt 2MB. Mit Webmin kann ich die Einstellungen korrekt setzten aber nicht mit my.cnf komisch.
Und wie bekomme ich "443 temp tables 10% were created on disk" auf 0% oder geht das garnicht bzw. macht nichts aus?

Ich freue mich auf Eure Meinungen und entschuldige mich für den vielen Text, aber irgendwie konnte ich nichts auslassen.

 

[Huschi]

Oder würde man das erst bei einer stärkeren Auslastung des Servers oder anderen Bedingungen bemerken?

Ja. Alle (Speicher-)Optimierungen mußt Du immer unter Last betrachten.
Es fängt doch schon an mit "Was ist, wenn wirklich 100 Apache-Prozesse im Speicher sind?" und der daraus folgenden Frage "Hat MySQL dann überhaupt noch genug Platz?" um einen Memory-Swap möglichst zu unterbinden.
Auch der Wirkung des Caches wird doch erst interessant, wenn mehrere gleiche/ähnliche Abfragen mehrfach hintereinander/gleichzeitig ausgeführt werden.
Baue also das Test-Scenario als Last-Test auf und fange dann anhand der Werte die Speicherverteilung zu optimieren.

Und wie bekomme ich "443 temp tables 10% were created on disk" auf 0% oder geht das garnicht bzw. macht nichts aus?

Das hängt von Deinen Joins ab. Die Einstellung tmp_table_size gibt vor, ab wann er die Temp-Tables auf Disk erstellt.

huschi.

 

[mcweb]

vielen Dank!

Ja. Alle (Speicher-)Optimierungen mußt Du immer unter Last betrachten.
...
Baue also das Test-Scenario als Last-Test auf und fange dann anhand der Werte die Speicherverteilung zu optimieren.

Ich habe mit apache benchmark (ab) schon ein paar Szenarios mit verschiedenen PHP Applikationen durchgespielt. Zum swapping kommt es nicht. Nur die CPU Last geht halt auf 2 oder 3

tuning-primer bescheinigt mir Configured Max Memory Limit : 541 M
so wollte ich es ja auch ungefähr haben. Bei 2GB RAM wär das ok denk ich.

Das hängt von Deinen Joins ab. Die Einstellung tmp_table_size gibt vor, ab wann er die Temp-Tables auf Disk erstellt.

heißt das es müsste irgendwann mal 0 sein wenn ich z.B. spaßeshalber mal 1GB angebe für die tmp_table_size? Ich hab mal gelesen dass bestimmte Tabellenformate immer auf Disk geschrieben werden.

Bleiben nur noch die seltsamen slow_queries. Kann ich mir nicht so recht erklären wann die 10 sekunden überschreiten sollten. Naja nicht so schlimm solange subektiv alles ratz-fatz läuft

Und die hohen Handler_read_rnd sind zu vernachlässigen oder?
Und löscht der Qcache eigentlich auch queries obwohl er erst zu 20% gefüllt ist? Kann man das irgendwie nachprüfen?

danke nochmal, dass Du dich durchgewurstelt hast

 

[Huschi]

Kann ich mir nicht so recht erklären wann die 10 sekunden überschreiten sollten.

Schalte das Logging an. Sowas kann z.B. unter Last passieren, wenn viele updates/inserts gelockt sind.

Und löscht der Qcache eigentlich auch queries obwohl er erst zu 20% gefüllt ist?

Ein Query wird aus dem Cache gelöscht, sobald
a) der Cache-Speicher voll ausgenutzt wird und der Query zu alt ist,
b) bei jedem Insert/Update/Delete auf den betroffenen Tabellen.

huschi.