Sysbench OLTP-Benchmark

Der Sysbench OLTP-Anwendungs-Benchmark läuft auf einer MySQL-Datenbank, auf der die InnoDB-Speicher-Engine ausgeführt wird. Die Aufgabe der Speicher-Engine besteht darin, die Schnittstelle von der Datenbank auf der Festplatte zu den Anwendungen zu verwalten, die Daten in die und aus der Speicher-Engine lesen und schreiben. Die Speicher-Engine wiederum verwaltet E/A-Threads und Protokolle und verwaltet einen In-Memory-Cache, um den Festplattenzugriff zu minimieren. Die folgende Tabelle gibt einen vereinfachten Überblick über den Motor.

Der Sysbench OLTP-Anwendungs-Benchmark läuft auf einer MySQL-Datenbank, auf der die InnoDB-Speicher-Engine ausgeführt wird. Die Aufgabe der Speicher-Engine besteht darin, die Schnittstelle von der Datenbank auf der Festplatte zu den Anwendungen zu verwalten, die Daten in die und aus der Speicher-Engine lesen und schreiben. Die Speicher-Engine wiederum verwaltet E/A-Threads und Protokolle und verwaltet einen In-Memory-Cache, um den Festplattenzugriff zu minimieren. Die folgende Tabelle gibt einen vereinfachten Überblick über den Motor.

Da die InnoDB-Engine einen In-Memory-Cache namens Pufferpool vorhält, wird die Leistung direkt durch das Verhältnis der Arbeitssatzgröße zur Größe des Pufferpools beeinflusst. Mit anderen Worten: Wenn der Pufferpool groß genug ist, um den Arbeitssatz aufzunehmen, oder der Arbeitssatz klein genug ist, um in den Pufferpool zu passen, werden die meisten Vorgänge niemals E/A-gebunden sein. Wenn die Datenbank jedoch zu groß ist, um in den Speicher zu passen, bestimmt die E/A-Leistung die Transaktionsantwortzeiten und den Durchsatz. Wir charakterisieren die Leistung des Laufwerks in dieser Situation, in der die Datenbank nicht in den Speicher passt, was zu einem erhöhten E/A-Verkehr von der InnoDB-Speicher-Engine führt.

Mehrere Threads (die Anzahl hängt von der Datenbankkonfiguration für Hochleistungsanwendungen ab und variiert zwischen 32 und 128) lesen Daten nach dem Zufallsprinzip aus dem Sicherungsspeicher mit einer Blockgröße von 16 KB. Diese Lesevorgänge beziehen sich auf Datenbankabfragen, bei denen Daten vom Sicherungsspeicher angefordert werden. Während Lesevorgänge verarbeitet werden, werden sie automatisch im Pufferpool zwischengespeichert. Wenn sich der Pufferpool füllt, verwendet InnoDB eine LRU-Richtlinie (Least Recent Used), um ältere Seiten zu entfernen und Platz für neuere Daten zu schaffen.

Datenbankschreibvorgänge werden zunächst an das Transaktionsprotokoll und den Pufferpool weitergeleitet. Das Transaktionsprotokoll ist ein sequentiell beschriebener Ringpuffer, der bei jeder Schreibtransaktion aktualisiert wird. Abhängig von der MySQL-Konfiguration kann dieses Update zu einem sofortigen Schreibvorgang auf der Festplatte führen oder vorübergehend im RAM als Puffer verbleiben, der schließlich vom Dateisystem auf die Festplatte geleert wird. Die Größe dieses Protokollpuffers variiert, beträgt jedoch normalerweise etwa 256 MB. Empfohlene Einstellungen für die ACID-Konformität erfordern, dass die Protokollschreibvorgänge bei jedem Datenbank-Commit auf die Festplatte gelangen. Diese Schreibvorgänge sind 4 KB lang.

Das Protokoll führt nur „physiologische“ Schreibvorgänge durch, bei denen das Delta zwischen den vorherigen Daten und den neuen Daten geschrieben wird. Für die Originaldaten schreibt InnoDB in den Pufferpool im RAM, der ebenfalls asynchron geleert werden muss. Das Zurückschreiben der Daten in das Dateisystem ist konfigurierbar und erfolgt im Hintergrund. Die Schreibvorgänge sind ebenfalls 16 KB groß. Bei den Schreibvorgängen handelt es sich tatsächlich um Doppelschreibvorgänge, bei denen die Engine die Daten zunächst in einen Zwischenspeicherort schreibt, der als Doppelschreibpuffer bezeichnet wird. Die Engine kopiert diese Daten dann an ihren endgültigen Speicherort im Dateisystem. Dies ist notwendig, um das Problem der „zerrissenen Seite“ zu vermeiden, bei dem eine 16-KB-Datenbankseite aufgrund eines Stromausfalls oder eines anderen katastrophalen Ereignisses teilweise auf die Festplatte geschrieben wird.

Ursprünge des Sysbench-Benchmarks

Wir haben den Sysbench-Testaufbau nach mehreren Gesprächen mit in unser Labor gebracht Mikron darüber, wie sie reale MySQL-Anwendungsumgebungen für SSD-Tests und -Messungen simulieren. Sie entwickelten eine Testmethodik rund um Sysbench, nachdem sie herausgefunden hatten, dass synthetische Speicher-Benchmarks selten einen vollständigen Überblick darüber lieferten, wie sich ein Laufwerk unter einer bestimmten Anwendungsauslastung verhält. Der Sysbench-Test ermöglicht es Micron, eine Umgebung zu simulieren, die einer Standard-MySQL-Datenbank-Workload am nächsten kommt, die in Anwendungen wie Facebook, Craigslist und Booking.com weit verbreitet ist

Besonders eng haben wir mit Moussa Ba zusammengearbeitet, der als Mitautor dieses Artikels mitgeholfen hat. Moussa ist Softwareentwickler im PCIe-Entwicklungsteam von Micron, wo seine Arbeit die Optimierung von Anwendungs- und Systemsoftware für Hochleistungs-IO-Geräte umfasst.

Sysbench OLTP-Benchmark

Sysbench ist ein Systemleistungs-Benchmark, der ein OLTP-Testprofil (OnLine Transaction Processing) enthält. Der OLTP-Test ist keine Annäherung an einen OLTP-Test, sondern ein echter datenbankgestützter Benchmark, der Transaktionsabfragen an eine MySQL-Instanz in einer CentOS-Umgebung durchführt.

Der erste Schritt beim Einrichten des Benchmarks besteht darin, die Datenbank selbst zu erstellen. Dies erfolgt durch Angabe der Anzahl der Tabellen in der Datenbank sowie der Anzahl der Zeilen pro Tabelle. In unserem Test haben wir 100 Tabellen mit jeweils 10 Millionen Zeilen definiert, was zu einer Datenbank mit 1 Milliarde Einträgen führte. Diese Datenbank war 260 GB groß.

Sysbench verfügt über zwei Betriebsmodi: den Standardmodus, der in die Datenbank liest und schreibt, und einen Nur-Lese-Modus. Der Standard-R/W-Modus führt die folgenden Abfragetypen aus: 5 SELECT-Abfragen, 2 UPDATE-Abfragen, 1 DELETE-Abfrage und 1 INSERT. Betrachtet man die E/A-Zahlen, beträgt das beobachtete Lese-/Schreibverhältnis etwa 75 % Lesevorgänge und 25 % Schreibvorgänge.

Sysbench-Testumgebung

Speicherlösungen werden mit dem Sysbench OLTP-Benchmark getestet StorageReview Enterprise Test Lab Verwendung eigenständiger Server. Wir verwenden derzeit handelsübliche PowerEdge R730s von Dell, um sowohl eine realistische Leistung als auch ein solides Preis-Leistungs-Verhältnis zu bieten, wobei wir lediglich den Speicheradapter oder die Netzwerkschnittstelle ändern, um unseren R730 mit verschiedenen Speicherprodukten zu verbinden. Der PowerEdge R730 bietet nachweislich eine hervorragende Kompatibilität mit Geräten von Drittanbietern und ist damit eine hervorragende Plattform für diese vielfältige Testumgebung. Der R730 nutzt außerdem Intels leistungsstarke Architektur der Haswell-Klasse, die uns die Rechenleistung gibt, um eine breite Palette von Speicherangeboten richtig auszulasten und deren Leistungspotenzial zu maximieren.

Sysbench-Benchmark-Umgebung der ersten Generation

Lenovo ThinkServer RD630 – SATA/SAS/PCIe-Testplattform

• 2594-ABU Topseller-Modell
• Duale Intel E5-2650-CPUs (2.0 GHz, 8 Kerne, 20 MB Cache)
• 128 GB RAM (8 GB x 16 DDR3, 64 GB pro CPU)
• 100 GB Mikron RealSSD P400e SSD (über LSI 9207-8i) Boot-Laufwerk
• 960 GB Micron M500 (über 9207-8i) Vorgefertigter Datenbankspeicher
• CentOS 6.3 64-Bit
• Percona XtraDB 5.5.30-rel30.1
  • Datenbanktabellen: 100
  • Datenbankgröße: 10,000,000
  • Datenbankthreads: 32
  • RAM-Puffer: 24 GB

​​Sysbench-Benchmark-Umgebung der zweiten Generation

Dell PowerEdge R730 – SATA/SAS/PCIe-Testplattform

• Zwei Intel E5-2690 v3-CPUs (2.6 GHz, 12 Kerne, 30 MB Cache)
• 256 GB RAM (16 GB x 16 DDR4, 128 GB pro CPU)
• 100 GB Boot-SSD, 480 GB Datenbankspeicher-SSD
• 2 x Mellanox ConnectX-3 InfiniBand-Adapter
• 2 x Emulex 16 GB Dual-Port-FC-HBA
• 2 x Emulex 10GbE Dual-Port-NIC
• CentOS 6.6 64-Bit
• Percona XtraDB 5.5.30-rel30.1
  • Datenbanktabellen: 100
  • Datenbankgröße: 10,000,000
  • Datenbankthreads: 32
  • RAM-Puffer: 24 GB

Dell PowerEdge R730 Virtualisierter Sysbench-Cluster mit 4 Knoten

• Acht Intel E5-2690 v3-CPUs für 249 GHz im Cluster (zwei pro Knoten, 2.6 GHz, 12 Kerne, 30 MB Cache)
• 1 TB RAM (256 GB pro Knoten, 16 GB x 16 DDR4, 128 GB pro CPU)
• SD-Karten-Boot (Lexar 16 GB)
• 4 x Mellanox ConnectX-3 InfiniBand Adapter (vSwitch für vMotion und VM-Netzwerk)
• 4 x Emulex 16 GB Dual-Port-FC-HBA
• 4 x Emulex 10GbE Dual-Port-NIC
• VMware ESXi vSphere 6.0 / Enterprise Plus 8-CPU

Das Hauptziel dieser Plattform besteht darin, die Leistung von Unternehmensspeicher in einer tatsächlichen Unternehmensumgebung und Arbeitslast hervorzuheben, anstatt sich auf synthetische oder pseudosynthetische Arbeitslasten zu verlassen. Synthetische Workload-Generatoren können hervorragend zeigen, wie gut Speichergeräte mit einem kontinuierlichen synthetischen I/O-Muster funktionieren, sie berücksichtigen jedoch keine der anderen externen Variablen, die Aufschluss darüber geben, wie Geräte tatsächlich in Produktionsumgebungen funktionieren. Synthetische Workload-Generatoren haben den Vorteil, dass sie immer wieder ein sauberes I/O-Muster zeigen, aber sie werden niemals eine echte Produktionsumgebung reproduzieren. Die Einführung der Anwendungsleistung zusätzlich zu Speicherprodukten zeigt, wie gut der Speicher mit seinen Treibern, dem lokalen Betriebssystem, der getesteten Anwendung, dem Netzwerkstapel, dem Netzwerk-Switching und externen Servern interagiert. Dies sind Variablen, die ein synthetischer Workload-Generator einfach nicht berücksichtigen kann, und sie sind außerdem um eine Größenordnung ressourcen- und infrastrukturintensiver im Hinblick auf die für die Ausführung dieses speziellen Benchmarks erforderliche Ausrüstung.

Gesamtergebnisse der Sysbench-Leistung

Mit dem Sysbench OLTP-Benchmark testen wir verschiedenste Speicherlösungen, die die Mindestanforderungen der Testumgebung erfüllen. Um sich für den Test zu qualifizieren, muss das Speichergerät über eine nutzbare Kapazität von mehr als 260 GB verfügen und für den Betrieb unter stressigen Unternehmensbedingungen ausgelegt sein. Lokal angeschlossene Speichergeräte wie SAS-, SATA- und PCIe-SSDs werden auf einem Bare-Metal-Server mit einer Sysbench-Instanz getestet. Neuere SAN- und hyperkonvergente Plattformen führen entweder 4, 8, 12 oder 16 VMs gleichzeitig aus, um zu zeigen, wie gut mehrere Workloads gleichzeitig auf jeder VM funktionieren. Diese Testmethodik trägt dazu bei, die Leistungsvergleiche zwischen neueren hyperkonvergenten Systemen und herkömmlichen SAN-Speicher-Arrays zu entmystifizieren.

Hyperkonvergente/SAN-virtualisierte Sysbench-Leistungsergebnisse (16 VM-Aggregate)

Hyperkonvergente/SAN-virtualisierte Sysbench-Leistungsergebnisse (12 VM-Aggregate)

Hyperkonvergente/SAN-virtualisierte Sysbench-Leistungsergebnisse (8 VM-Aggregate)

Hyperkonvergente/SAN-virtualisierte Sysbench-Leistungsergebnisse (4 VM-Aggregate)

PCIe Application Accelerator / Multi-SSD/HDD RAID Sysbench-Leistungsergebnisse

Einzelne SAS-/SATA-SSD-Ergebnisse