Jellyfinは読み取り時と書き込み時で負荷が異なるのはなぜですか？

Jellyfinの読み取りと書き込みでは、大容量のメディア転送、小規模なデータベース更新、キャッシュされたページ、永続化が必要な書き込みが異なるI/Oパスを通るため、システム負荷のかかり方が異なります。

サーバーはHDDから複数の映画をストリーミングしても負荷が低く見える一方で、スキャン、メタデータの更新、視聴状態の更新、トランスコードキャッシュへの書き込みが重なると、動作が重く感じられることがあります。重要なのは単純な「ディスク活動」ではありません。ワークロードがシーケンシャルかランダムか、読み取り中心か書き込み中心か、キャッシュ可能か永続性が重要か、そして同じキューをめぐって他のサービスと競合しているかが重要です。

メディア再生は通常、大規模なシーケンシャル読み取りワークロード

Direct Playでは通常、クライアントがシークしない限り、配信されるメディアのビットレートに近い速度でファイルを先頭から順に読み取ります。シーケンシャルアクセスでは、ストレージデバイスとOSの先読み機能が効率よく動作するため、ランダムアクセスのレイテンシーがSSDよりはるかに悪いメカニカルディスクでも、一般的な再生を継続できることが多くあります。同時に、サーバー上で見えるCPU負荷は低いままの場合があります。

Jellyfinのストレージに関するガイダンスでは、メディアファイルとJellyfin自身のファイルを明確に分けています。メディアには主にビットレートを上回るシーケンシャルスループットが必要である一方、アプリケーションファイルではランダムアクセスが大きな割合を占めます。このメディアとアプリケーションのストレージ分離が、ドライブが数GBのコピー試験を通過しても、負荷の高いデータベースやメタデータツリーの配置先としては適さない場合がある理由を説明します。

境界となるのは、ビットレートのバーストと同時実行数です。複数の高ビットレート読み取り、リモートファイルシステムのレイテンシー、断片化したストレージ、あるいは競合するシークによって、シーケンシャルアクセスの優位性が失われることがあります。すべての映画ストリームが中断のない単一ファイルのコピーと同じように動作すると考えるのではなく、実際の再生構成で配信スループットとデバイスのキューイングを測定してください。

データベースとメタデータの処理は、より小規模でシーケンシャル性の低いI/Oを生む

ライブラリスキャン、検索インデックス、アートワークの更新、ユーザー状態、設定変更では、1つの大きなオブジェクトを最初から最後まで読み取るのではなく、多数のレコードやファイルにアクセスします。ワーキングセットがメモリ容量を超える場合は特に、小規模な処理によってアクセスレイテンシーとIOPSの影響が目立ちます。そのため、転送データ量が同じでも、メディアの読み取りよりはるかに高コストに感じられることがあります。

この違いがあるため、混在するワークロードが問題になった場合、ZimaSpaceのバッファリングガイドでは、低レイテンシーが求められるアプリケーション状態と、大容量のメディアを分離することを推奨しています。その混在I/Oの説明では、スキャン、ダウンロード、バックアップ、メタデータ処理が、それぞれ単独では妥当に見える場合でも再生に影響を与える仕組みを解説しています。

境界となるのは因果関係です。観測された遅延の原因がCPUによる変換や混雑したネットワークであるなら、すべてのファイルをSSDに移す必要はありません。まず、同じ処理の重なり方でアプリケーション状態のレイテンシーとメディア読み取りのレイテンシーを比較してください。症状と連動するストレージ処理だけを、配置変更の根拠にすべきです。

ページキャッシュによって、読み取りと書き込みは非対称に見える

バッファードリードは、一度ページが取得されるとメモリ上のヒットになることがあります。一方、バッファードライトは、メモリページを変更した時点で完了したように見え、その後でカーネルがダーティページをフラッシュすることがあります。そのため短時間の観測は誤解を招きます。書き込みバーストは最初は低コストに見えても、後からデバイス活動が発生することがあり、繰り返しの読み取りはディスクが関与しなくなるため、ほぼ無料に見えることがあります。

Linuxのページキャッシュモデルは、これら両方の経路を説明します。通常の読み取りではキャッシュされたページが生成され、書き込みでは、ライトバックまたは明示的な同期境界に達するまで永続化が延期されるダーティページが生成されます。このライトバックの動作により、データを生成したユーザー向けの操作がすでに完了した後で、Jellyfinに断続的なストレージ活動が見られる理由が説明できます。

境界となるのは、永続性とメモリプレッシャーです。データベースソフトウェアは、通常のキャッシュファイルより強い永続性保証を要求する場合があり、メモリに余裕のないホストでは、ダーティページの書き出しや有用な読み取りページの早期追い出しが発生しやすくなります。主にRAMで処理された操作から、デバイスの能力を判断しないでください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

同時読み取りと書き込みは、同じデバイスキューを通じて競合する

ディスクやSSDには最終的に限られた処理能力しかないため、再生の読み取り、データベースのコミット、ダウンロード、バックアップ、トランスコードセグメントは、互いに待ち行列を形成します。HDDでは、シーケンシャル読み取りが無関係な小規模書き込みによって中断されると、ヘッド移動によってペナルティが増幅されます。SSDはシークレイテンシーを大幅に削減しますが、書き込み増幅、フラッシュ処理、その他のコンテナによってデバイスが飽和に近づくと、キューイングが発生することがあります。

ストレージ飽和テストでは、これをリソースの問題として捉えます。利用率だけでは不十分で、キュー長とレイテンシーによって、要求が処理を待っているかどうかが分かります。小規模な同期処理のキューが長くなり、Jellyfinの対話的なデータベース要求を遅延させる場合、平均帯域幅が中程度のディスクでもボトルネックになることがあります。

境界となるのは、繰り返し確認できる相関関係です。スケジュールされたバックアップ中に一度だけ発生したレイテンシーの急上昇は、通常の再生に対してストレージ設計が不十分である証拠にはなりません。同じ重なりを再現し、書き込み処理を1つ停止して、Jellyfinのレイテンシーが低下するか確認してください。低下するなら、ストレージ層全体を交換せずに、その書き込み処理のスケジュール変更や分離で問題を解決できる可能性があります。

ストレージを変更する前に読み取り・書き込みマトリックスを作成する

同じメディアとクライアントを使い、再生のみ、再生とライブラリスキャン、再生と継続的な外部書き込み、通常時のピーク負荷全体という4つの状態をテストします。メディアスループット、アプリケーション状態のレイテンシー、デバイスキューの深さ、可能であればダーティページやライトバックの活動、初回フレーム表示やシークの遅延を記録してください。このマトリックスにより、問題が読み取り、書き込み、または両者の重なりに伴って発生するのかが分かります。

ライブラリ内を繰り返し移動すると、デバイスにアクセスしなくなる可能性があるため、ウォームキャッシュの対照試験も必要です。このコールドとウォームの対照によって比較の妥当性を保てます。コールド状態と繰り返し実行の両方を試し、キャッシュヒットをストレージの余力と誤認したり、キャッシュミスを恒常的な性能不足と誤認したりしないようにしてください。

再生が安定し、キューイングが一定範囲に収まり、通常の処理の重なりでアプリケーション状態のレイテンシーが大きく上昇しない場合は、既存の構成を維持してください。同じ干渉が一貫して再現する場合は、アプリデータ、キャッシュ、または書き込み負荷の高い処理を別の層に分離します。キューが健全なのに計算、メモリ、またはネットワークの指標に問題がある場合は、ストレージ以外の原因を調査してください。