Linuxでの「不足している」メモリ使用量の追跡
Arch 3.6.7 x86_64カーネルでは、システムのメモリ使用量を説明しようとしています。これを見ると、（使用されたメモリの計算では、非ホールに）穴があるように見えます。の使用法）。
これは、新しく起動したシステムです。 systemdとsshd以外はあまり実行せず、シンプルに保つ
$ ps aux | sort -n -k6
...
root 316 0.0 0.0 7884 812 tty1 Ss+ 14:37 0:00 /sbin/agetty --noclear tty1 38400
matt 682 0.0 0.0 24528 820 pts/0 S+ 15:09 0:00 sort -n -k6
dbus 309 0.0 0.0 17280 1284 ? Ss 14:37 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
matt 681 0.0 0.0 10808 1364 pts/0 R+ 15:09 0:00 ps aux
root 308 0.0 0.0 26060 1516 ? Ss 14:37 0:00 /usr/lib/systemd/systemd-logind
root 148 0.0 0.0 25972 1692 ? Ss 14:37 0:00 /usr/lib/systemd/systemd-udevd
matt 451 0.0 0.0 78180 2008 ? S 14:37 0:00 sshd: matt@pts/0
root 288 0.0 0.0 39612 2708 ? Ss 14:37 0:00 /usr/sbin/sshd -D
matt 452 0.0 0.0 16452 3248 pts/0 Ss 14:37 0:00 -bash
root 1 0.0 0.0 32572 3268 ? Ss 14:37 0:00 /sbin/init
root 299 0.0 0.0 69352 3604 ? Ss 14:37 0:00 /usr/sbin/syslog-ng -F
root 449 0.0 0.0 78040 3800 ? Ss 14:37 0:00 sshd: matt [priv]
root 161 0.0 0.0 358384 9656 ? Ss 14:37 0:00 /usr/lib/systemd/systemd-journald
私が見つけることができる最も詳細なメモリ情報は this であり、プロセスを説明する一般的なカーネルにPssフィールドが追加されたようですが、pythonコードは古いカーネル用であり、残念ながら/ proc/k *ファイルの一部はそれ以降姿を消しています / proc/meminfo のドキュメントも役に立ちますが、少し古くなっています。
それで、私が見ているもののデモンストレーションです。
# cat /proc/meminfo
MemTotal: 16345780 kB
MemFree: 16129940 kB
Buffers: 10360 kB
Cached: 48444 kB
SwapCached: 0 kB
Active: 24108 kB
Inactive: 46724 kB
Active(anon): 12104 kB
Inactive(anon): 3616 kB
Active(file): 12004 kB
Inactive(file): 43108 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 11996 kB
Mapped: 16372 kB
Shmem: 3696 kB
Slab: 25092 kB
SReclaimable: 11716 kB
SUnreclaim: 13376 kB
KernelStack: 928 kB
PageTables: 2428 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8172888 kB
Committed_AS: 34304 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 372788 kB
VmallocChunk: 34359362043 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 12288 kB
DirectMap2M: 16680960 kB
中古品を合算すると：
MemTotal - MemFree - Buffers - Cached = Used
16345780 - 16129940 - 10360 - 48444 = 157036
すべてのActive */Inactive *は一部のページ（すべてではない）に適用されるカウンターのように見えるため、他の場所でカウントされるものと重複する可能性があります。
Active + Inactive = Used
46724 + 24108 = 70832 (not quite)
ここでのCommited_ASは、/ proc/*/smapsからのユーザースペースのプライベート/共有メモリ割引共有ファイルの合計に密接に追跡しているようです。 PSSを使用 も考慮に入れられます。 （興味がないので、32ビットdebian 2.6.32-5-686ではるかに大きなCommited_ASを取得します）
AnonPages + Mapped + Commited_AS = Userspace?
11996 + 16372 + 34304 = 62672
スラブは/ proc/slabinfoとインラインです
Slab + Shmem + KernelStack + PageTables = Kernelspace?
25092 + 3696 + 928 + 2428 = 32144
Userspace? + Kernelspace? = Used?
62672 + 32144 = 94816
だから〜63M短い。カーネルとロードされたすべてのモジュールにいくつかのMBが不足していることに私は気付きました。しかし、スラブはたくさんカバーしているようですので、欠けているものがあれば、それが〜60Mbに相当するかどうかはわかりませんか？
63はアクティブ+非アクティブの数値に少し近いですが、それは正しくありません。
だから誰も魔法の数式を知っていますか？そうでなければ、私が見ている数字が正しいものである場合、メモリ割り当ての中で私が突き刺すことができる灰色の領域は何ですか？
Linuxが私のRAMを食べたようです！通常非難されているよりも小さい部分です=）
editCommited_ASは、カーネルがコミットしたものの99.9％をカバーするために必要なメモリ量の推定値であるため、実際には割り当てられていません数。 AnonPages + Mappedはそのコンポーネントであるため、現在は約100MBの大きな穴が残っています。
User + Kernel
28368 + 32144 = 60512 != 157036
AnonPagesとMappedは、PSS/Sharedを考慮に入れて/ proc/[0-9] */smaps wgenからのanon/mapped情報で主に追跡します。
予約された領域はすべて、総メモリから取り出されたチャンクに収まるように見えます
freeメモリの合計は16345032Kbです
システムメモリの合計は16777216Kbです
PCI「穴」-lspci -v 266520K = 16510696K
Bios予約済み-dmesg 92793K = 16417903K
edit2この余分なメモリ使用量は、/proc/meminfoの元のボックス内で実行されているVMのメモリ使用量ではないことに気付きました。それで、私は2つの違いが何であるかを見て回り始めました。最終的に、使用可能な総物理メモリの増加は、使用済みメモリの増加と一致することがわかりました。
phys 16GB used>144508 vm>50692 user>21500 kern>26428 u+ktot>47928
vm 64MB used>24612 vm>31140 user>14956 kern>14440 u+ktot>29396
vm 256MB used>26316 vm>35260 user>14752 kern>14780 u+ktot>29532
vm 1GB used>33644 vm>35224 user>14936 kern>14772 u+ktot>29708
vm 2GB used>41592 vm>35048 user>14736 kern>15056 u+ktot>29792
vm 4GB used>57820 vm>35232 user>14780 kern>14952 u+ktot>29732
vm 8GB used>82932 vm>36912 user>15700 kern>15388 u+ktot>31088
vm 12GB used>110072 vm>35248 user>14812 kern>15624 u+ktot>30436
vm 15GB used>122012 vm>35424 user>14832 kern>15824 u+ktot>30656
これは、1GBのメモリごとに最大8Mbが割り当てられることになります。カーネル内のメモリマップである可能性があります...しかし、起動時にセットアップされるのではなく、メモリが割り当てられると、それだけが大きくなると思いました。
トレンドが続く場合、誰かがbigmemマシンにアクセスできるかどうかを確認するのは興味深いでしょうか？
「プロセスが使用するメモリ」はnotが最新のオペレーティングシステムの明確な概念です。測定できるのは、プロセスのアドレススペースのサイズ（SIZE）と常駐セットサイズ（RSS、アドレススペース内の現在のメモリ内のページ数）です。 RSSの一部が共有されます（メモリ内のほとんどのプロセスがglibcの1つのコピーを共有するため、他のさまざまな共有ライブラリの場合は、同じ実行可能ファイルを実行している複数のプロセスが共有し、フォークされたプロセスは読み取り専用データを共有し、変更されていない可能性があります親とのデータの読み書き）。一方、ページテーブル、カーネルバッファ、カーネルスタックなど、カーネルがプロセスに使用するメモリは考慮されません。全体像では、グラフィックスカード用に確保されたメモリ、カーネルの使用、およびDOSやその他の先史時代のシステム用に確保されたさまざまな「穴」を説明する必要があります（とにかく多くはありません）。
全体像を把握する唯一の方法は、カーネルがそのように報告することです。未知のオーバーラップと未知の除外された数値を合計することは、算術の素晴らしい練習であり、それ以上はありません。