サーバーと仮想マシン

サーバー・ストレージのキューの深さとNVMeのパフォーマンスを理解する

NVMeパフォーマンス キューの深さがワークロードにマッチすればするほど、アプリケーションのレスポンスは速くなる。キューの深さ、IOPS、レイテンシーがどのように相互作用しているのか、また、ほんの少しの測定で顕著に短いレスポンスタイムを達成できる方法を説明する。.

中心点

キューの深さ は並列性を制御し、レイテンシとIOPSに影響を与える。.
NVMe 多くのキューとコマンドを同時に処理する。.
レイテンシー ウェブワークロードでは、純粋な帯域幅よりも重要です。.
ワークロード は理想的なキューの深さを決定する。.
測定値 負荷がかかると、より良いセッティングにつながる。.

キューの深さとはどういう意味ですか？

仝 キュー は、コントローラがメモリコマンドを実行する前に、ドライバがメモリコマンドを収集するキューである。キュー深度が低いと、短い待ち時間が優先されるが、同時アクセスが多い場合にはボトルネックとなる。キュー深度を高くすると並列性が高まるが、ある時点から待ち時間が長くなる。そのため、スレッド数、IOサイズ、アクセスパターンに合わせてキューの深さを設定します。バランスをとるなら、既存の ハードウェア そして、アイドリングやキューの肥大化を防ぐ。.

NVMeがここで輝く理由

NVMe は多くの独立したキューを提供し、キューあたりのコマンド数を多くすることで、マルチコアCPUの並列動作を可能にしている。これは、1つのコマンド・キューがすぐに一杯になってしまうSATAとの接続を明確に区別するものである。小さなランダムアクセスが多いウェブワークロードでは、この並列性が短いレスポンスタイムをもたらします。私は、複数のキューにプロセスを分散させ、都合の良いときに小さなIOをバンドルすることで、この強みを利用している。これにより、実効的な レイテンシー, 指揮官率は上昇する。.

IOPS、レイテンシ、スループットの相互作用

私の評価 IOPS, レイテンシとスループットは互いに影響し合うため、決して切り離すことはできない。多くの小さなランダムIOは低いレイテンシを必要とするが、シーケンシャルな転送はより多くの帯域幅を必要とする傾向がある。キュー深度は、ここでのスイートスポットをシフトする：値を大きくするとIOPSが増加することが多いが、1回のアクセス時間が長くなることがある。そのため、現実的なブロックサイズ（4K、8Kなど）と、読み取り/書き込みの混在で測定しています。この相互作用のみで スイートスポット は嘘をついています。

キューの深さ	標準IOPS（ランダム4K、混合）	ミディアム・レイテンシー	適合性
1	ロー	非常に低い	シングルスレッドでレイテンシが非常に重要なリクエスト
4	ミディアム	ロー	ウェブAPI、小規模データベース、CMS
16	高い	控えめ	電子商取引、高度に並列化された労働者
64	非常に高い	より高い	バッチジョブ、多数のスレッド、キューの多いプロセス

測定方法：ウォームアップ、P99、テール・レイテンシーを正確に読み取る

短時間のテストは当てになりません。NVMe SSDは、数秒後に夢のような値を示すことがよくありますが、連続運転では崩れてしまいます。そのため、テストをウォームアップしています(ランプタイムと測定する。 時間ベース になるまで数分間 定常状態 に達する。平均値に加え、私が特に興味を持っているのは P95/P99-レイテンシとヒストグラムの分布。異常値は多くの場合、GC、SLCキャッシュのオーバーフロー、サーマルスロットリング、フラッシュイベントによって引き起こされます。私は提出- より 完全な待ち時間 (slat/clat）を使って、CPUやドライバのオーバーヘッドとデバイスの応答時間を区別している。このようにして、私は厩舎応答時間 - ピーク値だけでなく.

QD、スレッド、io_uring：何が本当にパラレルなのか？

QDはしばしば糸の本数と混同される。決定的な要因は 同時に傑出した デバイスとキューごとのIO。インフライトIOを持たない多くのスレッドはQDを増加させない。逆に、非同期APIを持つ単一のスレッド（例えば. io_uring)が高いQDを達成している。私は、スレッド数×スレッドあたりのアイオデプス数×キュー数の関係に注目している。NVMeでは、完了/投入キューの数はCPUコア（MSI-Xベクトル）に応じてスケールする。コア、割り込み、キュー間の親和性をきれいにすることで、クロスコアバウンスを防ぎ、レイテンシを大幅に削減します。.

作業量に応じて最適なキューの深さを選択

まずは控えめに QD そして、レイテンシP99、CPUアイドル、NVMeキューの利用率を監視します。SSDにほとんど負荷がかかっていないにもかかわらずレイテンシが低下しない場合は、キューの深さを徐々に増やしていきます。レイテンシが大幅に増加する場合は、値を減らすか、複数のIOスレッドに負荷を分散させます。多くの並列読み出しを行うアプリケーションは、フラッシュを必要とする書き込みの多いワークロードよりも、高いQDの恩恵を受けることが多い。このステップ・バイ・ステップのアプローチは、誤った設定を防ぎ パラレリズム より的を絞っている。.

インパクトのあるオペレーティングシステムとドライバーのチューニング

アプリを微調整する前に、スタックが効率的に動作していることを確認する。Linuxでは、NVMe用のI/Oスケジューラなし (blk-mq)をデフォルトで使用します。追加のソートは時間がかかるだけです。IRQアフィニティによってコア間で割り込みを分散させ、ホットスレッドのクロスコアマイグレーションを無効化し、NVMeドライバの合体設定を制御している。I/Oポーリングは、レイテンシのピークを滑らかにすることができますが、CPU負荷を増加させます。私は、ランダムなワークロードではreadaheadを低く保ち、シーケンシャルなジョブでは高く保ちます。書き込みの多いシステムでは ダーティーバックグラウンド- そして dirty_*-カーネルが時間内に書き込み、輻輳波を発生させないようにするためである。.

ファイルシステムとデータベースへの影響

仝 ファイルシステム も決定する：XFSとext4はランダムIOで再現可能なレイテンシを提供する。以下のようなオプションがあります。 ノータイム 或いは 怠け者 メタデータIOを減らす、, discard=async 高価なインラインTRIMを防ぐ。私は軽々しくバリアを上書きしない。データのセキュリティが第一だ。レギュラー fstrim はTLC/QLC SSDを正常に保ちます。データベースでは、私はIO特性に取り組んでいます。 io_capacity(_max) バックグラウンドレターを控えめに, flush_log_at_trx_commit とロググループの設定で同期頻度を制御します。PostgreSQLの影響 同期コミット, チェックポイントのチューニングとWALパラメータは、フラッシュ負荷に影響する。目的は、短くて一貫性のあるフラッシュパスと、ディスクアクセスが「バースト的」にならないQDを達成することである。.

実践：LinuxとWindowsでの測定とチューニング

Linuxでfio、iostat、blktraceを使っている。 レイテンシー, QDの分布とIOサイズ。Windowsでは、DiskSpdとPerfMonが、キューの深さ、IOPS、待ち時間に関する同等の洞察を提供します。ブロックサイズ、読み書き比率、スレッド数は実際のログに基づいています。その後、ワーカーの数、非同期IOパラメーター、DB接続プールなど、アプリの設定を調整する。それから初めてドライバーとカーネルのオプションに進みます。 最適化 がアプリケーションの近くに残っている。.

ホスティングにおけるNVMeとSATAの比較

時点では SATA は早い段階で個々のコマンド・キューを制限するため、並列処理では待ち時間が発生します。NVMeは、より多くのスレッドでこれに対抗するため、ウェブやAPIのロードがより高速に処理されます。SATAから乗り換えた人は、特にTTFBとデータベースのレスポンスが向上していることに気づくでしょう。コンパクトなアップデートの概要については、こちらをご覧ください： NVMe 対 SATA. .結局のところ、重要なのは、多くの短いIOからワークロードが生きるかどうかである。 平行移動 を利用する。

仮想化とコンテナ：マルチキューとQoS

VMとコンテナでは、ホストとゲストのキューを区別する。Virtio-blk/scsiとNVMeエミュレーションをサポートする。 マルチ・キュー - 割り込みがローカルに残るように、vCPUごとに少なくとも1つのキューを設定している。ホスト上では、cgroups (io.weight, io.max)であるため、人為的にグローバル QD を低下させることなく公平性を確保できる。ループバック上のコンテナ・イメージや設定不十分なオーバレイ・ドライバは測定値を歪める。ブロック・レベルの永続ボリュームはより現実的な結果を提供する。クラウド環境では、ストレージQoSの制限をチェックすることで 観察済み QDは、IOPS/スループットの譲歩によって失敗することはない。.

アーキテクチャ：CPU、RAM、ネットワークを一緒に考える

手っ取り早く ストレージ CPUが常にオーバーロードしていたり、キャッシュ用のRAMが不足していたり、ネットワークがブロックされていたりすると、ほとんど意味がない。そのため、私はメモリを調整する前に、まずアプリのプロファイリング、クエリープラン、キャッシュヒットをチェックする。高いIRQ負荷や非効率的なスレッドプールは、IOパイプラインを人為的に遅くする可能性がある。小さすぎるページキャッシュも、システムがSSDに頻繁にアクセスしなければならないため、有害だ。これらのチェーンがスムーズに実行されていれば NVMe 自分たちの力を十分に発揮する。.

ファブリック上のNVMeとスケーリング

プロジェクトが1つのサーバーを越えて大きくなった場合、私は次のようなものに頼る。 ファブリック, を使用して、ネットワーク上で NVMe パフォーマンスを提供します。このステップによって、複数のホストに低レイテンシーの接続性がもたらされますが、クリーンなネットワークとパスの設計が必要になります。私は、一貫性のあるパス、QoS、イニシエータ側とターゲット側のキュー利用率のモニタリングに注意を払っています。もっと詳しくお知りになりたい方は、こちらをご覧ください：ファブリック上のNVMe. .これにより負荷が分散され レイテンシー コントロール下にある。

RAID、LVM、暗号化

について ブロックスタック SSD上部の応答時間が特徴的です。チャンクサイズとファイルシステムのストライドが一致する場合、ソフトウェアRAID0/10はランダムIOをうまくスケールします。私は 基礎となる装置 - 1台のSSDで並列化しすぎるのは、複数のドライブにまたがる適度なストライピングよりもメリットが少ない。LVMとデバイスマッパーレイヤーは独自のキューを追加する。私はレイヤーの数を抑えています。 dmクリプト/LUKS 暗号化にはCPU時間がかかり、暗号パイプラインのために十分なコアが空いていない場合、QDを効果的にスロットルすることができます。AES-NI/ARMv8-CEとマルチコアの並列化により、損失は大幅に削減できますが、IOPSを比較するだけでなく、起動前と起動後のP99のレイテンシをチェックするようにしています。.

アプリケーションのシナリオWordPress、データベース、VM

時点では ワードプレス プラグインは多くの小さなランダムリードを生成するため、レイテンシーが低いとローディング時間が短縮される。データベースは、ライトアヘッド・ログ、フラッシュ動作、同期に敏感に反応する。ここでは、中程度のQDを選択し、クリーンなフラッシュパスを確保する。仮想マシンは非常に異なるワークロードを束ねるため、私はホスト・モニタリングを使って各VMのIO特性を分析している。その後、複数のキューにスレッドを分散させ、制限を使ってノイズの多い隣接キューを分離します。これによりレスポンスタイムを維持している。不変, ピーク負荷時でも。.

ホスティングモデルと予測可能なパフォーマンス

シェア環境 リソース, そのため、キューの有効利用率が変動する。VPSや専用マシンでは、IOの優先順位、キューの深さ、スレッド数をより正確にコントロールします。データ量の多いプロジェクトでは、プロバイダーの測定値を見てみる価値がある。負荷が混在しているときの一定の待ち時間は、公称IOPSよりも重要だ。適切な推薦図書は、さらなる視点を提供してくれる：サーバーIOPS. .プラットフォームがきれいに計画されていればいるほど、より良い。 最適化 店で。.

トラブルシューティング：典型的なエラーパターンと簡単なチェック方法

P99のレイテンシーが負荷がかかった状態で手に負えなくなった場合、私はまずQDが単に 待ち時間 実質的なスループットをもたらす代わりに拡張。表示は高い 待ち時間 デバイスの使用率が低く、カーネルログにタイムアウトやリセットが頻繁に記録され、IOPSが大きく変動している。私は温度とSMARTログをチェックします：サーマル・スロットリング、欠陥のあるケーブル/バックプレーン、またはAPSTによる古いファームウェアの処理は、異常値を生成する可能性があります。OSレベルでは、iostat/blktraceがリード/ライト間の不公平な配分を明らかにする。CPUがユーザースペースで立ち往生している場合、問題はしばしば以下のようなものである。曩にストレージ：ロックの保持、小さすぎるスレッドプール、アプリ内のシリアライズなどが、QDを効果的に減少させる。これらの点がクリーンになって初めて、キューの深さを微調整する価値がある。.

決定グリッドと簡単な要約

をまず明確にする。 ワークロード小さなランダムIOや大きなシーケンシャル転送が多い。次に、P95/P99のレイテンシー、QDの分布、CPUスレッドの使用率をチェックして、ボトルネックを特定する。次のステップでは、ドライバー、DB、VMレイヤーのキューの深さを微調整する前に、アプリのスレッド、コネクションプール、非同期IOを調整します。現実的な負荷の下で測定を繰り返し、利得を確認し、トレードオフを明らかにする。こうして顕著な効果が得られた。 パフォーマンス-主要な数字に盲目的に注目することなく、成長を目指す。.