NVMeのキュー深度はベクトルインデックスの取り込み速度にどのような影響を与えるか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does NVMe Queue Depth Affect Vector Index Ingest Speed? - Zima Store Online

NVMeのキュー深度を高めると、ストレージ処理を並列化できるため、ベクトル取り込み速度が向上する場合があります。ただし、別の工程やデバイスが飽和すると、それ以上の効果は止まります。

大規模なホームアーカイブを埋め込み処理すると、1つの連続ファイルではなく、ベクトル、メタデータ、グラフエッジ、転置インデックスのエントリ、一時ラン、コミットレコードが生成されます。インデクサーが1回の書き込みだけを送信して完了を待つ場合、高速なNVMeデバイスはコマンド間でアイドル状態になります。未完了リクエストを増やすと内部並列性を活用できますが、深度が過剰になるとキューが長くなり、同じドライブ上で実行される対話型検索に悪影響を与える可能性があります。

キュー深度が測定するのはファイル数ではなく未完了コマンド

NVMeは、送信キューと完了キューのペアを使用します。キュー深度とは、未完了のまま保持できるコマンド数です。そのため、ファイルシステムとブロック層がインデックス操作をデバイスリクエストに変換した後のストレージ並列性を示します。

NVMe仕様では、ホストソフトウェアが各コマンドの完了を待たずに複数のコマンドを送信できる送信キューと完了キューが定義されています。この設計により、複数のコントローラーチャネル、フラッシュダイ、内部処理を同時に動作させられます。この違いは、後の家庭環境でのテストでも確認できます。

多数のファイルを開いても、有効な深度が得られるとは限りません。同期的なアプリケーション処理、小さなトランザクション、ロック、または各レコードの後に実行するfsyncによって、リクエストがコントローラーに到達する前に処理経路が直列化されることがあります。自動化を進める前に、中間結果を確認できる状態にしておく必要があります。

並列インデックス処理がキュー深度をスループットに変える

ベクトル取り込みパイプラインでは、ドキュメントレコードをバッチ処理し、埋め込みを並列で生成し、グラフ構造や転置インデックス構造を構築し、非同期書き込みを実行できます。十分な独立処理があれば、各処理のレイテンシーを個別に露呈させるのではなく、プログラム、消去、メタデータ、転送の各処理をストレージ上で重ね合わせられます。

SPDKのNVMeパフォーマンスガイダンスでは、並列NVMeキューとワーカープレースメントを、デバイスとワークロードに合わせることが重視されています。並行性を高めても、アプリケーションが独立したI/Oを供給し、CPUが完了処理を効率的にポーリングまたは処理できる場合にのみ効果があります。

インデックス構造も重要です。追記中心のセグメント作成は大きなバッチで拡張できますが、頻繁なグラフ変更、WALコミット、小さなメタデータ更新は、CPUや同期処理がボトルネックのままになる場合があります。ストレージ処理を十分な速度で生成できない工程を、キュー深度で高速化することはできません。

飽和すると、深度の増加は待ち時間に変わる

スループットは、フラッシュ帯域幅、コントローラー処理、PCIe、CPU、またはインデクサー自身の直列化が容量上限に達するまで上昇します。その限界点を超えると、追加のコマンドは完了まで長く待たされるだけで、1秒あたりの処理バイト数は増えません。その結果、p99レイテンシーと、処理中バッファーに使用されるメモリが増加します。

USENIXによる最新NVMeストレージの研究では、NVMeのホストオーバーヘッドは、単純な公称帯域幅だけでなく、デバイスアーキテクチャとホストソフトウェアのオーバーヘッドにも左右されることが示されています。短いリクエストを並列実行すると、ボトルネックがCPUやI/O送信経路へ移る可能性があります。

問題が表面化するのは、取り込み処理が検索、モデルの読み込み、データベース、スワップと同じデバイスを共有する混在ワークロードです。一括取り込みを最大化する深度では、総合スループットが非常に高く見えても、対話型の読み取りが実用にならない場合があります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

検索レイテンシーを隠さずにスループットの限界点を見つける

埋め込みワーカー数、バッチサイズ、インデックスパラメーター、ファイルシステム、コミットポリシーを一定に保ち、同じコーパスをキュー深度1、2、4、8、16、32、64で実行します。この境界は、現実的な運用条件の下で個別に測定する必要があります。

小さなファイルのインデックス作成と比較して、少数の大きなファイルの場合の挙動も確認します。1秒あたりのベクトル数、書き込みバイト数、デバイス使用率、平均およびp99書き込みレイテンシー、CPU時間、fsync頻度、メモリ、同時検索のp99を記録します。複数のソースが限られたコンテキストを奪い合うと、実際の影響が現れます。

対話型レイテンシーの要件を満たしながら、持続可能な取り込みスループットが最大に近づく最低の深度を選択します。深度1からスループットが横ばいの場合は、NVMeを原因と決めつける前に、埋め込み処理、ロック、コンパクション、コミット頻度をプロファイリングします。この依存関係は、最終インターフェースでも明示したままにする必要があります。