アップデート後、JellyfinのCPU使用率が高くなるのはなぜですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does Jellyfin Consume High CPU After an Update? - Zima Store Online

アップデート後にJellyfinのCPU使用率が高くなる原因は、通常、起動時またはデータベース処理、スケジュールされたライブラリタスク、ソフトウェアまたは一部のトランスコード、あるいは新しいバージョンで挙動が変わったプラグインやバックグラウンドジョブの4つのいずれかです。どのプロセスとタスクがCPUを消費しているのかを特定するまで、アップデートによってJellyfinが恒常的に重くなったと決めつけないでください。

最も早い診断方法は、タイミングと負荷を比較することです。CPU使用率が起動後数分間だけ高い場合は、起動ログとタスクログを確認します。再生中だけ上昇する場合は、アクティブなストリームとFFmpegの処理経路を調べます。誰も視聴していないのに高い状態が続く場合は、スケジュールされたタスクとプラグインを確認します。一度に1つの変数だけを変更し、同じ状況を再現してください。そうすれば、一時的なアップデート後のジョブなのか、継続的なリグレッションなのかを判断できます。

起動時の処理と通常時のCPU使用率を切り分ける

負荷の少ない時間帯にJellyfinを一度再起動し、CPU使用率が高い状態がどれくらい続くかを記録します。サーバーログで、移行、データベースの最適化、プラグインの読み込み、ライブラリ関連のメッセージを確認し、Webインターフェースとスケジュールされた処理が落ち着くまで待ってから、新しい通常時の基準を判断してください。

Jellyfinのデフォルトのスケジュールタスクと起動時タスクには、ライブラリのスキャン、キーフレームの抽出、データベースの最適化、キャッシュのクリーンアップ、プラグインの更新などが含まれます。一部のタスクは起動時にも実行されるため、アップデート後の一時的な負荷上昇は、継続的な性能変化ではなくメンテナンス処理である可能性があります。

タスクの完了後にCPU使用率が以前のアイドル時の範囲に戻るなら、トランスコードの調整やハードウェアの交換は必要ありません。一時的なバックグラウンド処理が原因だと判断できるため、再生に支障がある場合は、負荷の高いタスクを視聴時間帯以外にスケジュールしてください。

再生時にCPUが使われるようになったか確認する

特定のクライアントで再生を開始したときだけCPU使用率が急上昇する場合は、Jellyfinのダッシュボードを開き、そのセッションがダイレクトプレイ、リマックス、音声トランスコード、動画トランスコードのどれなのかを確認します。クライアントやコーデックの変更によって、以前は使われていなかったソフトウェア処理経路が選択されることがあります。

同じクライアントで同じメディアを、字幕をオフにして再生し、CPU使用率を比較してください。使用率が大きく下がる場合は、字幕またはトランスコードの処理経路が原因です。ダイレクトプレイ中も高いままなら、エンコーダーのせいにせず、ストレージ、プラグイン、または別のプロセスを調べてください。

再生処理をさらに詳しく確認するには、ハードウェアトランスコードの確認で説明されている方法と同じ手順を使い、設定でハードウェアアクセラレーションが有効になっていることだけを信頼せず、実際に使用されているGPUとFFmpegの処理経路を確認してください。

ホストの負荷を推測せず、コンテナのプロセスを測定する

共有ホームサーバーでは、実際にCPUを消費しているプロセスがJellyfinかどうかを確認してください。バックアップ、メディアインデクサー、ダウンロードクライアント、サムネイル生成、ファイルシステムのメンテナンスなどが、同じ再起動またはアップデートのタイミングで開始された可能性があります。

コンテナランタイムには、コンテナごとの使用率を確認する機能があります。Dockerのstatsコマンドは、実行中のコンテナのリソース使用率をリアルタイムで表示するためのものです。問題を再現しながら、コンテナごとのリソース使用率、または使用中のプラットフォームに相当する機能を確認してください。

別のコンテナがCPUを使用している場合は、そのジョブを一時停止して、元のテストをもう一度実行します。Jellyfinが使用している場合は、Jellyfinのタスクと再生処理を引き続き調べてください。そうでなければ、アップデートはホスト負荷と同時に発生しただけで、原因ではありません。

Featured

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

ZimaCube2

バックグラウンド処理の原因を1つずつ無効化または再スケジュールする

Jellyfinのスケジュールタスク画面で、現在実行中または繰り返し再起動しているタスクを確認します。独自のスケジュール処理、メタデータプロバイダー、イントロ検出、字幕処理、その他のライブラリ自動化機能を追加するプラグインも確認してください。

すべてのプラグインとタスクを一度に無効化したままにしないでください。負荷の高そうな候補を1つ一時停止し、CPU使用率が落ち着くまで待ってから、同じアイドル状態またはスキャン状態を再現します。明確に低下すればその処理経路が特定でき、変化がなければ元に戻して次の候補をテストします。

タスク自体は必要でも実行時間が適切でない場合は、不具合とみなすのではなく、スケジュールを変更してください。アップデート後にループしたり、失敗したり、すぐに再起動したりする場合は、データベースファイルを変更したりサーバーを再構築したりする前に、ログとプラグインおよびバージョン情報を保存してください。

アップデート後と同じ負荷で修正を確認する

原因を特定したら、該当する修正を行います。移行処理を完了させる、タスクを再スケジュールする、ハードウェアアクセラレーションを復元する、問題のあるプラグインを更新または無効化する、あるいはクライアントやトランスコードの条件を修正してください。その後、一度再起動し、以前にCPU使用率を上昇させたのとまったく同じテストを繰り返します。

修正が成功した状態とは、CPUの挙動が再び負荷に対応していることです。起動後はアイドル状態に落ち着き、ダイレクトプレイは軽いままで、必要なトランスコードは想定どおりのアクセラレーション経路を使用します。きっかけとなった処理を再実行せず、1分間静かな状態が続いただけでは十分な確認とはいえません。

実行中のタスクがなく、トランスコードもなく、競合するコンテナもなく、プラグインを整理した状態でもCPU使用率が高いままなら、さらに調査してください。その時点で、Jellyfinのバージョン、OSとアーキテクチャ、タスクの状態、短時間のログを取得しておけば、負荷の高い起動処理だけを一般化せず、バージョン固有のリグレッションを調査できます。