MySQL サーバーにおける SSD パフォーマンスの問題の詳細な分析とテスト

【質問】

HP サーバーを使用しています。SSD が IOPS 約 5000 を書き込むと、%util が 80% を超えます。この SSD のパフォーマンスに問題があるのでしょうか? この問題を解決するために、次のテストを実施しました。

【道具】

Blktrace は、Linux での IO パフォーマンスのトラブルシューティングに使用されるツールです。 IO が実行するさまざまなステップを記録し、各段階での IO 要求の消費量を計算できます。次に、いくつかの重要なステップを示します。

Q2G – 再マップと分割時間を含む、IO 要求の生成に費やされた時間。

G2I – IO 要求が IO スケジューラに入るのにかかる時間（マージ時間を含む）。

I2D – IO 要求が IO スケジューラ内で待機する時間。

D2C – ドライバーとハードウェア間で IO 要求が完了するまでにかかる時間。

Q2C – IO 要求全体に費やされた時間 (G2I + I2D + D2C = Q2C)。これは、iostat の待機に相当します。

D2C はハードウェア パフォーマンスの指標として使用でき、I2D は IO スケジューラ パフォーマンスの指標として使用できます。

[テスト 1: HP SSD Smart Path を有効にする前後の SSD 書き込みパフォーマンスの比較]

1. HP SSD Smart Path が有効、SSD コントローラー キャッシュが無効、キャッシュ比率: 読み取り 100% / 書き込み 0%

テスト結果は以下のとおりで、D2C（SSD上のIO要求にかかる時間）のAVG値に着目すると、約0.217msである。

2. HP SSD Smart Path はオフ、SSD コントローラー キャッシュはオン、キャッシュ比率: 読み取り 10% / 書き込み 90%

テスト結果は以下のとおりで、D2C（SSD上のIO要求によって消費される時間）のAVG値に着目すると、約0.0906msである。

【結論は】

前者は後者よりもハードウェア上で約 2.4 倍の時間がかかります。書き込みベースのシステムの場合は、HP SSD Smart Path を無効にし、SSD コントローラー キャッシュを有効にすることをお勧めします。

[テスト 2: noop と deadline I/O スケジューリング アルゴリズムのパフォーマンスの比較]

現在、ディスク スケジューリング アルゴリズムは 4 つあります。当社のシステムのアルゴリズムは Deadline として構成されており、多くのドキュメントでは SSD を noop として構成することが推奨されています。

1. 先行型、個人用 PC、単一ディスク システムに適しています。

2. CFQ (Complete Fair Queuing)、デフォルトのIOスケジューリングアルゴリズム、完全に公平なキューイングスケジューリングアルゴリズム

3. 期限: 期限に応じて各IOキューをスケジュールする

4. noop、単純なFIFOキュースケジューリング

以下のテストは、HP SSD Smart Path を無効にした状態で実施されました。

1. 締め切り、主にG2IとI2Dに焦点を当てる

2. noopに変更する

【結論は】

noop IO Scheduler は、待機時間と消費時間の点で、deadline よりもわずかに優れたパフォーマンスを発揮しますが、その差はそれほど大きくありません。評価が必要な場合は、さまざまなシナリオでさらに詳細なテストを行う必要があります。

次の図は、オンライン データに基づくさまざまなスケジューリング アルゴリズムのテスト比較です。

[テスト3: このサーバーSSDの消費時間を、同じ構成のSSDの消費時間と比較する]

AVG D2C は 0.0906ms と 0.0934ms でほとんど差がなく、このサーバーの SSD は応答時間の点で正常であることがわかります。

要約する

上記はこの記事の全内容です。この記事の内容が皆さんの勉強や仕事に一定の参考学習価値を持つことを願っています。ご質問があれば、メッセージを残してコミュニケーションしてください。123WORDPRESS.COM を応援していただきありがとうございます。