Plexはなぜ一晩中ディスクにアクセスし続けるのか？
夜間のディスクアクセスはPlexの通常メンテナンスであることが多いものの、設定した時間帯以外にも繰り返しアクセスが発生する場合は、何かを無効にする前にプロセス単位で確認する必要があります。
常時稼働のホームNASでは、誰も視聴していなくても、データベースのバックアップ、ライブラリの更新、メタデータの更新、キャッシュのクリーンアップ、メディア分析などが静かな時間帯にスケジュールされているため、Plexがストレージにアクセスすることがあります。まずI/Oの発生時刻をPlexの動作と照合し、その後、Plexによるものか、別のコンテナ、バックアップジョブ、ファイルシステムのタスク、クライアントからのリクエストによるものかを切り分けるのが有効です。メンテナンスオプションを最初からすべて無効にするのは避けてください。これらのジョブの中には、サーバーの状態を保護したり最適化したりするものがあるためです。
まずディスクアクティビティとPlexのメンテナンス時間帯を照合する
NASの設定を変更する前に、Plex Webを開き、「スケジュール済みタスク」の開始時刻と終了時刻を確認してください。Plexでは、夜間に開始するデフォルトのメンテナンス時間帯が設定されており、データベースのバックアップ、データベースの最適化、キャッシュのクリーンアップ、ライブラリの更新、メタデータ処理、メディア分析などのタスクが実行されることがあります。ディスクの動作音がその時間帯の中で始まり、終わっているなら、故障しかけたドライブよりもスケジュールされた処理が有力です。
夜間にどのジョブが正当に実行される可能性があるかを判断するには、公式のPlexのスケジュール済みタスクのドキュメントが最適な参考資料です。設定されたスケジュールと、ドライブのLEDやストレージグラフが実際にアクティブになった正確な時刻を比較してください。近いタイミングで一致していれば有力な手掛かりになります。一致しない場合は、引き続き原因を調べる必要があります。
アクティビティがPlexの時間帯以外に始まった場合、Plexが原因だと決めつけないでください。NASのバックアップ、SMARTテスト、スクラブ、インデクサー、ダウンローダー、別のメディアアプリが同じ時刻に開始していないか確認します。判断の分岐は単純です。Plexのタスクに連動するアクティビティはPlex側で調べ、連動しないアクティビティはホストまたは別のコンテナ側で調べます。
ライブラリのスキャンを分析やトランスコードのI/Oと切り分ける
次に、ディスクが忙しい間にPlexが何をしていると表示しているかを確認します。通常、ライブラリスキャンではメディアのパスを巡回し、変更された項目を更新します。一方、メディア分析ではファイルのより広い範囲を読み取ることがあります。トランスコードはさらに異なり、再生に紐づいて一時的な出力を作成するため、静かなメンテナンス時間帯ではなく、現在再生中のストリームとアクティビティが一致するはずです。
大規模なライブラリを最近追加した、パスを変更した、より詳細な分析を有効にした、メタデータを復元した、といった場合は、1回のメンテナンス時間帯だけ通常より大幅に負荷が高くなることがあります。実用的なホームメディアサーバーのワークフローでも、ライブラリの整理、スキャン、再生、トランスコードを別々のレイヤーとして扱います。これらを分けて考えることで、予想されるアプリケーションの処理をストレージデバイスの問題と誤認せずに済みます。
アクティブなクライアントがない状態で1晩、条件をそろえて確認し、同じI/Oが再び発生するか記録してください。アクティビティが消えた場合は、クライアントからのリクエスト、リモートストリーム、ダウンロード、再生をきっかけとした変換が関係していた可能性があります。同じスケジュール時刻に続く場合は、クライアントのトラブルシューティングではなく、メンテナンス側の切り分けを続けます。
設定を変更する前に正確なプロセスを特定する
NASのプロセスモニターまたはストレージモニターを使い、アクティビティ発生中に読み書きを行っているプロセスを特定します。Dockerホストでは、同じタイムスタンプ周辺のPlexコンテナのアクティビティとログも確認してください。目的はディスク使用率の合計値を眺めることではなく、そのI/OがPlex、別のコンテナ、ホストサービスのいずれによるものかを特定することです。
Plexがプロセスである場合は、タイムスタンプをアクティビティビュー、サーバーログ、メンテナンススケジュールと照合します。別のプロセスがI/Oを行っているなら、Plexの設定は変更せず、そのプロセスを追ってください。1つずつ変数を切り分けることで、Plexのメンテナンスを無効にしただけで、実際にはバックアップやインデックス作成のジョブがディスクを起こし続けているという、よくある誤りを防げます。
再起動を解決策と考えないでください。再起動によって現在のタスクがクリアされ、一時的にディスクが静かになることはあります。しかし、それで分かるのはプロセスが停止したときに処理も止まったということだけです。より確実なテストは、同じ設定のまま次回のスケジュール実行時に同じアクティビティが再発するかどうかを確認することです。
確認できたトリガーだけを変更し、1晩かけて検証する
特定のPlexタスクが明らかに原因で、発生時刻が問題になる場合は、まずメンテナンス時間帯をより都合のよい時間に移動します。個別のタスクを無効にするのは、何を失うことになるのか理解してからにしてください。データベースのバックアップ、最適化、分析にはそれぞれ異なる目的があるため、すべてを無効にするのは特定のジョブを見つける代わりにはなりません。
変更後は、元の条件を再現します。次のメンテナンス時間帯までサーバーをアイドル状態にして、以前と同じ時刻のディスクアクティビティを比較してください。解決したと言えるのは、問題となっていたI/Oが以前発生していた時刻に起こらなくなり、Plexが新しい時間帯に期待どおりライブラリのスキャン、再生、メンテナンスを続けられる場合です。
プロセスを特定してもI/Oの原因が分からない場合、ストレージエラーを伴う場合、またはPlexを停止してもI/Oが続く場合に限り、ドライブやファイルシステムの診断へ進んでください。その時点で症状はPlexの範囲を超えており、Plexの設定をさらに調整しても解決につながる可能性は低いでしょう。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
