Diskussion was mir da jetzt an den Statistiken auffällt sind, die
> abgebrochenen Verbindungen, wobei ich nicht weiß ob die bei der Anzahl
> der Versuche nicht normal sind
http://board.issociate.de/thread/458440/
#22: Re: MySQL Performance CPU 100%
Posted on 2007-10-04 15:42:47 by Axel Schwenke
Kostja <<a href=“mailto:anmeldung@kruta.de“>anmeldung@kruta.de style=“margin: 0px; padding: 0px;“>wrote:
>
> Also der Server lief jetzt die Nacht durch. Das
> einzige, was mir da jetzt an den Statistiken auffällt sind, die
> abgebrochenen Verbindungen, wobei ich nicht weiß ob die bei der Anzahl
> der Versuche nicht normal sind. (?)
>
> Aborted_clients 0
> Aborted_connects 1293
> Connections 292837
Etwa 0.3% – vermutlich nicht relevant. Trotzdem seltsam.
> Bytes_received 18906545136
> Bytes_sent 18911218699
Das finde ich seltsam angesichts
> Com_delete 16156
> Com_insert 17655
> Com_update 219635
vs.
> Com_select 130492078
Allerdings – seit ich die eine Query letztens gesehen habe, wundert
mich das nicht mehr ganz so. Wer hat dieses SQL denn verbrochen?
Und da oben: sind das Mass-Inserts? Oder liefern deine SELECTs immer
nur sehr wenig Daten?
> Created_tmp_disk_tables 11402
> Created_tmp_tables 84269
Das sieht nicht zu schlecht aus.
> Handler_read_first 25907
> Handler_read_key 190930007
> Handler_read_next 142093340
> Handler_read_prev 46123
> Handler_read_rnd 1028719
> Handler_read_rnd_next 24581337
Das sieht sogar ausgesprochen gut aus: die weitaus meisten Zugriffe
gehen über einen Index und liefern auch nur einen Wert.
> Innodb_buffer_pool_pages_total 512
Das ist der Default von 8MB, der typischerweise viel zu klein ist, aber
> Innodb_buffer_pool_read_requests 73437272
> Innodb_buffer_pool_reads 175106
…. offensichtlich hast du nicht viel Daten in InnoDB-Tabellen, so daß
das trotzdem für >99% hitrate reicht.
> Key_blocks_unused 417490
> Key_blocks_used 11202
Der key_buffer ist dafür deutlich überdimensioniert (allerdings ist das
nicht schlimm, weil der on-demand alloziert wird)
> Open_tables 280
> Opened_tables 398
Der table_cache ist auch groß genug.
> Qcache_hits 5397983
> Qcache_inserts 130312503
Der Query-Cache funktioniert anscheinend gar nicht. Würde ich
abschalten (Größe auf 0 setzen)
> Slow_queries 42896
Huch? Hattest du nicht was von 0 erzählt?
> Questions 137021797
> Uptime 42359
Macht nach Adam Riese 3234 Queries pro Sekunde. Das ist ne Menge Holz.
Kann ich dem MySQL nicht übelnehmen, daß es dafür ordentlich an der CPU
saugt. Insbesondere weil der Query-Cache so gar nicht wirkt.
Kannst du sagen, zu wieviel Pageviews pro Sekunde das korrespondiert?
Oder anders gefragt: wieviele Queries macht denn deine Applikation pro
ausgelieferter Seite? Vermutlich ist das ein zu hoher Wert (10-20 würde
ich als normal bezeichnen).
Mit SQL-Optimierung wird man sicher noch das eine oder andere heraus
holen können, aber mehr als Faktor 2 bringt das kaum (es sei denn, da
sind noch fette Klopper a’la … LIKE ‚%foo%‘ … drin).
Die Strategie sollte jetzt sein, möglichst wenig Daten aus der Daten-
bank zu holen und statt dessen mehr statischen Content zu haben.
Memcache eignet sich z.B. prima, um häufig gebrauchte Daten zu cachen.
Die allereinfachste Variante wäre, dynamischen Content mit geeigneten
Expires: Headern zu versehen und einen caching Proxy vor den Webserver
zuu stellen. Kommt aber alles sehr auf die Applikation an.
Man könnte auch überlegen, Daten so aufzuteilen, daß der Query-Cache
nicht so viel Ergebnisse invalidieren muß. Also häufig geänderte Daten
von den eher statischen trennen (verschiedene Tabellen).
Angesichts der anscheinend kleinen Datenmenge (in Relation zum verfüg-
baren RAM) könnte man auch überlegen, alles auf InnoDB umzustellen.
Das ist aber ein zweischneidiges Schwert. Würde ich erst sehr gründlich
auf einem separaten System testen wollen. Wenn genügend RAM da ist, ist
InnoDB sauschnell.
Der nächste Schritt zum Wachstum wäre dann Replikation. Eine Variante
die mir besonders zusagt, ist Webserver und Replikat jeweils auf eine
Maschine zu packen und mehrere davon (bis mittlere zweistellige Zahlen
sind machbar) parallel zu betreiben. Dann gehen alle Lesezugriffe auf
die lokale Datenbank und die Skalierung ist automatisch gegeben –
zumindest so lange bis der Master das Bottleneck wird.
XL<<a href=“mailto:/anmeldung@kruta.de“>/anmeldung@kruta.de>