SSDリードキャッシュは、繰り返しのNAS読み取りにおいて直接ディスクアクセスよりも実際に有利ですか？

エヴァ・ウォン

IceWhale author

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

Does SSD Read Cache Offer a Real Advantage Over Direct Disk Access for Repeated NAS Reads? - Zima Store Online

はい、ただし再利用される作業セットが利用可能なRAMより大きく、SSDキャッシュに収まるほど小さく、基盤となるディスクプールが遅い場合に限ります。すでにNASページキャッシュからの繰り返し読み取りはほとんど利点がなく、一度きりのスキャンや大きな連続転送はディスクから効率的に提供されることがあります。利点はメモリがストレージを隠さなくなった後にのみ真実です。

真の利点はRAMとディスクプールの間で始まる

繰り返しのアクセスはSSDキャッシュが役立っている証明にはなりません。Linuxや多くのNASプラットフォームは最近読み取ったファイルデータをRAMに保持するため、2回目の読み取りはSSDキャッシュやHDDプールに触れずに高速になることがあります。Baeldungの読み取り後にメモリに保持されるファイルシステムデータの説明は、ウォームテストが誤ってRAMを測定してしまう理由を示しています。

有用なキャッシュウィンドウは、アクティブなデータセットがメモリに快適に収まらなくなったが、設定されたSSDキャッシュにはまだ収まる場合に現れます。その範囲内では、繰り返しのランダム読み取りが機械的なシークや長いキュー時間を回避できます。作業セットがRAMとSSDキャッシュの両方を超える場合、有用なブロックは繰り返し追い出され、ヒット率が重要なレベルに達しないかもしれません。

この記事が保持すべき唯一の変数は、RAMがもはや解決策でなくなった後に同じブロックが実質的に速く提供されるかどうかです。これは一般的なSSD対HDDの比較ではなく、すべてのキャッシュされたNASが応答性を持つと主張するものではありません。

リードキャッシュが顕著な効果を生む場合

リードキャッシュは、多くの小さなブロックを再訪するワークロードに適しています：サムネイルライブラリ、パッケージリポジトリ、頻繁に開くプロジェクトフォルダ、仮想マシンのテンプレート、インデックス、RAMよりもホットな読み取りセットが大きいデータベースなどです。利点はしばしばレイテンシの低減やHDDのシーク回数の減少であり、大きなファイル転送数の劇的な増加ではありません。

XDAの頻繁に再利用されるNASデータがSSDキャッシュから提供されるという説明は、このパターンを反映しています。改善は、同じファイルやブロックが十分にホットになりキャッシュに留まることに依存します。

ディスクの活動が同じ話を示すと、選択は簡単になります。繰り返しのディレクトリスキャンやアプリケーションの起動がHDDプールで持続的なランダム読み取りを引き起こし、ネットワークがほとんどアイドル状態の場合、SSD読み取りキャッシュは妥当なターゲットとなります。ディスクが静かな場合は、別のレイヤーがすでにリクエストに応えています。

直接ディスクアクセスがすでに十分な場合

大きな連続読み取りは、HDDアレイのストリーミングスループットをうまく活用することが多いです。メディアファイルの一度の再生、完全バックアップの検証、または一度きりのデータセットスキャンは、キャッシュを通過しても再利用されずに追い出されることがあります。そのトラフィックをキャッシュすることは、次の判断を変えずに容量を消費する可能性があります。

プールに十分なスピンドルが既にある場合、クライアントのリンクがアレイより遅い場合、またはワークロードが連続的なプリフェッチに支配されている場合、直接ディスクアクセスが勝つこともあります。その場合、ネットワークやクライアントが見える上限を設定します。ZimaSpaceのSSDレイテンシを露呈するNASワークロードの比較は、ワークロードが実際に高速メディアに到達した後に高速メディアが最も重要になる理由を説明しています。

頻繁に使用されるデータセットがRAMに収まる場合、SSDキャッシュは不要です。Thomas-KrennのLinuxページキャッシュからの2回目のファイル読み込みの例は、NASテストが制御すべきまさにその混乱要因です。

Featured

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

ZimaCube2

RAM、SSDキャッシュ、ディスクを区別するテスト

ベンチマークを1つではなく3つの状態で行います。まず、関連するキャッシュが安全なテスト方法でクリアされた後、または制御された再起動後にコールドテストを実行します。次に、SSDキャッシュがまだウォームアップ中の間にワークロードを繰り返します。最後に、作業セットが十分に再訪問されて安定したヒット率が得られた後に再度実行します。

観察された結果	考えられる解釈	決定
SSDキャッシュがウォームアップする前の2回目の実行は高速です	RAM/ページキャッシュがデータを提供している可能性がある	キャッシュを購入する前にRAMを追加するかテストを変更する
SSDヒット率が上がるにつれてパフォーマンスが向上する	繰り返されるブロックがSSDの作業セットに収まっている	読み取りキャッシュは実際のボトルネックに対処している
ネットワークが毎回飽和している	ストレージはすでにクライアントリンクにデータを供給している	キャッシュはクライアントが感じる速度を変えないかもしれない
ディスクシークが高くヒット率が低いまま	作業セットが大きすぎるか再利用性が低い	代わりに専用SSD層を検討してください

経過時間、キャッシュヒット率、ディスクIOPS、ディスク遅延、ネットワーク利用率、利用可能なメモリを一緒に追跡してください。3回目の実行が速くなるだけでは不十分です。キャッシュは単にRAMに残るデータが増えるのと同時に起こるのではなく、同じリクエストに対してバックエンドのディスク作業を減らすべきです。

利点を打ち消す要因は？

キャッシュのウォームアップは短命なジョブの利点を消してしまうことがあります。NASが頻繁に再起動したり、作業セットが毎日変わる場合、有用なブロックはタスクがほぼ完了した後に昇格されることがあります。キャッシュは再利用が十分に頻繁に起こる場合に価値があります。

容量の選択も両方向で失敗することがあります。小さすぎるキャッシュはホットデータをすぐに入れ替え、大きすぎるキャッシュはアクティブなデータセットを専用SSDボリュームに置くのとほぼ同じコストになることがあります。XDAのSSDキャッシュは多くの不適合なワークロードにとって誤ったアップグレードであるという警告は、決定を実際のアクセスパターンに戻すために有用です。

CPU、ファイルシステムのメタデータ、SMB設定、暗号化、またはアプリケーションの動作が、SSDにヒットした後もボトルネックのままであることがあります。その時点でストレージ層はすでに役割を果たしています。予想より小さい効果をキャッシュの不良の証拠と解釈せず、診断を続けてください。

実際に違いを感じられるのは誰か？

読み取りキャッシュが適している場合

NASは繰り返しRAMに収まらない作業セットを提供し、HDDプールは高いランダム読み取り遅延を示し、キャッシュヒット率は安定します。複数のユーザーが共通のファイルを再訪問すると、同じキャッシュブロックが複数のクライアントにサービスされるため、その効果が観察しやすくなります。

直接ディスクアクセスで十分な場合

ワークロードが主に連続的、一度きり、またはすでにクライアントネットワークによって制限されている場合。また、頻繁に再利用されるデータがRAMに収まるか、アレイが目立ったキューイングなしに要求に対応できるIOPSを持つ場合も十分です。

専用SSDボリュームを使用する場合

アクティブなデータセットが常に高速である必要があり、頻繁に書き込まれ、キャッシュ昇格を待てない場合は、実際のSSD層を選択してください。仮想ディスク、データベース、コンテナ、アクティブなプロジェクトデータは、適切なブロックがホットなままであることを期待するよりも、明示的な配置からより予測可能に恩恵を受けることが多いです。

購入前のリードキャッシュチェック

利用可能なRAMを測定し、繰り返しアクセスされる作業セットを推定してください。
遅い操作中のバックエンドディスクのレイテンシを記録してください。
クライアントのリンクがすでに飽和していないことを確認してください。
コールド、ウォーミング、安定したキャッシュの動作を比較してください。
1回の転送結果だけで判断せず、キャッシュヒット率を監視してください。
専用SSDボリュームがより明確な配置ルールを提供するかどうかを判断してください。
パフォーマンスキャッシュとは独立したバックアップを保持してください。

よくある質問

リードオンリーSSDキャッシュはユニークなデータを危険にさらしますか？

リードキャッシュは通常、プライマリプールに残るデータのコピーを保存するため、その障害が唯一のコピーを失うことにはなりません。実装と回復の挙動は異なるため、プラットフォームの削除および障害時の手順を展開前に理解する必要があります。

リードキャッシュはPlexやJellyfinの速度を向上させますか？

繰り返されるメタデータ、サムネイル、データベースの読み取りを改善する場合があります。HDDプールがすでにビットレートを供給している一度きりの連続ストリーミングには通常ほとんど効果がありません。トランスコーディングの性能は読み取りキャッシュの結果ではなく計算の問題です。

キャッシュのウォームアップにはどのくらい時間がかかりますか？

普遍的な期間はありません。プロモーションポリシー、ワークロードの繰り返し、キャッシュサイズ、作業セットサイズ、および有用なブロックがどのくらいの頻度で再訪されるかによって異なります。ウォームアップは安定したヒット率とバックエンドディスクの活動減少で判断してください。

最終判断

SSDのリードキャッシュは、繰り返されるNASの読み取りがRAM容量とHDD性能のギャップに収まる場合に真の利点を提供します。RAMがすでにデータを提供している場合、アクセスが連続的または一度きりの場合、またはネットワークが明らかな制限である場合はほとんど効果がありません。SSDの効果を割り当てる前に、完全なキャッシュ階層をテストしてください。