ライブラリを変更すると、Plexのバックグラウンド処理が急増するのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Plex Background Work Spike After a Library Change? - Zima Store Online

ライブラリを変更した後にPlexのバックグラウンド処理が急増するのは、検出によってスキャン、メタデータの照合、分析、派生データの生成が順番に開始されることがあるためです。

新しいエピソードが1本追加されただけなら短時間の集中処理で済む場合がありますが、フォルダー名の変更、ライブラリの再マウント、大量インポートなどが行われると、Plexが多数のパスを再確認し、より長時間の分析処理をスケジュールすることがあります。サムネイル、イントロやチャプターの処理、バックアップ、その他のホームサーバーのジョブが重なると、この急増はさらに目立ちます。重要なのは、現在どのバックグラウンド処理段階が実行されているか、そして正常に進行しているかを特定することです。

ライブラリの変更によって新しい行だけでなく新たな処理が発生する

メディアを追加、移動、名前変更したり、メディアの構成を変更したりすると、Plexは一覧にタイトルを1件追加する以上の処理を行います。変更されたパスを検出し、メディアを識別し、メタデータを照合し、データベースのレコードを更新したうえで、どの分析ジョブを適用するか判断する必要があります。変更の規模によって、この一連の処理のどこまでが実行されるかが決まります。

大規模ライブラリの運用者からは、ライブラリスキャンの動作は、変更されたコンテンツの量や種類によって異なると報告されています。そのため、変更後の急増を正しく判断するには、Plexが新しいエピソードを1本検出したのか、ツリー全体のマッピングが変更されたのかを把握することが重要です。

1ファイルを追加した後と、フォルダー名を変更した後またはマウントパスを変更した後で、ログとプロセスの稼働状況を比較してください。大規模な構造変更でのみ急増が発生するなら、原因は偶発的なアイドル処理ではなく、照合範囲の広さにあります。

スキャンが増分処理から広範な列挙に変わることがある

増分スキャンでは、通常、変更されたライブラリの一部だけが処理されます。しかし、ファイルシステムイベントの検出漏れ、リモートマウント、大規模なパス変更、明示的なフルスキャンによって、Plexがはるかに広い範囲を列挙することがあります。すると、短時間の集中処理が、ディレクトリの継続的な走査、メタデータの確認、データベースの更新へと変わります。

長時間実行されたライブラリの事例では、メディアパスとライブラリサイズの組み合わせによって、ライブラリ全体のスキャンが何時間も続くことがあります。重要なのは正確な所要時間ではなく、スキャン範囲が予想していた変更を超えて広がっているかどうかです。

どのライブラリがアクティブか、スキャンが部分スキャンかフルスキャンか、実行中にストレージの遅延が増加しているかを確認してください。スキャンが想定どおり小さな範囲だけに限定されているなら、次は分析タスクを調べます。小さな更新のたびにツリー全体を走査しているなら、計算リソースを追加する前に変更検出またはスケジュールを修正してください。

メディア分析は検出完了後にCPU負荷を追加する

検出は最初の段階にすぎません。Plexは新しく見つかった動画を分析し、技術的なプロパティを把握したり、メディアを読み取る必要がある機能の準備を行ったりします。設定によっては、新しいアイテムの追加後に、プレビュー、イントロ、チャプター、音声分析、その他の派生データの生成が開始されることがあります。画面上のライブラリスキャンが完了した後も、これらの処理が続く場合があります。

プレビュー生成は、スキャン後の処理が続く一般的な原因です。動画プレビューのサムネイルは、軽量なファイル名チェックではなく、メディアのフレームから生成されるためです。そのため、タイトルがすでにライブラリに表示されているのに、CPUやストレージの処理が続くことがあります。

スキャン段階の後もどのプロセスが高負荷のままかを確認し、スケジュール設定や新規追加アイテムの分析設定と照らし合わせてください。任意の分析機能を一時的に無効にしたときに急増が収まるなら、再生設定を変更せずに、バックグラウンド処理の段階を特定できます。

-15% OFF

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

Single board computer zimaboard2

サムネイルとチャプターのジョブは予想以上に長く続くことがある

サムネイルのジョブは、ファイルの長い範囲を読み取り、多数の小さな派生画像やインデックスエントリを書き込むため、特に負荷が目立ちます。そのため、大量の新規メディアを追加すると、メディア自体はすでに再生可能であっても、CPU、ディスク読み取り、アプリ状態の書き込みが継続的に発生することがあります。

Plexがサムネイルの生成で停止した事例は、完了しないジョブと、単に負荷が高いものの正常に進行しているジョブを分けて考える必要性を示しています。前者には待機またはスケジュール調整が必要ですが、後者では問題のあるアイテムやジョブの調査が必要です。

処理中のメディアアイテムが時間の経過とともに変わっているか、データベースやメタデータのサイズが増え続けているかを確認してください。進行しているジョブは、より負荷の少ないメンテナンス時間帯に移せます。再起動後も同じアイテムを繰り返し処理するジョブは、次のフルスキャンを行う前に、ファイルレベルまたはデータベースレベルで診断する必要があります。

共有されたホームサーバーの負荷によって急増が大きく見える

多機能なホームサーバーでは、Plexのバックグラウンド処理が、バックアップ、ダウンロード、スクラブ、写真のインデックス作成、別のコンテナのメンテナンスなどと重なることがあります。その結果、ライブラリの変更を単独で行った場合には現れないストレージキューやCPU競合が、Plexをきっかけにした負荷増加によって表面化します。

サーバーがアイドル状態に見えるのにCPU使用率が高い状態が続く現象は、Plexのバックグラウンド処理中に報告されています。また、バックグラウンドのCPU急増は、実行中のタスクやメディアアイテムと照合して初めて役立つ情報になります。使用率だけでは、どのジョブが原因かは特定できません。

競合するメンテナンスを一時停止した状態で、ライブラリの変更を1回だけ制御して実行し、その後通常のスケジュールに戻してください。急増が短くなったり、再生が滑らかになったりするなら、競合が原因の一部です。ディスク容量不足とバックグラウンドI/Oが重なっている場合は、バックグラウンド用ストレージの確認を行い、容量の問題と処理負荷を切り分けてください。