Plexの読み込みと書き込みでサーバー負荷が異なる理由

Plexは、サイズの大きいメディア転送と小さな状態更新でI/Oパターンが大きく異なるため、ホームサーバーの異なる部分に負荷をかけます。

ストリーミング中は大きなファイルをシーケンシャルに読み取りながら、Plexがデータベース、ログ、メタデータ、一時データを小さな単位で同時に更新することがあります。これらの処理は同じデバイスを共有できますが、負荷に対する反応は異なります。「ディスク使用率」が原因だと判断する前に、メディアのスループットとアプリデータのレイテンシーを分けて測定してください。

メディアの読み取りは通常、スループット重視

ダイレクト再生では、大きく連続したメディアデータを読み取るため、複数のストリームを同時に処理できる十分な余裕と、持続的なスループットが主に必要です。小さなレコードを大量に扱うデータベースほど、シークレイテンシーは重要ではありません。

高速なストレージが役立つのは、そのレイテンシー、容量、トランザクション特性がワークロードに適合する場合に限られます。アクティブデータ向けストレージのトレードオフを考えると、デバイスの公称速度だけでなく、アクセスパターンを確認するほうが有用です。

最もストリーム数が多い状態で、メディアの総読み取りスループットを測定してください。デバイスやネットワークの容量を大きく下回っているなら、メディアだけを高速なフラッシュストレージへ移しても、メタデータやデータベースの遅延が解消する可能性は低いでしょう。

アプリデータの書き込みはレイテンシーの影響を受けやすい

データベーストランザクション、アートワークの更新、ログ、メタデータでは、同期処理、ジャーナリング、競合するランダムI/Oを待つ小さな書き込みが発生します。総MB/sが低くても、体感上の影響は大きくなることがあります。

Linuxはダーティページを蓄積してからまとめてフラッシュすることがあるため、遅延書き戻しによって、Plexが書き込んだ瞬間とデバイスにスパイクが現れる瞬間がずれる場合があります。

レイテンシー、キュー深度、ダーティメモリ、アプリデータ用デバイスを、メディア用デバイスとは個別に追跡してください。レイテンシーの高い小規模な書き込みワークロードは、シーケンシャルなメディア読み取りが飽和している場合とは別の問題です。

読み取りと書き込みの同時実行は干渉する可能性がある

データベースの状態、メディア、バックアップ、ダウンローダーを1台のデバイスに集約すると、無関係なアクセスパターンが同じキューを奪い合うことになります。単独では高速なドライブでも、これらの処理が重なると動作が不安定に感じられることがあります。

データベースの性能はストレージ速度だけでなくワークロードの組み合わせによっても変化します。I/Oに敏感なデータベースの挙動があるため、単一ファイルのコピー結果から推測するのではなく、複合ワークロードでテストすることが重要です。

バックアップやメディア管理による書き込みを一時停止し、遅いPlex操作を再実行してください。レイテンシーが大幅に低下するなら、サーバー全体を交換する前に、処理のタイミングまたはストレージの役割を分離しましょう。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

役割を分離するとボトルネックが見える

適切に整理されたトポロジーでは、物理ハードウェアの一部を共有していても、Plexの永続状態、バルクメディア、一時作業、バックアップにそれぞれ異なる性能上および復旧上の役割を持たせられます。これにより、後続のテスト結果を解釈しやすくなります。

役割を分離すると、リソースの飽和が、ストレージ全体ではなく、実際に処理を担っているデバイスや経路に起因するものとして特定しやすくなります。

役割を変更するたびに再テストし、測定したボトルネックを改善した変更だけを残してください。ホームメディアサーバーのトポロジーでは、状態、メディア、一時作業、バックアップを、個別に測定できる程度に分離しておくべきです。