誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アクティブな視聴者がいない場合でも、バックグラウンドタスクや関連サービスがCPU、ストレージ、GPUのリソースを消費するため、Jellyfinが高温になったり、ファンの音が大きくなったりすることがあります。
「誰もストリーミングしていない」というのはユーザーの利用状況を示すものであり、ホストの稼働状況を示すものではありません。ライブラリのスキャン、メタデータの更新、トリックプレイの生成、チャプターの抽出、プラグインによる解析、バックアップ、ダウンロード、その他のコンテナによって、パッケージ電力やファン速度が上昇することがあります。冷却機構の不具合だと判断する前に、発熱と相関するプロセスやスケジュールされた実行時間を特定しましょう。
冷却ハードウェアを確認する前に、スケジュール済みタスクを確認する
まず疑うべきなのは、視聴者がいない時間帯に開始される定期処理です。画像処理や解析などの負荷が高いタスクは、ダッシュボードに再生セッションが表示されていなくても、継続的な計算負荷を発生させることがあります。
ライブラリのメンテナンスは、アクティブな視聴者がいなくても実行されます。スケジュールされたJellyfinのスキャンは、CPUやディスクのアクティビティと関連付けて確認すべき、具体的な処理の発生源の一つです。
ファンや温度の急上昇を、スケジュール済みタスクの履歴と比較します。負荷の高いジョブを決まった時間帯に移動し、温度の推移がそのジョブに伴って変化するか確認してください。
ソフトウェアトランスコードや停止していないセッションを探す
クライアント側で視聴を停止していても、変換プロセスや終了に失敗したセッションがアクティブなまま残っていることがあります。また、ハードウェアアクセラレーションに失敗すると、中程度の処理でもCPUに継続的な負荷がかかる場合があります。
トランスコード時のホストの負荷状況は、アイドル状態での配信とは大きく異なります。実測されたJellyfinのトランスコードでは、コーデックやフィルタ処理の経路ごとにCPUとGPUの負荷を分けて確認できます。
FFmpegのプロセス、現在のセッション、最近のログを確認します。孤立したプロセスを終了したときにCPU負荷が下がる場合は、ファンカーブを変更する前に、セッションまたはトランスコードの原因を解決してください。
同じホスト上の他のコンテナを測定する
Jellyfin自体が静かな状態でも、ダウンローダー、バックアップ、写真のインデクサー、AIワークロードなどが同じマシンを発熱させることがあります。コンテナ名によって、熱の影響範囲が分離されるわけではありません。
同じホストに配置されたワークロードは、共有リソースの干渉を引き起こすことがあります。これは、あるアプリケーションが忙しくない場合でも、ホスト側に現れることがあります。
温度が上昇している間に、プロセスまたはコンテナ単位でCPUとI/Oの使用状況を記録します。ホームサーバーのワークロードマップには、メディア再生とは無関係でも、実行時間が重なるジョブを含める必要があります。
温度を壁面電力と処理内容と比較する
BIOSやカーネルの更新後にファンの動作が変わることはありますが、発熱は依然として電力とワークロードに左右されます。センサーや冷却機構の故障を疑う前に、まず測定してください。
アイドル時とトランスコード時の消費電力は、ホームサーバープラットフォームによって大きく異なることがあり、必要な冷却も大きく変わります。
アイドル時と既知のタスクを1つ実行したときについて、壁面電力、CPUパッケージ電力、温度、ファン速度を同時に記録します。測定した電力レベルに対して温度が異常な場合にのみ、冷却機構を調査してください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。
Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。
Jellyfinはバックグラウンドジョブ用にどのくらいの空き容量を確保すべきですか？
Jellyfinに適した一律の空き容量率はありません。永続的な増加と一時的なピークを別々に測定し、その両方を上回る余裕を確保してください。
