Linuxで「失われた」メモリ使用量を追跡する

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

私が見つけることができる最も詳細なメモリ情報は次のとおりです。これこれにより、2007年からプロセスの共通カーネルアカウントにPssフィールドが追加されたように見えますが、Pythonコードは以前のカーネル用であり、残念ながらそれ以降/ proc / k *ファイルの一部が消えました。これ/proc/メモリ情報文書も役に立ちますが、少し古いです。

ここに私が見たデモがあります。

# 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 = Used
46724  + 24108    = 70832 (not quite)

ここで、Committed_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はActive + Inactiveの数字にやや近いですが、それほど正しいとは感じません。

それでは、この魔法の公式を知っている人はいますか?そうではなく、私が見ている図が正しい場合に調べることができるメモリ割り当てのグレー領域は何ですか?

Linuxが私のメモリを捕まえたと思います!一般的に請求されるよりも少ない割合ですが=)

編集するCommitted_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

編集2 私はもともとボックス内で実行されているVMにはこれらの追加のメモリ使用量がないことを発見しました/proc/meminfo。それで、違いが何であるかを見始めました。最後に、使用可能な物理メモリ全体の増加は、使用されたメモリの増加と一致することがわかりました。

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マシンにアクセスできるかどうかを調べるのは興味深いでしょうか?

ベストアンサー1

「プロセスで使用するメモリ」は、いいえ最新のオペレーティングシステムの明確な概念。測定できるのは、プロセスのアドレス空間サイズ(SIZE)と常駐セットサイズ(RSS、現在メモリにあるアドレス空間のページ数)です。 RSSの一部は共有されます(メモリ内のほとんどのプロセスはさまざまな共有ライブラリだけでなくglibcのコピーも共有します。同じ実行ファイルを実行する複数のプロセスはRSSを共有し、フォークされたプロセスは読み取り専用データを共有します。するなど)。まだ変更されていないデータ(親データの読み取りと書き込み)の一方、ページテーブル、カーネルバッファ、カーネルスタックなど、カーネルがプロセスに使用するメモリは考慮されません。全体的な図では、グラフィックカード用に予約されているメモリ、カーネル使用、DOSなどの先史時代システム用に予約されているさまざまな「穴」(とにかく多くはありません)を考慮する必要があります。

全体像を得る唯一の方法はカーネルが報告することです。未知の重複と未知の欠落の数を追加するのは良い算術練習です。

おすすめ記事