JellyfinがCPU、メモリ、ネットワーク、ストレージのどれに制約されているかを見分ける方法、】【

同じワークロードを繰り返し実行し、ユーザーに見える症状と、エラーやキューイングを伴って飽和するリソースを照合することで、Jellyfinのボトルネックを特定できます。

CPU使用率のグラフが高いからといって、CPUが限界だとは限りません。ストレージがアクティブだからといって、ストレージが原因だとも限りません。同じファイル、クライアント、画質、セッション数を使い、条件を一度に1つだけ変更してください。これにより、本当の依存関係による上限と、クライアントが選択したより負荷の高い再生経路を切り分けられます。

再生条件を一定に保つ

メディアファイルを1つ、クライアントを1つ、画質ポリシーを1つ、同時実行数を1つ選びます。リソースグラフを確認する前に、セッションがダイレクト再生、リマックス、トランスコードのどれで動作しているかを記録してください。再生モードによって、どのリソースが使用されるべきかが決まるためです。

リソースの挙動を比較する前にサーバー側の経路を把握できるよう、まずはダイレクト再生からトランスコードへの切り替えを確認します。

条件を管理したベースラインを用意することで、ブラウザーのトランスコードとネイティブなダイレクト再生セッションを比較して、その差をハードウェアのボトルネックと誤認するのを防げます。

CPUとメモリは異なる兆候を示す

CPU負荷が原因の処理では、通常、ソフトウェアデコード、フィルター、字幕の合成、エンコードに連動して負荷が上がります。一方、メモリ圧迫では、メモリ回収、スワップ、ワーカーの停止、ページングによるストレージアクティビティの増加などが現れます。症状が重なることはありますが、確認すべきカウンターは異なります。

平均CPU使用率やRAM使用量だけで判断せず、使用率と飽和状態を使って、使用率、飽和状態、エラーをまとめて確認してください。

ストレージやネットワークを変更せずにフィルターを無効にするかハードウェアデコードへ切り替えることでリアルタイム速度に戻るなら、CPU処理が関与しています。別のコンテナを停止したときにメモリ回収やスワップが消えるなら、メモリ圧迫の可能性が高くなります。

ネットワークとストレージには経路別のテストが必要

アップロード帯域が飽和すると、ホストのCPUに余裕があってもリモート再生がバッファリングすることがあります。ストレージのレイテンシーは、シーケンシャルスループットが十分に見えていても、起動、シーク、メタデータ処理、トランスコード用の一時領域に遅延を生じさせます。クライアントが実際に使用する経路をテストしてください。

ストレージのレイテンシーとスループットを別々に測定し、競合する転送を停止した状態で同じストリームを比較します。

キューの深さやアップロード使用率に応じて症状が変化するなら、CPUやRAMを変更しても解消しません。経路がアイドル状態になっても症状が続く場合は、クライアントの互換性または計算処理を確認してください。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

4つのリソースによる判定マトリクスを使う

各実行について、観測された症状、最初に飽和したカウンター、エラーが増加したかどうか、そのリソースへの負荷を取り除くことでベースラインに戻ったかどうかを記録します。1つの肯定的なシグナルだけでは不十分です。その関係が繰り返し確認できなければなりません。

簡潔なコールドベンチマークとウォームベンチマークを使うことで、アップグレードしたいという直感ではなく、証拠に基づいて判断できます。

繰り返し実行して、1つのリソースが症状を説明できるようになったら終了します。どのリソースも症状と連動しない場合、実際の問題はクライアントUI、起動順序、または4リソーステストの範囲外で発生した再生モードの変更である可能性があります。