Plexのアップデート直後にCPU使用率が高くなるのは、一時的な移行処理や分析処理が原因の場合がありますが、いつまでも正常だと考えてはいけません。
最も安全な診断方法は、時間を区切って確認することです。アップデート後のバージョン、起動時刻、実行中のPlexプロセス、ディスク活動を記録します。移行処理や分析処理が明示的に完了するまで待ち、その後、2回目のクリーンな再起動中のCPU使用率と比較します。同じタスクが実行されていないのに負荷が続く場合は、「アップデート移行」ではなく、回帰やワークロードの診断に切り替えます。
設定を変更する前にデータベース移行を確認する
一部のPlexリリースでは、サーバーが完全に準備完了する前に、既存のデータベースの状態をスキャンまたは変換する必要があります。この処理は、限られた時間だけCPUとアプリデータのI/Oを消費することがあります。
一部のリリースでは、起動が完了する前に既存のデータベースレコードを完全にスキャンする必要があります。そのため、一時的なCPU使用率とアプリデータのI/Oは、通常のアイドル時の動作ではなく、その移行処理が完了するまでの状態と照らして判断してください。
ログで移行処理の実行状況を確認し、準備完了状態に戻ったときにCPU使用率が低下するかを記録します。最初の再起動が通常より遅いというだけで、既知の移行処理を中断しないでください。
再分析と停止したプロセスを切り分ける
アップデートによって、新しいメディア分析、プレビュー生成、メタデータ処理が開始されたり、再実行されたりすることもあります。この負荷はWebインターフェースにアクセスできるようになった後も続く場合があり、サーバーの回帰に見えることがあります。
アップデート後の分析は長時間にわたってCPUを消費することがあります。実際のPlexタスクを特定する間は、コールド状態のワーキングセットや再構築中のワーキングセットによって、初回実行時の挙動が後のアイドル時と異なる可能性も考慮してください。
任意のスケジュールタスクを一時停止するか、実行中のジョブが完了するまで待ってから、同じ条件でアイドル時の状態を再確認します。CPU使用率が下がる場合は、グローバルなCPU制限を変更するのではなく、タスクのスケジュールを変更してください。
2回目の再起動を比較する
一度きりの処理が、クリーンな起動のたびに同じように繰り返されることはありません。処理の完了後に再起動をもう一度行うことは、移行処理と継続的な動作を切り分ける最も早い確認方法です。
比較中はアプリデータのパスを変更せず、同じプロセス名とメトリクスを監視します。意図的に変更する変数を完了済みのアップデートだけにするため、永続的なアプリデータのパスは一定に保つ必要があります。
2回目の起動でもCPU使用率が最大状態のままなら、ログを収集し、その負荷が検索、スキャン、トランスコード、または別のプロセスによるものかを特定します。アップデート日だけを根拠にせず、具体的に特定したワークロードを起点に調査を続けてください。
安全な状態の境界がある場合にのみロールバックする
新しいバージョンによって保存状態が変更され、その状態を古いバージョンが理解できない場合、バイナリのロールバックは危険です。トラブルシューティングの近道としてロールバックを行う前に、アップデート前のデータベースを保護してください。
ロールバックでは、一致する状態のコピーを復元する必要があります。これは、クリーンな復旧ポイントによって、古いバイナリが安全に理解できない変更から保護できるためです。
ロールバックが必要な場合は、対応するバージョンとともに、正常に動作していたアップデート前の状態を復元してください。CPU使用率の高さの原因を切り分けるために、1つの稼働中データベースに対して古いバイナリと新しいバイナリを交互に使用しないでください。
サポートとヒント
もっと読む

Jellyfinは別のコンテナとGPUやアクセラレーターを安全に共有できますか?
GPUの共有には条件があります。デバイスが認識され、ドライバーが対応していることを確認してから、両方のワークロードを実行し、ソフトウェアフォールバックが発生していないか監視してください。

Jellyfinのエラーがクライアントとサーバーのどちらに起因するかを見分ける方法
Jellyfinのエラーが特定の1台のデバイスにだけ発生する場合はクライアント側に原因があり、同じ経路で複数のクライアントが失敗し、ログも一致する場合はサーバー側に原因があります。

Jellyfinのキャッシュと一時ストレージの設定方法
永続的なデータ、再構築可能なキャッシュ、一時的なトランスコード用ストレージを分離し、実際に再生テストを行って容量と権限を確認します。

