Melacak penggunaan memori "hilang" di linux

Pada kernel Arch 3.6.7 x86_64 saya mencoba untuk menjelaskan penggunaan memori sistem, yang semakin saya melihatnya, semakin banyak tampaknya ada lubang (dalam akuntansi memori yang digunakan, bukan lubang di penggunaan).

Ini adalah sistem yang baru saja di-boot. Dengan tidak banyak menjalankan selain systemd dan sshd untuk membuatnya tetap sederhana

$ 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

Info memori paling detail yang dapat saya temukan adalah ini dari tahun 2007 yang tampaknya telah menghasilkan penambahan bidang Pss ke akuntansi kernel umum untuk suatu proses tetapi kode python mereka adalah untuk kernel yang lebih tua dan sayangnya beberapa file / proc / k * telah menghilang sejak saat itu. The / proc / meminfo dokumentasi juga membantu tetapi penuaan sedikit juga.

Jadi, demonstrasi dari apa yang saya lihat.

# 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

Jika kita menjumlahkan yang digunakan:

MemTotal - MemFree - Buffers - Cached = Used
16345780 - 16129940 - 10360 - 48444 = 157036

Semua * Aktif / Tidak Aktif * tampaknya menjadi counter yang diterapkan pada beberapa halaman (tidak semua) sehingga dapat menduplikasi apa yang dihitung di tempat lain.

Active + Inactive = Used
46724  + 24108    = 70832 (not quite)

Commited_AS di sini tampaknya melacak dengan seksama jumlah userspace privat / memori bersama yang mendiskontokan file bersama dari / proc / * / smaps. mempertimbangkan PSS juga berbaris. (Karena ketertarikan saya mendapatkan Commited_AS jauh lebih besar, jauh lebih besar pada debian 32bit 2.6.32-5-686)

AnonPages + Mapped + Commited_AS = Userspace?
11996     + 16372  + 34304       = 62672

Slab sejalan dengan / proc / slabinfo

Slab +  Shmem + KernelStack + PageTables = Kernelspace?
25092 + 3696  + 928         + 2428       = 32144

Userspace? + Kernelspace? = Used?
62672      + 32144        = 94816

Jadi ~ 63 juta. Itu mengejutkan saya bahwa kernel dan semua modul yang dimuat kekurangan beberapa MB. Slab itu tampaknya mencakup banyak hal, jadi jika ada yang hilang, saya tidak yakin apakah itu sama dengan ~ 60MB?

63 agak dekat dengan angka Aktif + Tidak Aktif tetapi itu terasa tidak benar.

Jadi, adakah yang tahu formula ajaibnya ?? Kalau tidak, jika angka yang saya lihat adalah yang benar, apa area abu-abu dalam alokasi memori yang bisa saya lihat?

Tampaknya linux memakan ram saya! Meskipun porsi lebih kecil dari biasanya dituduh =)

sunting Commited_AS adalah perkiraan dari kernel berapa banyak memori yang diperlukan untuk mencakup 99,9% dari apa yang telah dikomitnya, jadi bukan angka yang dialokasikan secara nyata. AnonPages + Mapped adalah komponennya, sehingga menyisakan lubang yang lebih besar, sekitar 100MB sekarang.

User + Kernel
28368 + 32144 = 60512 != 157036

AnonPages dan dipetakan sebagian besar melacak dengan anon / info dipetakan dari / proc / [0-9] * / smaps wgen mengambil PSS / Dibagikan ke akun.

Area yang dicadangkan tampaknya semuanya masuk ke dalam chunk yang diambil dari total memori:

Total freememori adalah 16345032Kb
Total memori sistem adalah 16777216Kb
PCI 'hole' - lspci -v 266520K = 16510696K
Bios Dicadangkan - dmesg 92793K = 16417903K

sunting2 Saya perhatikan penggunaan memori tambahan ini bukan pada VM yang berjalan di dalam kotak aslinya /proc/meminfo. Jadi saya mulai melihat-lihat apa yang berbeda di antara keduanya. Akhirnya ditemukan bahwa peningkatan total memori fisik yang tersedia bertepatan dengan peningkatan memori yang digunakan.

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

Itu berhasil ~ 8 MB dialokasikan untuk setiap 1GB memori. Mungkin merupakan peta memori di kernel ... tapi saya pikir itu hanya akan tumbuh karena memori dialokasikan daripada setup saat boot.

Akan menarik untuk melihat apakah ada yang punya akses ke mesin bigmem jika tren berlanjut?

"Memori yang digunakan oleh suatu proses" tidakkonsep yang jelas dalam sistem operasi modern. Apa yang dapat diukur adalah ukuran ruang alamat proses (SIZE) dan ukuran yang ditetapkan penduduk (RSS, berapa banyak halaman di ruang alamat yang saat ini ada dalam memori). Bagian dari RSS dibagikan (sebagian besar proses dalam memori berbagi satu salinan glibc, dan untuk berbagai macam perpustakaan bersama lainnya; beberapa proses menjalankan berbagi yang dapat dieksekusi yang sama, proses bercabang berbagi data hanya-baca dan mungkin sepotong belum-dimodifikasi) baca-tulis data dengan orang tua). Di sisi lain, memori yang digunakan untuk proses oleh kernel tidak diperhitungkan, seperti tabel halaman, buffer kernel, dan tumpukan kernel. Dalam keseluruhan gambar Anda harus memperhitungkan memori yang disediakan untuk kartu grafis, penggunaan kernel, dan berbagai "lubang" yang disediakan untuk DOS dan sistem prasejarah lainnya (itu tidak banyak,

Satu-satunya cara untuk mendapatkan gambaran keseluruhan adalah apa yang dilaporkan kernel. Menambahkan angka dengan tumpang tindih yang tidak diketahui dan yang tidak diketahui yang tersisa adalah latihan yang bagus dalam aritmatika, tidak lebih.