Hier handelt es sich um die ersten Ergebnisse dieses Artikels: MySQL Benchmarking, Stress-Test, Optimierung. Für generelle Fragen und Anregungen bitte auch dort posten.
Um was geht es?
Um meine MySQL-Server zu optimieren, möchte ich zunächst meine Server vergleichen. Dadurch erhoffe ich mir ein paar Antworten zum Thema: "Was bringt eine schnellere CPU. mehr RAM, schnellere Festplatten, anderes Linux, andere Compiler flags."
Dazu gibt es die "MySQL Benchmark Suit", die normalerweise in jeder Installation enthalten ist. Sie eignet sich zum Vergleichen unterschiedlicher Installationen. Es ist KEIN Werkzeug um spezifische Daten oder Bedürfnisse zu testen. Desweiteren ist dieses Tool in Perl geschrieben - Windows-Benutzer werden damit evtl. Probleme haben.
Mitmachen
Ich werde in diesem Thread die Ergebnisse meiner Benchmarks posten. Natürlich ist Jeder dazu eingeladen dies auch zu tun da es zu Vergleichszwecken einfach interessant ist.
Anmerkungen:
- Bei den folgenden Tests ist meist die CPU der Flaschenhals. Es gibt aber auch Tests, die stark auf die Festplatte zugreifen.
- Multi-CPU Server können bei diesem Test nicht berücksichtigt werden, da alle Querys nacheinander ausgeführt werden.
- Die Benchmarks benötigen eine gewisse Zeit und (wie könnte es anders sein) lasten das System aus. Also bitte nachts laufen lassen!
- Änderungen an der my.cnf haben relativ wenig Auswirkungen. Warscheinlich weil es nur 1 Zugriff gleichzeitig ist und die test db nicht wirklich gross ist. Ich werde später noch Stress-Tests durchführen.
Wo sind die Scripte?
Gentoo: /usr/share/mysql/sql-bench/
SuSE: hier muss man das rpm "mysql-bench" installieren
Generell: Einfach die 4.x.x Sources runterladen, entpacken und da ist dann auch schon das "sql-bech" Verzeichnis.
Test Durchführung
Es handelt sich wie gesagt um eine Benchmark Suit. Es gibt also mehrere Tests. Diese können alle zusammen oder einzeln ausgeführt werden.
Ich empfehle die Tests einzeln zu starten, damit das System nicht allzulange beschäftigt ist. Außerdem ist es sinnvoll jeden Test mehrmals (ca. 4x) und möglichst isoliert (nachts?) durchzuführen. Interessant ist dabei nur der beste (schnellste) Durchlauf. Dadurch kann man äußere Einflüsse (andere, böse Benutzer) relativ gut ausschließen.
Starten der Tests
Code:
./run-all-tests server=mysql --user=root --password='geheim' --log --fast
Wie bereits erwähnt: Das kann auch mal ne Stunde dauern. Also die Tests lieber einzeln laufen lassen. Dazu aus dem obigen Code einfach das "run-all-tests" mit einem anderen Script aus dem Verzeichnis ersetzen.
Ergebnisse
Die liegen im Verzeichnis "output" (das bewirkt die Option --log). Jeder Test hat eine eigene Datei bekommen, die sich wunderbar mit cat oder less anzeigen lässt.
Falls man alle Tests durchgeführt hat, sollte das Output-verzeichnis in etwas so aussehen:
HTML-Code:
ATIS-mysql_fast-Linux_2.6.14_gentoo_r5_i686
RUN-mysql_fast-Linux_2.6.14_gentoo_r5_i686
alter-table-mysql_fast-Linux_2.6.14_gentoo_r5_i686
big-tables-mysql_fast-Linux_2.6.14_gentoo_r5_i686
connect-mysql_fast-Linux_2.6.14_gentoo_r5_i686
create-mysql_fast-Linux_2.6.14_gentoo_r5_i686
insert-mysql_fast-Linux_2.6.14_gentoo_r5_i686
select-mysql_fast-Linux_2.6.14_gentoo_r5_i686
transactions-mysql_fast-Linux_2.6.14_gentoo_r5_i686
wisconsin-mysql_fast-Linux_2.6.14_gentoo_r5_i686
Die Datei RUN-mysql_fast-Linux_2.6.14_gentoo_r5_i686 beinhaltet eine Zusammenfassung aus der ich auch die Daten entnehme, die ich hier posten werde.
Was bedeuten die vielen Zahlen?
Hier mal mein Output für den connect-Test:
HTML-Code:
Testing server 'MySQL 4.0.24/' at 2006-03-12 16:43:57
Testing the speed of connecting to the server and sending of data
Connect tests are done 10000 times and other tests 100000 times
Testing connection/disconnect
Time to connect (10000): 11 wallclock secs ( 6.28 usr 0.72 sys + 0.00 cusr 0.00 csys = 7.00 CPU)
Test connect/simple select/disconnect
Time for connect+select_simple (10000): 12 wallclock secs ( 6.62 usr 0.82 sys + 0.00 cusr 0.00 csys = 7.44 CPU)
Test simple select
Time for select_simple (100000): 5 wallclock secs ( 1.92 usr 1.01 sys + 0.00 cusr 0.00 csys = 2.93 CPU)
Test simple select
Time for select_simple_cache (100000): 5 wallclock secs ( 1.94 usr 1.01 sys + 0.00 cusr 0.00 csys = 2.95 CPU)
Testing connect/select 1 row from table/disconnect
Time to connect+select_1_row (10000): 14 wallclock secs ( 7.17 usr 0.84 sys + 0.00 cusr 0.00 csys = 8.01 CPU)
Testing select 1 row from table
Time to select_1_row (100000): 9 wallclock secs ( 2.52 usr 1.31 sys + 0.00 cusr 0.00 csys = 3.83 CPU)
Time to select_1_row_cache (100000): 7 wallclock secs ( 2.24 usr 1.22 sys + 0.00 cusr 0.00 csys = 3.46 CPU)
Testing select 2 rows from table
Time to select_2_rows (100000): 10 wallclock secs ( 2.48 usr 1.63 sys + 0.00 cusr 0.00 csys = 4.11 CPU)
Test select with aritmetic (+)
Time for select_column+column (100000): 9 wallclock secs ( 2.27 usr 1.25 sys + 0.00 cusr 0.00 csys = 3.52 CPU)
Testing retrieval of big records (65000 bytes)
Time to select_big_str (10000): 18 wallclock secs ( 8.29 usr 1.77 sys + 0.00 cusr 0.00 csys = 10.06 CPU)
Total time: 100 wallclock secs (41.73 usr 11.58 sys + 0.00 cusr 0.00 csys = 53.31 CPU)
"wallclock secs": Gesamtzeit für die Ausführung
"usr, sys, cursr, csys": Overhead des Clients
Der interessante Wert errechnet sich also aus wallclock minus Overhead.
Bei meiner "Total time" entspricht das 46,69 Sekunden.
Lesezeichen