Sysbench OLTP ベンチマーク

Sysbench OLTP アプリケーション ベンチマークは、InnoDB ストレージ エンジンを実行する MySQL データベース上で実行されます。ストレージ エンジンの仕事は、ディスク上のデータベースから、ストレージ エンジンとの間でデータを読み書きするアプリケーションへのインターフェイスを管理することです。ストレージ エンジンは IO スレッドとログを管理し、メモリ内キャッシュを保持してディスク アクセスを最小限に抑えます。以下の図は、エンジンの簡単な概要を示しています。

Sysbench OLTP アプリケーション ベンチマークは、InnoDB ストレージ エンジンを実行する MySQL データベース上で実行されます。ストレージ エンジンの仕事は、ディスク上のデータベースから、ストレージ エンジンとの間でデータを読み書きするアプリケーションへのインターフェイスを管理することです。ストレージ エンジンは IO スレッドとログを管理し、メモリ内キャッシュを保持してディスク アクセスを最小限に抑えます。以下の図は、エンジンの簡単な概要を示しています。

InnoDB エンジンはバッファ プールと呼ばれるメモリ内キャッシュを保持するため、パフォーマンスはバッファ プールのサイズに対するワーキング セットのサイズの比率に直接影響されます。つまり、バッファー プールがワーキング セットを保持できるほど大きい場合、またはワーキング セットがバッファー プールに収まるほど小さい場合、ほとんどの操作が IO バインドされることはありません。ただし、データベースが大きすぎてメモリに収まらない場合は、IO パフォーマンスによってトランザクションの応答時間とスループットが決まります。データベースがメモリに収まらないため、InnoDB ストレージ エンジンからの IO トラフィックが増加するこの状況でのドライブのパフォーマンスを特徴付けています。

複数のスレッド (その数は高パフォーマンス アプリケーションのデータベース構成によって異なり、32 から 128 まで変化します) が、ブロック サイズ 16K バイトのバッキング ストアからランダムな方法でデータを読み取ります。これらの読み取りは、バッキング ストアからのデータを要求するデータベース クエリに関連しています。読み取りが処理されると、それらは自動的にバッファー プールにキャッシュされます。バッファ プールがいっぱいになると、InnoDB は LRU (最も最近使用されていない) ポリシーを使用して古いページを削除し、新しいデータ用のスペースを確保します。

データベースへの書き込みは、まずトランザクション ログとバッファ プールに送られます。トランザクション ログは、書き込みトランザクションごとに更新される、順次書き込まれるリング バッファです。 MySQL の構成に応じて、この更新により即座にディスクへの書き込みが行われる場合もあれば、最終的にファイル システムによってディスクにフラッシュされるバッファとして RAM に一時的に保持される場合もあります。このログ バッファのサイズはさまざまですが、通常は約 256MB です。 ACID 準拠の推奨設定では、データベースのコミットごとにログの書き込みがディスクにヒットする必要があります。これらの書き込みの長さは 4K です。

ログは、以前のデータと新しいデータの間の差分が書き込まれる「生理学的」書き込みのみを実行します。元のデータの場合、InnoDB は RAM 内のバッファ プールに書き込みますが、これも非同期で空にする必要があります。データをファイル システムに書き戻すプロセスは構成可能であり、バックグラウンドで実行されます。書き込みも16Kです。実際の書き込みは二重書き込みであり、エンジンは最初に二重書き込みバッファーと呼ばれる中間の場所にデータを書き込みます。次に、エンジンはそのデータをファイル システム内の最終的な場所にコピーします。これは、停電やその他の致命的なイベントにより、16KB データベース ページの一部がディスクに書き込まれる「ページ切れ」問題を回避するために必要です。

Sysbench ベンチマークの起源

私たちは、何回か話し合いを行った後、Sysbench テスト セットアップをラボに導入しました。 ミクロン SSD のテストと測定のために実際の MySQL アプリケーション環境をシミュレートする方法について説明します。彼らは、合成ストレージのベンチマークでは、特定のアプリケーションのワークロード下でドライブがどのように動作するかを完全に把握できることはほとんどないことに気づき、Sysbench を中心としたテスト方法論を開発しました。 Sysbench テストにより、Micron は、Facebook、Craigslist、Booking.com などのアプリケーションで普及している標準の MySQL データベース ワークロードに最も近い環境をシミュレートできます。

私たちは、この記事の共著者となった Moussa Ba と特に緊密に連携しました。 Moussa は、Micron の PCIe 開発チームのソフトウェア エンジニアであり、高性能 IO デバイス向けのアプリケーションおよびシステム ソフトウェアの最適化などの仕事を行っています。

Sysbench OLTP ベンチマーク

Sysbench は、オンライン トランザクション処理 (OLTP) テスト プロファイルを含むシステム パフォーマンス ベンチマークです。 OLTP テストは OLTP テストの近似ではなく、CentOS 環境で MySQL のインスタンスに対してトランザクション クエリを実行する、データベースに基づいた真のベンチマークです。

ベンチマークを設定する最初のステップは、データベース自体を作成することです。これは、データベース内のテーブルの数とテーブルごとの行数を指定することによって行われます。私たちのテストでは、それぞれ 100 万行を持つ 10 のテーブルを定義しました。その結果、1 億エントリのデータベースが作成されました。このデータベースは 260GB でした。

Sysbench には、データベースの読み取りと書き込みを行うデフォルト モードと読み取り専用モードの 5 つの動作モードがあります。デフォルトの R/W モードでは、2 つの SELECT クエリ、1 つの UPDATE クエリ、1 つの DELETE クエリ、および 75 つの INSERT クエリ タイプが実行されます。 IO カウントを見ると、読み取り/書き込み比率は読み取りが約 25%、書き込みが XNUMX% であることがわかります。

Sysbench テスト環境

ストレージ ソリューションは、Sysbench OLTP ベンチマークでテストされています。 StorageReview エンタープライズ テスト ラボ スタンドアロンサーバーを利用します。現在、デルの既製チャネルの PowerEdge R730 を利用して、現実的なパフォーマンスと確かな価格性能比の両方を示しており、R730 をさまざまなストレージ製品に接続するためにストレージ アダプタまたはネットワーク インターフェイスのみを変更しています。 PowerEdge R730 は、サードパーティ製デバイスとの優れた互換性を提供することが証明されており、この多様なテスト環境にとって優れた頼りになるプラットフォームとなっています。 R730 は、Intel の強力な Haswell クラス アーキテクチャも活用しており、幅広いストレージ製品に適切に負荷をかけ、パフォーマンスの可能性を最大限に引き出すコンピューティング能力を提供します。

第 1 世代の Sysbench ベンチマーク環境

レノボ ThinkServer RD630 – SATA/SAS/PCIe テスト プラットフォーム

• 2594-ABU トップセラーモデル
• デュアル Intel E5-2650 CPU (2.0GHz、8 コア、20MB キャッシュ)
• 128GB RAM (8GB x 16 DDR3、CPU あたり 64GB)
• 100GBミクロン RealSSD P400e SSD (LSI 9207-8i経由) ブートドライブ
• 960GB Micron M500 (9207-8i 経由) 構築済みデータベース ストレージ
• CentOS 6.3 64 ビット
• Percona XtraDB 5.5.30-rel30.1
  • データベーステーブル: 100
  • データベースのサイズ: 10,000,000
  • データベーススレッド: 32
  • RAMバッファ: 24GB

第 2 世代 Sysbench ベンチマーク環境

Dell PowerEdge R730 – SATA/SAS/PCIe テスト プラットフォーム

• デュアル Intel E5-2690 v3 CPU（2.6 GHz、12 コア、30 MB キャッシュ）
• 256GB RAM (16GB x 16 DDR4、CPU あたり 128GB)
• 100GB ブート SSD、480GB データベース ストレージ SSD
• 2 x Mellanox ConnectX-3 InfiniBand アダプター
• 2 x Emulex 16GB デュアルポート FC HBA
• 2 x Emulex 10GbE デュアルポート NIC
• CentOS 6.6 64 ビット
• Percona XtraDB 5.5.30-rel30.1
  • データベーステーブル: 100
  • データベースのサイズ: 10,000,000
  • データベーススレッド: 32
  • RAMバッファ: 24GB

Dell PowerEdge R730 仮想化 Sysbench 4 ノード クラスター

• クラスター内の 5 GHz 用の 2690 つの Intel E3-249 v2.6 CPU (ノードごとに 12 つ、30 GHz、XNUMX コア、XNUMX MB キャッシュ)
• 1TB RAM (ノードあたり 256GB、16GB x 16 DDR4、CPU あたり 128GB)
• SDカードブート(Lexar 16GB)
• 4 x Mellanox ConnectX-3 InfiniBand アダプター (vMotion および VM ネットワーク用の vSwitch)
• 4 x Emulex 16GB デュアルポート FC HBA
• 4 x Emulex 10GbE デュアルポート NIC
• VMware ESXi vSphere 6.0/Enterprise Plus 8-CPU

このプラットフォームの主な目標は、合成または疑似合成ワークロードに依存するのではなく、実際のエンタープライズ環境およびワークロードでエンタープライズ ストレージがどのように機能するかを強調することです。合成ワークロード ジェネレーターは、連続的な合成 I/O パターンでストレージ デバイスがどのようにパフォーマンスを発揮するかを示すのに優れていますが、実稼働環境でデバイスが実際にどのように動作するかを明らかにする他の外部変数は考慮されていません。合成ワークロード ジェネレーターには、クリーンな I/O パターンを何度も表示できるという利点がありますが、真の運用環境を複製することはできません。ストレージ製品上にアプリケーションのパフォーマンスを導入すると、ストレージがそのドライバー、ローカル オペレーティング システム、テスト対象のアプリケーション、ネットワーク スタック、ネットワーク スイッチング、および外部サーバーとどの程度うまく相互作用するかがわかります。これらは、合成ワークロード ジェネレーターでは考慮できない変数であり、また、この特定のベンチマークを実行するために必要な機器の点で、リソースとインフラストラクチャの消費量が桁違いに多くなります。

Sysbench の全体的なパフォーマンス結果

当社では、テスト環境の最小要件を満たす Sysbench OLTP ベンチマークを使用して、幅広いストレージ ソリューションをテストしています。テストの対象となるには、ストレージ デバイスが 260 GB を超える使用可能な容量を備え、ストレスの多い企業条件下での動作に対応している必要があります。 SAS、SATA、PCIe SSD などのローカルに接続されたストレージ デバイスは、4 つの Sysbench インスタンスを備えたベアメタル サーバーでテストされます。新しい SAN およびハイパーコンバージド プラットフォームでは、8、12、16、または XNUMX 個の VM が同時に実行され、複数のワークロードがそれぞれの VM 上で同時にどの程度適切に動作するかを示します。このテスト方法は、新しいハイパーコンバージド システムと従来の SAN ストレージ アレイ間のパフォーマンスの比較をわかりやすくするのに役立ちます。

ハイパーコンバージド/SAN 仮想化 Sysbench のパフォーマンス結果 (16 VM の合計)

ハイパーコンバージド/SAN 仮想化 Sysbench のパフォーマンス結果 (12 VM の合計)

ハイパーコンバージド/SAN 仮想化 Sysbench のパフォーマンス結果 (8 VM の合計)

ハイパーコンバージド/SAN 仮想化 Sysbench のパフォーマンス結果 (4 VM 合計)

PCIe アプリケーション アクセラレータ / マルチ SSD/HDD RAID Sysbench のパフォーマンス結果

個々の SAS / SATA SSD の結果