RootForum Community

Guten Abend liebe Rootforumnutzer,
ich teste gerade 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 ca 3.5 Sekunden. Bei eingeschaltetem Q-Cache 0.1.

natürlich will ich die Werte folgender 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 im Rahmen zu halten.

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

MySQL server has been running for 0 days, 4 hours, 8 minutes and 23 seconds.
Handler_read_rnd 290 k
Handler_read_rnd_next 116 M

Können diese sich negativ auf die Stabilität auswirken oder andere schlechte Folgen haben?

was ich auch etwas seltsam finde ist folgendes
Slow_queries: 1,645

die slow query time habe ich auf 10 Sekunden, was eigentlich ja zu hoch ist. Mir wäre nie aufgefallen das irgend eine Seite auf dem Server so lange braucht zu laden (caches deaktivier).
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 bemerken 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 bekommt man das nie hin?

freue mich auf Eure Meinungen
Gruß

LOkiTOki wrote:MySQL server has been running for 0 days, 4 hours, 8 minutes and 23 seconds.
Handler_read_rnd 290 k
Handler_read_rnd_next 116 M

Die Read_Rnd Handler werden für Zugriffe ohne Index verwendet. Read_Rnd liest den ersten, Read_Rnd_Next dann die folgenden Werte bei einem Full Table Scan. Hohe Zahlen hier sind fast immer ein Indikator für eine fehlende oder (seltener) nicht mögliche Indizierung ("nicht möglich" ist eine Indizierung bei Reporting-Queries, die sowieso einen vollen Scan erfordern).

Können diese sich negativ auf die Stabilität auswirken oder andere schlechte Folgen haben?

Ja, klar. Ein Full Table Scan ist scheiße langsam. Du solltest jede Menge Einträge im Slow Log finden. Die Queries dort haben schlechte Pläne und müssen optimiert werden, durch Anlegen der fehlenden Indices oder durch Umschreiben der Query.

was ich auch etwas seltsam finde ist folgendes
Slow_queries: 1,645

Sag ich ja.


die slow query time habe ich auf 10 Sekunden, was eigentlich ja zu hoch ist. Mir wäre nie aufgefallen das irgend eine Seite auf dem Server so lange braucht zu laden (caches deaktivier).
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

Ja, aber warum?

Also, was bedeuten diese Werte Deiner Meinung nach und wieso hast Du gerade diese gewählt? Zum Beispiel

key_buffer_size = 192M
table_cache = 2048
tmp_table_size = 128M
max_heap_table_size = 128M
query_cache_size = 128M
myisam_sort_buffer_size = 32M
myisam_recover = FORCE,BACKUP
max_allowed_packet = 32M

Warum ist Deine key_buffer_size gerade 192M? Wie groß sind denn Deine Indices in MyISAM? Benutzt Du auch noch andere Engines?

Warum ist Dein Table_Cache 2048? Wie viele Tabellen hat Deine Datenbank?

Warum sind tmp_table_size und max_heap_table_size so hoch gestellt? Hast Du viele Queries, die große "using temporary" erzeugen? Warum tun die das? Sind das Sorts und Group By? Solltest Du dann nicht auch den Sort_buffer größer machen?

Wieso gerade 128M Query Cache Size? Wie ist Deine Treffer-Rate dort?

Wieso gerade 32M max_allowed_packet? Machst Du viel mit TEXT oder BLOB? Wieso?

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 bemerken oder anderen Bedingungen bemerken?

Eigentlich würde man lieber Queries haben, die Indices benutzen, dann gehen Read_rnd Handler automatisch runter, weil stattdessen Handler mit Index-Reads verwendet werden. Wie sehen denn Deine "show global status like 'select%' zahlen aus. Hast Du viele Full Joins?

Und wie bekomme ich "443 temp tables 10% were created on disk" auf 0% oder bekommt man das nie hin?

Die Quote ist leidlich okay. Doch, man bekommt das auf 0%, aber da muss man ein wenig für arbeiten. Queries legen Tmp_tables an, wenn sie "using temporary" sind im Explain. Eine solche Tabelle wird als MEMORY angelegt, wenn das geht. Das geht, wenn sie kleiner als tmp_table_size UND max_heap_table_size ist und wenn sie nur Typen enthält, die in MEMORY auch repräsentiert werden können - TEXT und BLOB-Typen jeder Art (auch TINYTEXT und TINYBLOB) können in MEMORY nicht repräsentiert werden, sondern zwingen die tmp_table immer on disk.

Select id, textfield from t where name like "xxx%" order by no_index_field

geht also immer using temporary (wegen des order by ohne Index) und die tmp_table geht immer auf Disk (wegen textfeidl im Select).