質問:nmonまたはvmstatまたは-を使用して、REALメモリ使用量(なしキャッシュ!) svmon AIX 6で?
nmon:
vmstat:
svmon:
Linuxと同様に、freeコマンドを使用できますが、AIXでは使用できません。
[user@notebook ~]$ free -m
total used free shared buffers cached
Mem: 7797 4344 3453 0 219 2745
-/+ buffers/cache: 1379 6417
Swap: 2047 0 2047
[user@notebook ~]$ free -m | grep cache: | awk '{print $3}'
1379
[user@notebook ~]$
ショートバージョン:すべてのファイルキャッシュを知りたい場合は、_svmon -G
_出力の使用中のclnt
+ pers
ページ(単位は4kページ)を確認するか、_vmstat -v
_実行可能ファイル(同じユニット)を除くファイルキャッシュの「ファイルページ」を確認します。
何が起こっているのかについての概要が必要な場合は、次の記事をチェックしてください: AIXページ置換の概要 。
非常に短い要約では、AIXのメモリーは2つの方法で分類されます。
ワーキングメモリvsパーマネントメモリ
作業メモリは、プロセス(スタック、ヒープ、共有メモリ)とカーネルメモリです。その種のメモリをページアウトする必要がある場合は、スワップします。
永久メモリはファイルキャッシュです。ページアウトする必要がある場合は、元のファイルシステムに戻ります(ダーティページの場合、クリーンページはリサイクルされます)。これは、JFSファイルシステムの非クライアント(または永続)ページと、JFS2、NFS、および場合によってはその他のクライアントページに細分されます。
計算ページと非計算ページ。
計算ページは、プロセスデータとカーネルデータに加えて、プロセステキストデータ(つまり、実行可能ファイル/コードをキャッシュするページ)です。
非計算は他のものです:実行可能ではないファイルキャッシュ(または共有ライブラリ)。
_svmon -G
_(ところで、_svmon -G -O unit=MB
_は少し親しみやすい)は、永続的なページと比較して作業量を示します。 work
列は、ワークメモリです。 pers
(JFS)列とclnt
(JFS2)列を合計すると、永続的なメモリが得られます。
あなたのケースでは、ファイルシステム(186151 * 4kページ)に支えられた永続的なページが約730MBあります。
これでtopas
右上の「ウィジェット」FileSystemCache (numperm)
は少し異なるものを示し、_vmstat -v
_で同じデータを取得します。これは非計算永続ページのみです。つまり、上記と同じですが、実行可能ファイルのページを除外します。
あなたの場合、それは約350MB(16Gの2.2%)です。
いずれにせよ、それは実際にはあまりキャッシュではありません。
あなたが探しているコマンド(imho)は次のとおりです。
# svmon -P -O filtertype=working,segment=off,filtercat=exclusive,unit=MB
ここでの主なオプションは次のとおりです。
また、-C(コマンド名関連、以下のいくつかの例)やユーザー関連)などの他のオプションも確認する必要があります。
++++コメントの開始++++
私があなたの質問にコメントとして入力したものを挿入しますが、評判はありません-ここで新しいユーザーとして。
Vmstatの出力は、現在の状況だけではなく、1行の出力であるため、それが履歴であることを教えてくれます。pi/ po(ページングスペースのページング/ページングスペースの履歴)を表示しているため、メモリの問題が発生していると思います。ページアウト)
関心のある他の列は、fr/sr列です。
ここで問題となっているのは、ここに示されているpi/po値であり、他のコマンドからのデータと完全に一致していません。ここでも稼働時間がないため、「テスト」で何がこれらの数値を生成したかを知るのは困難です。
プレゼンテーションでは、pi = 22とpo = 7を示します。これは、平均して、システムがページングスペースから(書き込まれた後)データを書き込むよりも3倍の頻度で情報を読み取っていたことを意味します。これは、データが読み込まれる(pi)後、再度アクセス(sr/fr)される前に再度盗まれる(参照aka used)か、アプリケーションが「待機」する前に再度読み込まれて削除されるため、システムが不足していることを示しています。これにアクセスする機会があります。
要するに、提示されたデータは「痛み」の瞬間と「同期」していません-キャッシュに2.2%のメモリしか使用されていない理由を説明している可能性があります(「計算された、ロードされたプログラム」とも呼ばれます)。
---(vmstatに関する限り、フラグ-I(「fi」と「fo」を追加するcapital:i-fileInとfileOutアクティビティ)と-w(ワイド)を使用して、数値をより適切に配置することもお勧めしますテキストヘッダーの下。
++++「コメント」の終わり
それでは、-P(プロセスビュー)を使用して抜粋を見てみましょう
# svmon -P -O filtertype=working,segment=off,filtercat=exclusive,unit=MB | head -15
Unit: MB
-------------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual
14614630 httpd 21.5 0.06 0 21.5
11272246 httpd 21.4 0.06 0 21.4
12779758 httpd 21.2 0.06 0 21.2
17760476 httpd 20.9 0.06 0 20.9
11796712 httpd 20.8 0.06 0 20.8
17039454 httpd 20.6 0.06 0 20.6
11862240 httpd 20.6 0.06 0 20.6
14680090 httpd 20.5 0.06 0 20.5
10747970 httpd 20.5 0.06 0 20.5
11141286 httpd 20.5 0.06 0 20.5
4718766 mysqld 13.6 0.02 0 13.6
Rootでない場合は、環境内のコマンドのみが表示されます。
$ svmon -P -O filtertype=working,segment=off,filtercat=exclusive,unit=MB
Unit: MB
-------------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual
5505172 svmon 10.7 0.19 0.44 11.4
6553826 ksh 0.57 0.02 0 0.57
9175288 ksh 0.55 0.02 0 0.55
12910710 sshd 0.55 0.02 0 0.55
15204356 sshd 0.52 0.02 0 0.52
12779760 head 0.18 0.02 0 0.18
特定のコマンドを確認したい場合があります。ルートに戻ってhttpdを確認してください。
svmon -C httpd -O filtertype=working,segment=off,filtercat=exclusive,unit=MB
Unit: MB
===============================================================================
Command Inuse Pin Pgsp Virtual
httpd 227.44 0.69 0 227.44
# svmon -C httpd -O filtertype=working,segment=category,filtercat=exclusive,unit=MB >
Unit: MB
===============================================================================
Command Inuse Pin Pgsp Virtual
httpd 230.62 0.81 0 230.62
...............................................................................
EXCLUSIVE segments Inuse Pin Pgsp Virtual
230.62 0.81 0 230.62
Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
81a203 3 work working storage m 24.6 0 0 24.6
parent=883990
8b82d7 3 work working storage m 18.8 0 0 18.8
parent=834226
8b9d37 3 work working storage m 18.2 0 0 18.2
parent=884fb0
8915f2 f work shared library data m 2.00 0 0 2.00
parent=898373
89abb3 f work shared library data m 2.00 0 0 2.00
parent=84b9a9
824ea4 f work shared library data m 2.00 0 0 2.00
これは 'segment = category'をうまく表示しないため、より単純なコマンド-tail-で各メモリの 'segment'タイプの概要と詳細を表示しますが、まだ 'working'メモリのみ(別名:キャッシュなし)
# svmon -C tail -O filtertype=working,segment=category,unit=MB
Unit: MB
===============================================================================
Command Inuse Pin Pgsp Virtual
tail 82.5 52.6 5.12 90.6
...............................................................................
SYSTEM segments Inuse Pin Pgsp Virtual
34.1 33.1 2.38 35.8
Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
10002 0 work kernel segment m 34.1 33.1 2.38 35.8
...............................................................................
EXCLUSIVE segments Inuse Pin Pgsp Virtual
0.18 0.02 0 0.18
Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
88b4f1 f work working storage sm 0.09 0 0 0.09
82d005 2 work process private sm 0.07 0.02 0 0.07
8e0c9c 3 work working storage sm 0.02 0 0 0.02
...............................................................................
SHARED segments Inuse Pin Pgsp Virtual
48.2 19.5 2.75 54.6
Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
9000 d work shared library text m 48.2 19.5 2.75 54.6
nmon次に「m」を押すと、メモリのいくつかの大きな使用法がすぐに表示されます
ipcs -am
DB2やOracleなどの多くのアプリケーションで使用される共有メモリ-ipcs -am
コマンドのサイズをSEGSZで確認します。通常、Owner列は、SGAのOracleユーザーやDB2バッファーキャッシュのdb2inst1などの用途を示します。
それからそれはプロセスにあり、これはトリッキーになります。同じプログラムファイルを実行するすべてのプロセスは、コードページを読み取り専用として共有します。また、プロセスが、たとえばRDBMSやApacheのようなもののように分岐した共通のプロセスによって開始された場合、データおよびsackページの一部またはほぼすべてを共有している可能性があります。これは、プロセスが必要とし、ほとんど私たちには見えない数十のライブラリーにも当てはまります。
この共有が不明なため、すべてのプロセスのすべてのメモリを合計すると、明らかにメモリよりもはるかに大きくなります。
nmon
を使用すると、上位のプロセスには「t」、次にプロセスサイズの順に「4」を使用すると、プロセスメモリが表示されます。