☰

Suche nach Vergleichen der Festplatten-E/A für einen dedizierten MySQL-Server

tag-icon • tag-icon mysql performance performance-tuning
Suche nach Vergleichen der Festplatten-E/A für einen dedizierten MySQL-Server

Wir beauftragten einen Berater, der uns dabei helfen sollte, die Kapazität unseres MySQL-Clusters zu erhöhen. Das Erste (und fast Einzige), was er tat, war, die Festplatten-E/A-Geschwindigkeit unserer Server zu messen.

Mich interessiert ein Vergleich der Festplatten-E/A auf ähnlichen Systemen wie unserem:

  • Unsere MySQL-Server sind virtuelle Server, die auf 32-Bit VMWare ESX 3.5 mit einem SCSI SAN (Raid 5) laufen, und die virtuellen Server selbst laufen unter Debian Etch und MySQL Version 5.0.32

Das Ausführen der folgenden Befehle auf der MySQL-Box führt bei mir zu diesen Ergebnissen (die der Berater als „furchtbar langsam“ beschrieb):

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 71.3347 seconds, 14.7 MB/s
real    1m13.596s
user    0m0.052s
sys 0m56.932s

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 21.8202 seconds, 48.1 MB/s
real    0m21.902s
user    0m0.012s  
sys 0m7.948s

Sind diese Ergebnisse tatsächlich „furchtbar langsam“?

Mich würde interessieren, welche Ergebnisse andere Leute mit diesen beiden Befehlen auf ihren dedizierten MySQL-Boxen erzielen – insbesondere, wenn es sich um eine 32-Bit-virtuelle Maschine handelt.

Antwort1

Beachten Sie, dass Ihr dd-Befehl den Dateisystem-Cache des Betriebssystems nicht umgeht. Das bedeutet, dass Sie je nach den anderen Vorgängen unterschiedliche Ergebnisse erhalten und erhebliche Leistungsunterschiede feststellen, wenn Sie die Ausgabegröße erhöhen (und damit Ihren FS-Cache erschöpfen).

Fügen Sie "oflag=direct" hinzu, um den Dateisystem-Cache der Ausgabedatei zu umgehen, z. B.

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 oflag=direct

Sie können den Dateisystem-Cache zum Lesen umgehen, indem Sie iflag=direct verwenden

Außerdem hängt die Leistung stark von der Blockgröße ab. 1 M ist zwar ein ziemlich guter Kompromiss zum Testen sequentieller Schreibvorgänge, aber es sei denn, Ihre Anwendung schreibt 1 M-Blöcke, ist dies nicht repräsentativ für Ihre tatsächliche Leistung.

Generell sind diese Durchsatzzahlen ziemlich miserabel – ein einzelnes SATA-Laufwerk (wie etwa die Seagate ES.2-Laufwerke) kann beim sequentiellen Schreiben zu Beginn des Laufwerks einen Spitzenwert von 105 MB/s erreichen und über die gesamte Laufzeit des Laufwerks eine Geschwindigkeit von ca. 60 MB/s aufrechterhalten.

Schließlich empfehlen allgemeine Datenbank-Best Practices, RAID5/6 als zugrunde liegendes System für eine Datenbank zu vermeiden, da der durch Paritätsschreibvorgänge verursachte Overhead relativ hoch ist (nicht die eigentliche Paritätsberechnung selbst, die in Hardware relativ günstig ist, sondern die Auswirkung zusätzlicher Lese- und Schreibvorgänge beim Schreiben neuer Paritäten).

Antwort2

Hier sind die Ergebnisse von meinem MySQL-Server. Es ist eine 64-Bit-Maschine, keine virtuelle Maschine, daher bin ich mir nicht sicher, wie nützlich sie wirklich ist, aber es gibt einen sehr großen Unterschied.

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.72139 s, 183 MB/s
0.00s user 1.55s system 27% cpu 5.725 total

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.432328 s, 2.4 GB/s
0.00s user 0.45s system 103% cpu 0.436 total

Antwort3

in den meisten Fällen sollten Sie auch random io vergleichen [ zB mitbonnie++] nicht nur lineares Lesen/Schreiben. Oder ist es vielleicht ein großer Datenspeicher, der Protokolle erstellt und in einer großen, nicht indizierten Tabelle speichert?

Ergebnisse für dd 'Benchmark'

szcapp1:/mnt/big/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.26186 s, 246 MB/s

real    0m4.563s
user    0m0.001s
sys     0m2.255s
szcapp1:/mnt/big/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.457162 s, 2.3 GB/s

real    0m0.459s
user    0m0.000s
sys     0m0.459s
szcapp1:/mnt/big/tmp#

64-Bit-Linux auf Dell Poweredge 2950, ​​Perc6 RAID 10 auf 5 Desktop-SATA-Festplatten mit 500 GB. 16 GB RAM, 2 Quad-Core 2,66 GHz. Aber hey! Das ergibt keinen Sinn – diese Daten passen zu 1/4 in den Cache-Speicher des RAID-Controllers und der Rest in den Systemspeicher.

Ihre Ergebnisse sind in der Tat langsam. Ergebnisse von einer VM unter Linux oben [32-Bit-Linux-Gast unter VMware Server 2.0]:

vfeed0:/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 15.996 s, 65.6 MB/s

real    0m16.043s
user    0m0.016s
sys     0m13.117s
vfeed0:/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.49413 s, 2.1 GB/s

real    0m0.505s
user    0m0.000s
sys     0m0.500s
vfeed0:/tmp#

Bedenken Sie, dass die Leseleistung nicht echt ist – es wird aus dem Cache gelesen – wenn nicht aus dem Cache des Gasts, dann sicherlich aus dem Cache des VMware-Hosts.

Antwort4

Etwas abseits von Ihrer ursprünglichen Frage; aber die Antwort des SAN-Anbieters auf „RAID 5 ist langsam“ ist die Konvertierung auf RAID 1 oder RAID 10. Berücksichtigen Sie auch die VMFS-Ausrichtung (PDF) kann die Leistung erheblich beeinträchtigen.

verwandte Informationen