他の人が正しく指摘しているように、プロセスが使用する実際のメモリ、共有領域のあるもの、mmapされたファイルなどを把握するのは困難です。
あなたが実験者なら、valgrindとmassifを実行できます。これは、カジュアルなユーザーにとっては少し重くなるかもしれませんが、時間の経過に伴うアプリケーションのメモリの振る舞いを知ることができます。アプリケーションのmalloc（）がまさに必要なものである場合、これによりプロセスの実際の動的メモリ使用量を適切に表すことができます。しかし、この実験は「中毒」になる可能性があります。
問題を複雑にするために、Linuxではメモリをオーバーコミットできます。メモリをmalloc（）すると、メモリを消費する意図が表明されます。しかし、割り当てられた「RAM」の新しいページにバイトを書き込むまで、割り当ては実際には起こりません。次のような小さなCプログラムを作成して実行することで、これを自分で証明できます。
// test.c
#include <malloc.h>
#include <stdio.h>
#include <unistd.h>
int main() {
void *p;
sleep(5)
p = malloc(16ULL*1024*1024*1024);
printf("p = %p\n", p);
sleep(30);
return 0;
}
# Shell:
cc test.c -o test && ./test &
top -p $!
16GB未満のRAMを搭載したマシンでこれを実行すると、16GBのメモリを獲得しました！（いいえ、そうではありません）。
top「VIRT」は16.004Gと表示されますが、％MEMは0.0 であることに注意してください。
valgrindでこれを再度実行します。
# Shell:
valgrind --tool=massif ./test &
sleep 36
ms_print massif.out.$! | head -n 30
そして、massifは「すべてのallocs（）の合計= 16GB」と言います。だからそれはあまり面白くない。
ただし、正常なプロセスで実行する場合：
# Shell:
rm test test.o
valgrind --tool=massif cc test.c -o test &
sleep 3
ms_print massif.out.$! | head -n 30
--------------------------------------------------------------------------------
Command: cc test.c -o test
Massif arguments: (none)
ms_print arguments: massif.out.23988
--------------------------------------------------------------------------------
KB
77.33^ :
| #:
| :@::@:#:
| :::::@@::@:#:
| @:: :::@@::@:#:
| ::::@:: :::@@::@:#:
| ::@:::@:::::@:: :::@@::@:#:
| @::@:::@:::::@:: :::@@::@:#:
| @::@:::@:::::@:: :::@@::@:#:
| :@@@@@@@@@@@@@@@@@@@@:@::@:::@:::::@:: :::@@::@:#:
| :@@ :@::@:::@:::::@:: :::@@::@:#:
| :@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| :::::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| ::::::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
| ::::::::@::::@@:@@ :@::@:::@:::::@:: :::@@::@:#:
0 +----------------------------------------------------------------------->Mi
0 1.140
そして、ここでは、コンパイラーが77KBのヒープを割り当てていることがわかります（非常に経験的に、非常に高い信頼性で）。
なぜヒープ使用量を取得するために一生懸命努力するのですか プロセスが使用するすべての共有オブジェクトとテキストセクション（この例ではコンパイラー）はそれほど興味深いものではないためです。それらはプロセスの一定のオーバーヘッドです。実際、プロセスの後続の呼び出しはほとんど「無料」で行われます。
また、以下を比較対照します。
MMAP（）1GBファイル。VMSizeは1 + GBです。ただし、Resident Set Sizeは、（その領域へのポインターを逆参照することにより）ページングされる原因となったファイルの部分のみです。そして、ファイル全体を「読む」場合、最後に到達するまでに、カーネルはすでにページの先頭をページアウトしている可能性があります（これは簡単に行うことができます。 ）。どちらの場合でも、VMSizeもRSSもメモリの「使用量」の良い指標ではありません。実際にmalloc（）したものはありません。
対照的に、Malloc（）とメモリの多くに触れる-メモリがディスクにスワップされるまで。したがって、割り当てられたメモリはRSSを超えています。ここで、VMSizeが何かを伝え始めるかもしれません（プロセスは実際にRAMにあるメモリよりも多くのメモリを所有しています）。しかし、共有ページであるVMとスワップされたデータであるVMを区別することは依然として困難です。
これは、valgrind / massifが興味深いところです。（ページの状態に関係なく）意図的に割り当てたものを表示します。
htop...私は他の日だった1つの同様の質問には、著者を（htopのような）は/ proc / meminfoのからメモリ使用量を計算する方法