topの出力を見てみましたが、次のような結果が私に表示されました（そして他のプロセス）。
ご覧のとおり、10個のプロセスがあり、各プロセスは約10GBを消費するため、合計100GBになります。ただし、上部の2行目に示すように、コンピュータには64 GBのRAMしかありません。現在、約22GBが使用されています。
これで問題は、test_mpi.outプロセスが互いに多くの共有メモリを使用していることです。ソースコードがあり、実際のメモリ使用量は10GB程度になることがわかっています。
コンピュータはアイドル状態で約12 GBのメモリを消費するため、報告された合計メモリは22 GBです。
私が理解していないのは、実際には22 GBのメモリしか使用されていないことをtopがどのように知っているかです。これは、表示されているすべての列（VIRT、RES、およびSHR）に基づいて一番上で明確ではないはずです。誰かがこれについて明らかにすることができれば良いでしょう。
編集：Redhat Linuxで実行中
編集：Michael Homerのおかげで、topが/ proc / meminfoからこの情報を取得することがわかりました。しかし、私はすべてのtest_mpi.outプロセスが合計10 GBしか消費しないことをどのように決定したかを説明する答えをしたいと思います（トップの出力を追加して提案された100 GBの代わりに）。 /proc/PID/statusを見てみましたが、大きなメモリセグメントを共有する複数のプロセスの実際のメモリ使用量を確認する方法に関する手がかりが見つかりませんでした（ソースコードがない場合）。
ベストアンサー1
SHRこの列に表示されているメモリ量が等しいことがわかりますRES。これは、この特定のタスクの常駐メモリが実際に100％共有メモリセグメントで構成されていることを意味します。しかし、それにもかかわらず、RESページアウトされていないメモリ量がどれくらいになるかはよくわかりません。
プロセスの実際のメモリ消費量を把握するには、選択フィールドの使用など、より賢明なアプローチを試してください（オプションとマニュアルのセクションを参照ps(1)）。-oSTANDARD FORMAT SPECIFIERS
フィールド（非常におおよその見積もり）を除いて、sizeメモリ側でプロセスの全体的なサイズを液面のまま正確に評価することは困難です。メモリの一部が他のプロセスと共有される可能性があり、これがわからないためです。どのくらいのページがダーティであるかを直接知ることができます（NOTESマンページの段落とそのセクションのマンページを参照）。SIZERSS
実際にどのプロセスを使用しているかがわかります。同じipcs(1)共有メモリセグメントの場合は、コマンドの出力を調べて、nattchどの共有メモリセグメントに疑わしい数のプロセスがあるかを確認する必要があります。
その後、そのセグメントの詳細を確認する必要があり、ipcs -m -i <id>ここにリンクされている実際のプロセスが表示されます。
これが複雑すぎると思われる場合は、挑戦的な課題と考えてください。プロセスIDが与えられたら、そのプロセスに関連付けられたSHM IDのリストと、そのSHM IDを共有するPIDのリストを印刷するスクリプトを作成します。 ;)