ストレージのレイテンシーが複数ユーザーによるJellyfinストリーミングに与える影響

ストレージのレイテンシは、複数の読み取りや小規模な状態操作が長時間待たされ、クライアントのバッファ余裕を削ることで、複数ユーザーでのJellyfin利用に影響します。

ディスクが複数ストリームに十分なシーケンシャルスループットを謳っていても、ユーザーがシークしたり、メタデータを読み込んだり、スキャンを実行したり、同じデバイスに別のサービスが書き込んだりすると、応答性が低下することがあります。したがって、複数ユーザーでの動作は、毎秒何メガバイト処理できるかだけでなく、キューイングにも左右されます。各テストでは同じストリーム数とバックグラウンド負荷を使用し、待ち時間やキュー深度の変化をストレージに起因するものとして評価できるようにします。

シーケンシャルスループットはストレージ性能の一部にすぎない

長時間のメディア読み取りはディスクにとって処理しやすい一方、起動、シーク、ポスター画像、データベース処理、同時ファイルアクセスでは、より小さく予測しにくい操作が発生します。こうした待ち時間は、合計のデータ転送速度がデバイスの最大値に達する前から目立つことがあります。

レイテンシとスループットは異なるストレージ特性を表すため、1回のシーケンシャルベンチマークだけでは、複数ユーザー環境での応答時間が低く保たれることを証明できません。

持続的なファイル読み取りと、シーク負荷またはメタデータ負荷の高いタスクを別々に測定し、その後、複数のセッションをアクティブにした状態でも繰り返します。

異なるワークロードでもアプリデータとメディアは競合する

データベースとメタデータを大量のメディアと同じ低速ボリュームに置くと、小さな状態読み取りが長時間の転送の後ろで待たされることがあります。その結果、再生自体はおおむね安定しているのに、インターフェースだけが遅く感じられる場合があります。

ランダムアクセスの動作はシーケンシャルI/Oとは異なります。小さな状態読み取りと長時間のメディア転送を同じデバイスで処理する場合、この違いが重要になります。

比較テストでは、アプリデータのパスだけを低レイテンシのストレージ階層へ移動します。メディアのスループットを変えずにブラウジングが改善するなら、状態データの経路が問題の一部だったことになります。

同時利用ユーザーが増えると、小さな遅延がキューイングに変わる

複数のユーザーがほぼ同時に異なるファイルを開き、シークし、アートワークを要求することがあります。さらに別のコンテナやバックアップジョブが書き込みを加えると、個別には許容できるレイテンシが継続的なキュー深度へと変わる可能性があります。

同じホスト上に配置されたワークロードは、各アプリケーションが単独では正常に動作していても、測定可能なリソース干渉を引き起こすことがあります。

競合する書き込み処理の有無で、同じストリーム数を実行します。NASメディアセンターのトポロジーは、アプリの状態データ、メディア、バックグラウンドジョブに明確なストレージ上の役割を割り当てると、より調整しやすくなります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

キューの発生を再現できるようになってからストレージをアップグレードする

SSDを購入しても、クライアント側のコーデックの問題やネットワークの飽和は解決しません。同じユーザーが感じる遅延がストレージの待ち時間と連動し、I/O負荷を取り除くと改善する場合にのみ、ストレージが適切な対策対象となります。

USEメソッドを使うと、飽和状態とエラーを明確に把握できます。これにより、本当に負荷が高いストレージリソースと、単に稼働しているだけのリソースを区別しやすくなります。

再現可能な複数ユーザーテストを実施し、キューが発生しているデバイスを特定したうえで、配置に関する変数を一度に1つだけ変更します。キューイングが減っても症状が別の場所に残るなら、アップグレードを続けるのはやめましょう。