I/Oキュー深度は、複数のクライアントが同時にストレージにアクセスする場合にホームNASのスループットを向上させることがありますが、ストレージスタックがそれらの未処理リクエストを並列に処理できる場合に限ります。有効な並列性を超える需要が発生すると、NASが1秒あたりのデータ転送量を増やし続けても、追加のリクエストはより長く待機することになります。
これが、マルチデバイストランスファーテストで合計レートが高く報告される一方で、写真ブラウザ、データベース、ファイルエクスプローラーが応答性に欠ける理由です。キュー深度はそれ自体が速度設定ではなく、未完了の作業量の指標であり、その効果はワークロード、ドライブタイプ、アレイ、キャッシュ、プロトコルパスによって異なります。
I/Oキュー深度は実際に何を測定しているのか?
キュー深度は、特定のレイヤーで未処理のI/O操作がいくつあるかを表します。テストツールでは、1つのジョブによって送信され、まだ完了していないリクエストを意味することがあります。fioのI/O深度の定義では、ファイルに対して飛行中のI/Oユニット数と呼ばれています。完了した操作はもはやその深さに含まれません。
ホームNASには複数のキューがあります。アプリケーションはファイル共有リクエストを待機し、NASはソフトウェアでブロックリクエストをステージングし、デバイスコントローラは独自のコマンドキューを維持します。したがって、1つのレイヤーで表示される深さは、パスの他の場所で待機しているすべてのリクエストを示すわけではありません。
同時実行性は自然に深さを生み出します。4人のクライアントがそれぞれ1つのブロッキングリクエストを発行すると、どのクライアントも意図的に深いキューを選択しなくても、複数の未処理操作が発生します。バックグラウンドのインデックス作成、スナップショット、ダウンロード、メディアサービスがさらに作業を追加するため、デバイス側のキューは前景のアプリケーションが示すよりも深くなることがあります。
なぜより多くの未処理I/Oがスループットを向上させるのか?
デバイスは1つのリクエストしか受け取らず、完了ごとに次の送信を待たなければ、内部の並列性を活用できません。複数の独立したリクエストを保持することで、スケジューラやコントローラは異なるチャネル、ダイ、ドライブ、またはアレイメンバーの作業を選択でき、他の操作が進行中でも処理が可能になります。
Linuxのマルチキューブロックレイヤーは、現代のストレージがその並列性を活用できるように、リクエストを同時にキューイングおよび送信するよう設計されています。また、ソフトウェアのステージングキューとハードウェアのディスパッチキューを分離しているため、キューに入った作業がドライブに到達する前に再編成されたり遅延したりする理由が説明されます。
この利点はワークロードに依存します。複数のSSDロケーションにまたがる独立した読み取りは効果的に重複する可能性がありますが、単一の同期操作では同じ機会を作れません。RAIDアレイでは、並列リクエストが異なるメンバーに到達することもありますが、パリティ作業、ロック、または飽和したネットワークがドライブの有効な深さに達する前の次の制限になることがあります。
並列処理はいつ待機に変わるのか?
キュー深度はアクティブなリソースが忙しい間は役立ちます。そのポイントを超えると、新しいリクエストはより多くの並列作業を解放せず、バックログに加わります。スループットは天井近くで平坦化し、完了時間は各リクエストがサービス前により長く待機するため増加します。
| キュー状態 | ストレージの挙動 | 総合スループット | リクエスト遅延 | 実用的な意味 |
|---|---|---|---|---|
| 過小充填 | 一部のデバイスリソースはアイドル状態かもしれない | 可能なピークを下回る | 通常は低い | より多くの同時実行が役立つ場合がある |
| 生産的な深さ | 独立した作業が並行して実行される | 効率的に増加中 | 中程度 | 最適なバランスはワークロードによる |
| 飽和状態 | コアリソースは忙しいまま | ほぼ安定期 | 増加中 | 新しい作業はほとんど待機する |
| 過負荷 | バックログがクライアント間で競合する | 平坦または不安定 | 高く変動が大きい | インタラクティブなタスクは遅く感じる |
この表は状態モデルであり、普遍的なキュー深度チャートではありません。遷移点はブロックサイズ、読み書きの比率、キャッシュ、ドライブのファームウェア、RAID構成、およびリクエストが実際に独立して実行可能かどうかによって変動します。
重要な指標は応答の形状です。有効な深さは限定的な遅延コストで意味のあるスループット向上をもたらしますが、過負荷はほとんど追加の作業を完了しないまま大幅な待機時間を増やします。ワークロードの文脈なしに固定されたキュー深度の推奨は、その境界を特定できません。
同時アクセスはどのようにしてNASのバックログを作るのか?
同時ユーザーはほとんど同一のストレージ作業を生成しません。あるコンピューターは大きなファイルをストリーミングし、別のコンピューターは何千もの写真を閲覧し、バックアップジョブは新しいブロックとメタデータを書き込みます。NASはこれらのリクエストをインターリーブするため、各クライアントが予測可能に動作していても、シーケンシャルなワークロードがデバイス上で断片化することがあります。
ファイル共有プロトコル、ファイルシステム、およびアプリケーションも順序を課します。リクエストは、次のステップに進む前にメタデータの検索、権限チェック、ロック、または耐久性のある書き込みに依存する場合があります。ブロックデバイスの深さを増やしても、デバイスの上位に存在する依存関係は取り除けませんが、無関係なクライアントはその停滞したチェーンの周りのキューを埋めることができます。
この相互作用が、総合速度とユーザー体験が乖離する理由を説明します。大量転送はデバイスを生産的に保つ一方で、小さなインタラクティブリクエストは大きなまたは多数の操作の後ろで待つことがあります。公平性ポリシーは飢餓状態を減らせますが、すでに飽和したリソースが無制限の作業を即座に完了させることはできません。したがって、混合ワークロードは合計バイトレートだけでなく、各クラスのサービス品質で評価すべきです。
なぜHDD、SATA SSD、NVMeは異なる反応を示すのか?
回転ディスクはリクエストが離れた場所を対象とすると機械的なコストがかかります。深いランダムキューはスケジューラーにより多くの選択肢を与えますが、同時により多くのシークや長い待ち時間を意味することもあります。隣接するリクエストはマージしやすいため、ドライブが忙しい場合でもシーケンシャルな局所性は価値があります。
SSDは機械的なシークを排除し、並列フラッシュ操作を処理できますが、コントローラー、NANDチャネル、ファームウェア、バックグラウンドメンテナンスには依然として制限があります。NVMeは複数のコマンドキューと大容量のコマンド処理能力を提供しますが、NVMeキュー仕様は、すべての追加コマンドが性能向上を約束するのではなく、未処理コマンドとコントローラーのコマンド制限について説明しています。
ドライブのクラスだけで判断してはいけません。SATA SSDは小規模なインタラクティブなワークロードのニーズをすでに超えているかもしれませんし、HDDアレイは強力なシーケンシャルスループットを提供するかもしれません。実用的なHDDとSSDの選択は、ランダムI/Oの需要、容量、耐久性、レイテンシに合わせるべきであり、インターフェースの表面的な速度だけで決めるべきではありません。
同時実行時にホームNASは何を測定すべきか?
スループットとレイテンシを一緒に測定します。レイテンシについては、平均値だけでなく中央値、95パーセンタイル、99パーセンタイルなどの分布を報告してください。平均値は許容範囲内でも、少数の重要なリクエストが遅くなり、ブラウジング、VMの動作、データベース作業を妨げることがあります。短時間のバーストは長い報告間隔内で消えることがあるため、結果を時間経過で追跡することも重要です。
また、進行中のリクエスト、読み取りおよび書き込みの処理時間、加重I/O時間も観察します。LinuxのブロックI/O統計ドキュメントでは、アクティブなリクエスト、サービス時間、マージ、および完了時間と蓄積されたバックログの両方を反映する加重指標のカウンターが特定されています。
単一クライアントでベースラインを実行し、その後、実際の同時クライアント数と家庭で想定されるファイルサイズ、読み書き比率、キャッシュ状態で繰り返します。ネットワークがすでに飽和している場合、ストレージの調整は結果を変えないかもしれません。10GbE NASボトルネックチェックリストは診断の補助になりますが、キューイングメカニズムの証拠とはなりません。
よくある質問
キュー深度を増やせば必ずホームNASは高速になりますか?
いいえ。ストレージパスに未使用の並列処理能力があり、ワークロードに独立した操作が含まれている場合にのみ効果があります。スループットが頭打ちに近づいた後は、キュー深度を増やすと待ち時間が増え、テールレイテンシが悪化することが多いです。
ホームNASのベンチマークでどのキュー深度を使うべきですか?
キュー深度は複数の値を試し、1から始めてスループットが実質的に改善しなくなるかレイテンシが許容できなくなるまで増やします。有効な範囲はデバイス、アレイ、ワークロード、クライアント数に依存するため、固定値で全てのNASを代表することはできません。
なぜ一人のユーザーは遅延を感じるのに、NAS全体のスループットは良好に見えるのですか?
総スループットは完了した全データ量をカウントし、各リクエストの待ち時間は考慮しません。大量転送が完了を支配している間にインタラクティブなリクエストがキューに滞留すると、総合的なレートは高くてもインターフェースが遅く感じられます。
SMBやNFSは観測されるキュー深度を変えますか?
はい。プロトコルの同時実行性、キャッシュ、同期的な意味論、クライアントの動作が、どれだけ多くの操作がNASに到達し、いつストレージ処理の対象になるかに影響します。SMBとNFSの比較はプロトコル選択の参考になりますが、デバイスのキュー深度はあくまで一層に過ぎません。
高速なネットワークはキューイングレイテンシをより明確にしますか?
はい。ネットワークがストレージの処理速度を上回って作業を送信できるようになると、バックログはストレージ層に移動します。アップグレードによりピークスループットが向上する一方で、遅いリンクが以前は隠していたドライブ、アレイ、またはファイルシステムの制限が露呈することがあります。
最終的な結論
I/Oキューの深さは、未処理のリクエストが有用な並列作業を解放している場合にのみ、ホームNASの性能を向上させます。結果は同時スループットとレイテンシのパーセンタイルを合わせて判断してください。スループットが頭打ちになりリクエスト遅延が増加する場合、キューは並列処理の源からバックログへと変わっています。
テック&AIハブ
もっと読む

Home AssistantはLAN接続とリモート接続でなぜパフォーマンスが異なるのですか?
LAN接続とリモート接続のHome Assistantセッションではネットワーク経路が異なります。リモート接続では、DNS、暗号化、WAN、プロキシやVPN、再接続処理による遅延が加わります。

Home AssistantはCGNATや二重NAT環境でも安定して動作しますか?
CGNATと二重NATは通常、ローカルでのHome Assistantの制御には影響しません。主に、リモートクライアントがホームネットワークへのインバウンド経路を確立する方法が変わります。

インターネット障害中、ネットワーク遅延はHome Assistantにどのような影響を与えるか?
インターネット接続の喪失とネットワーク遅延は異なる障害です。DNS、クラウド連携、ゲートウェイ、リモートクライアントが待機している間も、ローカルデバイスへの経路は高速なまま維持されることがあります。

