JellyfinがCPU、RAM、ストレージ、ネットワークのどれによって制限されているかを見極める方法

CPU、メモリプレッシャー、ストレージレイテンシ、ネットワークの挙動を同時に測定しながら1つの障害を再現して、Jellyfinのボトルネックを特定しましょう。

バッファリング、起動の遅さ、ブラウジングの遅延、トランスコードの失敗は、ソファから見ると似た症状に見えても、原因となるリソースは異なります。診断ではメディア、クライアント、画質、再生モードを一定に保ち、症状と同時に飽和またはエラーが現れるリソースを特定します。その相関関係を再現できるまで、変数は1つだけ変更してください。

実行待ちの処理が滞留しているなら、CPUが疑わしい

CPU使用率が高いだけでは十分な根拠になりません。より強い兆候は、アクティブなトランスコードやバックグラウンドジョブが時間目標に間に合わない状態で、持続的な飽和が発生していることです。ハードウェアアクセラレーションを使えば、同じ処理を汎用CPUコアから別の経路へ移せます。

USEメソッドは、使用率、飽和、エラーを区別します。これにより、負荷が高くても正常なプロセッサをボトルネックと誤認するのを防げます。

障害の再現中に、CPUの実行キューとトランスコード速度を比較します。ストリームがダイレクトプレイになったとき、またはハードウェアアクセラレーションが機能したときにCPUの飽和が解消するなら、計算処理の経路が原因だと確認できます。

メモリプレッシャーによって回収やスワップが発生しているなら、RAMが疑わしい

Jellyfinはファイルシステムキャッシュやデータベースキャッシュの恩恵を受けますが、ワーキングセットがメモリに収まっている場合、それ以上メモリを増やしても効果はありません。問題なのは、プレッシャーによって繰り返しのメモリ回収、スワップ、または他のプロセスの強制終了が発生するケースです。

キャッシュされたワーキングセットは、別のワークロードに置き換えられるまで、ストレージからの読み取りを減らせます。

同じシナリオで、メモリプレッシャー、メジャーフォールト、スワップを監視します。RAMを追加または解放することでストレージの繰り返しアクセスがなくなるなら、メモリが原因の一部だったと判断できます。

I/O待ち時間が症状と連動しているなら、ストレージが疑わしい

メディア用ディスクは平均スループットが十分でも、ランダムなメタデータアクセスや複数の同時読み取りによってキューが形成されることがあります。再生開始やシークでは、安定したシーケンシャル再生よりも早くこの問題が表面化することがあります。

ストレージのレイテンシとスループットを比較することで、問題が応答時間にあるのか、純粋な帯域幅にあるのかを判断するための適切な測定ができます。

問題を再現しながら、デバイスのレイテンシとキューの深さを記録します。Jellyfinのバッファリング確認は、ローカルストレージからサーバーへ安定してデータを供給できることを確認してから、ネットワークの調査へ進めてください。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

サーバーがクライアントの受信速度を上回る速さでデータを生成しているなら、ネットワークが疑わしい

トランスコードとストレージの経路が正常でも、Wi-Fi、リモート接続のアップロード帯域、クライアント側のポート、VPNの経路が要求されたビットレートを維持できなければ、バッファリングは発生します。リンクが公称速度に達する前でも、パケットロスや再送が影響することがあります。

正常なサーバーをボトルネックと判断する前に、メディアストリームの帯域幅予算を使って、ストリームのビットレートと実際の配信リンクを比較します。

有線のローカルクライアントと、同じストリームの低ビットレート版をテストします。ホストのリソースが正常なまま症状が経路やビットレートに応じて変化するなら、解決策はネットワーク層に求めるべきです。