JellyfinはSSDストレージとHDDストレージでなぜ使用感が異なるのか？

レイテンシーに敏感なアプリデータが大半を占める場合、JellyfinはSSD上のほうが高速に感じられます。一方、大容量メディアのシーケンシャル読み取りには、HDDでも十分対応できます。

インターフェース、検索、アートワーク、データベース、スキャン更新、トランスコードキャッシュは、ビットレートに合わせて前方へ読み取られる映画とは異なる形でストレージにアクセスします。SSDが主に変えるのはアクセスレイテンシーとランダムI/Oの挙動であり、CPUがボトルネックのトランスコードや、飽和したネットワークを自動的に改善するわけではありません。重要なのは、1台のドライブベンチマークだけでサーバー全体の体感を判断せず、アクティブなJellyfinの状態と大容量メディアを分離する設計です。

アプリケーションの状態がレイテンシーに敏感な体感を生む

Jellyfinのデータベース、メタデータ、アートワーク、ログ、設定では、多数の小規模な操作やディレクトリ検索が発生します。ライブラリを開く、ポスターを読み込む、検索する、再生状態を更新するといったユーザー向けの操作は、これらの処理が完了するまで待つことがあるため、デバイスのアクセスレイテンシーがインターフェースの応答性として表れます。SSDは、機械式ドライブでこの種のワークロードを特に重くするシークのペナルティを軽減します。

Jellyfinのハードウェアガイドでは、Jellyfin自身のファイルはランダムアクセスが多いためSSDを推奨し、メディアストレージは主にシーケンシャル速度で評価しています。このランダムアクセス用ストレージの分離により、すべての映画を同じHDDプールに残したままでも、アプリケーションの状態を移動すればブラウジングが改善する理由を直接説明できます。

境界となるのは、アクティブなアクセス経路です。データベースがすでにメモリ上で温まっていて、リクエストがキャッシュされていないアートワークを必要としない場合、その操作にデバイスがほとんど影響しないことがあります。SSDの効果を誇張しないよう、HDDのコールド実行とSSDのウォーム実行を比較するのではなく、コールド時とウォーム時の挙動を分けて測定してください。

メディアファイルでは通常、シークレイテンシーよりスループットが重要

Direct Playの映画は通常、大きなデータを前方へ連続して読み取るため、データベースのようなランダムアクセスよりもHDDの強みに適しています。同時再生ストリームの合計ビットレートを十分な余裕をもってデバイスが維持できる限り、メディア層をSSDに置き換えても、再生体験に目立った改善が生じないことがあります。大容量メディアでは、容量、動作音、消費電力、復旧設計のほうが重要になる場合があります。

Jellyfinのストレージドキュメントでは、メディアファイルをシーケンシャルスループットのワークロードとして説明し、サーバーデータを低速な機械式ストレージに置かないよう別途注意しています。このメディアとサーバーデータに関する指針は、階層型設計を支持しています。ランダムなアプリ操作で低レイテンシーが必要な場所には高速ストレージを使い、シーケンシャル読み取りがすでに必要なビットレートを満たしている場所では、経済的な大容量ストレージを維持します。

境界となるのは、同時シークと特殊なメディアアクセスです。複数のストリームがそれぞれ独立してシークしたり、チャプタースキャン、サムネイル生成、同じディスクを読む別のサービスが発生したりすると、ほぼシーケンシャルだったパターンが崩れます。個々の動画のビットレートが控えめでも、ヘッドが無関係なリクエスト間を移動しなければならなくなると、HDDのレイテンシーが表面化します。

Linuxのページキャッシュはウォームアップ後に物理ドライブを隠すことがある

SSDでもHDDでも、有用なページがファイルシステムキャッシュに入ると、読み取りがメモリヒットになることがあります。そのため、コールド性能に大きな差があっても、データベースクエリやアートワークの読み込みを繰り返すと、似たような体感になる場合があります。同じオブジェクトに繰り返しアクセスする短時間のベンチマークでは、ストレージよりもRAMの再利用を測定してしまう可能性があります。特に、アクティブなメタデータのワーキングセットを収容できるだけのメモリがサーバーにある場合は顕著です。

このLinuxのページキャッシュモデルが示すように、通常のファイル読み取りではメモリページが作成され、その後のリクエストは、ページが追い出されるまでディスクI/Oなしで処理されることがあります。Jellyfinでは、初回利用時と繰り返し利用時のレイテンシーを比較し、物理I/Oも記録してから、応答性の違いをすべてストレージデバイスのせいにするべきか判断するのが簡単な方法です。

境界となるのは、ワーキングセットのサイズとメモリプレッシャーです。大規模なカタログ、複数のコンテナ、厳しいメモリ制限があると、有用なページが追い出されて再びデバイスの性能が表面化します。アクティブなメタデータセットがキャッシュ容量を繰り返し超える場合、SSDの効果はより持続的になります。一方、重要なデータのほぼすべてがすでにメモリ上にあれば、HDDでも驚くほど高速に見えることがあります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

読み取りと書き込みの混在はHDDの弱点を増幅する

ライブラリスキャン、ダウンロード、バックアップ、データベースのコミット、トランスコードセグメントの書き込みがパターンを中断するまでは、再生はシーケンシャルに進むことがあります。機械式ドライブでは、ワークロードが無関係な場所の間を移動すると物理的なシークコストが発生しますが、SSDはランダムアクセスをはるかに低いレイテンシーで処理できます。そのため、HDDサーバーが夜間は問題なくても、メンテナンス処理が重なると急激に遅く感じられることがあります。

ZimaSpaceのバッファリングガイドでは、同じ混在I/Oの影響を説明しています。通常のメディア読み取りは低負荷で共存できますが、スキャンや書き込みの多い処理が隣接すると競合が発生し、レイテンシーが上昇します。この混在ストレージワークロードは、JellyfinではすべてのHDDが本質的に遅すぎると考えるより、断続的な遅延を説明するうえで適切です。

境界となるのは、共有キューです。データベースをSSDに移しても、バックアップが同じメディアプールを飽和させてデバイスキューイングが変わらないなら、ユーザー向けの改善は限定的かもしれません。単に移しやすいデータ種別ではなく、キューを作り出しているワークロードを分離してください。

SSD一択のルールではなく、ストレージ配置テストを行う

同じクライアントとメディアを使い、次の4項目を測定します。コールド状態でのライブラリ表示、ウォーム状態で繰り返すライブラリ表示、Direct Playの初回フレーム表示時間、通常のスキャンまたは書き込みの多い処理が並行しているときの再生です。データベースまたはメタデータのレイテンシー、メディアのスループット、デバイスキューイング、キャッシュ状態を記録します。その後、メディアファイルやクライアントを変更せず、アクティブなJellyfinの状態だけをSSDに移して再測定します。

このストレージ飽和度の分析手法は、変更した階層によって待ち時間が実際に解消されたかを解釈するのに役立ちます。スループットが合計ビットレートを余裕をもって上回り、キューが一定範囲に収まっているなら、メディアにはHDDを使い続けます。ユーザーが実際に体感できるコールド時や混在ワークロードのケースで、ランダムアクセスの低レイテンシーが一貫して改善をもたらすなら、アプリケーションの状態にはSSDを使います。

アプリデータを移した後にダッシュボードが高速になったというだけで、すべてのメディアをSSDに移さないでください。測定した同時読み取り、シーク、混在I/Oがメディア層を飽和させる場合にのみ、メディア層の強化を検討します。ストレージの指標が正常なのに再生に問題がある場合は、間違ったボトルネックに対して高速なディスクを購入するのではなく、トランスコード、クライアント互換性、メモリ、ネットワークに注目してください。