it-swarm-ja.com

失われた物理メモリの特定

サーバーの物理メモリが不足しているという問題があり、それがアプリケーションのJavaプロセスからのものか、サーバー上の他の何かからのものか」を識別するのに問題があります。次のシナリオを考えてみましょう。

サーバーの物理メモリ:3747MB
Java -Xms64m
Java -Xmx512m
Java XX:MaxPermSize = 512m

サーバーを起動すると、OS(RHEL)は、お気に入りのメモリレポートツール(top, cat /proc/meminfo | grep Mem, free -mなど)を使用して、487MBが使用されていることを報告します。 Javaプロセス(pid 123)を開始すると、約215MBの物理メモリが使用され(ps -f -p 123のRESメモリで報告されています)、合計使用メモリが最大約700MBになります。 。

1日中実行すると、プロセスのRESメモリは少し変動しますが、通常は一貫しています。ただし、サーバーの合計メモリは約1500MBで着実に増加し、合計で2200MBになりました。

私のJavaヒープサイズまたはpermgenヒープが大きくなっている場合、それはプロセスのRESメモリに反映されませんか?

また、私はその余分な1500MBをどこにも説明できないようです。

# ps aux | awk '{ RES+=$6 } END { printf("RES: %.2fMB\n", RES/1024) }'
RES: 722.23MB

誰かが私がその失われた記憶を見つけるのを手伝ってくれる?私は基本的に、これが私のアプリケーションの問題なのか、インフラストラクチャチームのサーバービルドの問題なのかを理解しようとしています。

7
schmimd04

Linuxは再利用のポリシーを使用しますが、最近使用したメモリを「本当に無料」としてマークしません(スクラブには手間がかかり、誰かが再び使用する場合に備えてものを残しておくと、費用がかからず、バンドルを節約できる可能性があります)。 「空きメモリ」レポートについて心配する必要はありません。使用されているスワップの量(ある場合)を確認します(スワップは基本的に、物理メモリを実際にオーバーフローさせるメモリ要件のためのディスクスペースです。ディスクは非常に遅いので、必要ありません)。パフォーマンスが心配な場合は、悪名高いsar( sysstat 、確かにシステム用のパッケージがあります)などの監視ソフトウェアをインストールして構成すると、後で確認できるように、何が起こっているかが詳細に記録されます。上記のレポートが手元にあれば、(もしあれば)あなたのボトルネックが何であるかがわかります。 「時期尚早の最適化はすべての悪の根源である」という言い回しは、人々が悪名高い実際のパフォーマンスの問題がどこにあるかを推測するのが苦手であり、「修正」を終了するためです。 「完全に正常に機能しているもの。

1
vonbrand