なぜ処理完了後もPlexのメモリ使用量が高いままなのですか？

タスクが完了した後もPlexのメモリ使用量が高いままになることがあります。これは、Linuxが再利用可能なファイルシステムキャッシュを保持し、アプリケーションが後続の処理に備えて確保したメモリを保持するためです。

「使用中」のメモリが多いからといって、必ずしもメモリリークとは限りません。プロセスの常駐メモリ、回収可能なキャッシュ、スワップの圧迫状況、そして別のワークロードがメモリを必要としたときにホストがメモリを解放できるかを比較してください。フットプリントが繰り返しのサイクルを通じて増え続ける、または実際の圧迫や不安定さを引き起こす場合にのみ調査します。

プロセスメモリとファイルシステムキャッシュを分けて考える

Linuxは、空いているRAMをファイルやデータベースページのキャッシュに使用するため、スキャンや再生の後に空きメモリの数値が少なく見えることがあります。回収可能なキャッシュは、回収不能なアプリケーションのメモリ増加とは異なります。

使用中のRAMだけでは、リークを判断する指標として不十分です。Linuxのキャッシュとアプリケーションメモリは、メモリがまだ回収可能な場合でも高いままになることがあるためです。

ワークロードの前後で、PlexのRSS、ホストのキャッシュ、利用可能なメモリ、スワップを記録してください。利用可能なメモリが健全な状態に保たれているなら、空きメモリの欄を最大化するためだけに調整する必要はありません。

ジョブ終了後もウォームキャッシュが役立つ場合がある

メタデータやデータベースページをメモリ上に保持すると、後続のブラウジングが高速になることがあります。キャッシュはすぐにゼロへ戻るかではなく、圧迫時にカーネルが回収できるかで判断してください。

キャッシュされたページは、競合する需要によって価値が変わるまで有用な状態で保持されることがあります。これは通常のLinuxのページキャッシュ動作に沿ったものです。

メモリを消費するワークロードを制御して開始し、スワップやプロセスの強制終了が発生する前にキャッシュが縮小するか観察してください。正常に回収できるなら、キャッシュが原因だという説明を裏付けられます。

繰り返しのサイクルで増加しているか確認する

実際のリークは通常、同じワークロードを完了するたびにプロセスのフットプリントが上昇し続け、安定しない形で現れます。大規模なスキャンの後に高い水準で一度安定しただけでは、十分な証拠になりません。

複数の同一サイクルにわたって使用率と飽和度を追跡し、メモリの圧迫が単一のスナップショットではなく、再現可能なワークロードに結び付いているか確認してください。

同じライブラリタスクを3回実行し、それぞれが安定した後のPlex RSSを記録してください。安定後のベースラインが上昇し続ける、またはホストの回収性能が低下し始めた場合にのみ、詳しい調査へ進みます。ページキャッシュ、関連サービス、ストレージの動作によって健全な安定時のベースラインが変わる可能性があるため、ホームメディアサーバーの構成全体の中でメモリを評価してください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

共有コンテナによって解釈が変わる場合がある

別のサービスがキャッシュを消費したりスワップを発生させたりすると、ホスト全体のメモリ問題の原因がPlexであるように見えることがあります。Plexの上限を低く設定する前に、マシン全体を確認してください。

複数サービスを実行するホストでは、プロセスが分離されていても、同じ物理メモリをめぐる共有コンテナ依存関係が生じます。

最大の関連コンテナを一時停止した状態でワークロードを再実行してください。メモリの圧迫が解消されるなら、Plex自体を変更する前に、共有ホストのメモリ予算を調整します。