PlexサーバーでディスクI/Oが断続的に急増する原因は何ですか？

Plexの突発的なディスクI/Oは、ディスクが継続的に飽和していることよりも、キューに入ったバックグラウンド処理や遅延書き込みが原因であることが多いです。

まずは、このスパイクをタイミングの問題として考えてください。スキャン、サムネイル処理、データベーストランザクション、または別のコンテナによって短時間に大量の処理が発生し、オペレーティングシステムが物理的な書き込みの一部を遅延させることがあります。ドライブ自体を疑う前に、ディスクのバーストとPlexのアクティビティ、ホストの書き戻し処理、その他のサービスを照合してください。

まずはバーストの形状を確認する

短時間のスパイクと、持続するキューでは、示唆される障害モードが異なります。すぐに解消するバーストは通常のバッチ処理かもしれませんが、キューが深いまま残る場合は飽和を示している可能性があります。

使用率、飽和度、エラーの確認により、単に負荷が高いリソースと、実際に制約を受けているか故障しているリソースを区別できます。

同じ5分間のウィンドウで、ディスク使用率、キュー深度、レイテンシ、Plexタスクのタイミングを記録してください。Plexのタスク終了後もキューが高い状態に留まる場合は、タスクスケジューラーではなくストレージ経路を調査します。

Linuxは書き込みを遅延させ、まとめてフラッシュすることがある

ファイルシステムへの書き込みは、Plexが発行した瞬間に必ずしもドライブへ到達するとは限りません。特にメタデータを大量に処理するアクティビティ中は、メモリ内にダーティページが蓄積し、その後、目に見えるバーストとしてフラッシュされることがあります。

Linuxの書き戻し処理によって、アプリケーションが書き込みを生成した後も、物理ディスクのアクティビティが遅延することがあります。

ライブラリのスキャンやメタデータジョブの実行中に、ダーティメモリと書き戻しのカウンターをディスクのバーストと比較してください。デバイスのスパイクより前に書き戻しが増加している場合、そのバーストは少なくとも一部がオペレーティングシステムによるバッチ処理の影響です。

アプリデータのI/OとメディアのI/Oを分ける

PlexのメディアファイルとPlexのアプリケーションデータでは、アクセスパターンが大きく異なります。大容量の動画読み込みは主にシーケンシャルですが、データベース、メタデータ、アートワーク、ログ、キャッシュでは、より小さなランダムI/Oが発生します。

Plexのメタデータ保存領域には、データベース、アートワーク、インデックス、その他のサーバー状態ファイルが含まれます。

アプリデータ用ボリュームとメディア用ボリュームが別のデバイスにある場合は、それぞれを個別に測定してください。メディア用デバイスが静かな一方でアプリデータ用デバイスがスパイクする場合は、データベース、メタデータ、またはキャッシュのアクティビティに注目します。大量のメディアとは分離した永続的なアプリデータパスを使用すると、こうしたI/Oパターンを個別に観測しやすくなります。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ストレージを交換する前に、競合するサービスを確認する

共有ホームサーバーでは、他のコンテナが同時にストレージへアクセスすると、通常のPlex処理がバーストになることがあります。ダウンローダー、インデクサー、バックアップジョブ、メディア管理サービスは、スキャンやインポートのタイミングに合わせて書き込みを同期させることがあります。

複数サービスのメディアスタックでは、Plexが自動化、インデックス作成、ダウンロードの各サービスとパスやタイミングを共有することがあります。

競合している書き込みサービスを1つ一時停止し、同じPlex操作を繰り返してから、レイテンシとキュー深度を比較してください。1つのサービスを停止するだけでバーストが解消するなら、高速なディスクを購入する前に、そのワークロードのスケジュールを変更するか分離します。