리눅스에서 "누락 된"메모리 사용량 추적

아치 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 필드가 추가되었지만 파이썬 코드는 이전 커널과 불행히도 / 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 비트 데비안 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 수치와 비슷하지만 옳지 않습니다.

누구나 마법의 공식을 알고 있습니까? 그렇지 않으면 내가보고있는 그림이 올바른 것이라면 메모리 할당에서 회색으로 표시된 영역은 무엇입니까?

리눅스가 내 램을 먹은 것 같습니다! 일반적으로 비난되는 것보다 작은 부분이지만 =)

편집 Commited_AS는 그래서 실제 할당 된 번호가 아닙니다, 그것이 최선을 다하고 무슨의 99.9 %를 커버 할 필요가 얼마나 많은 메모리의 커널에서 어디 까지나 추정치 일뿐 정확한 통계입니다. AnonPages + Mapped는 그 구성 요소이므로 지금은 약 100MB의 더 큰 구멍을 남깁니다.

User + Kernel
28368 + 32144 = 60512 != 157036

AnonPages 및 Mapped는 주로 PSS / Shared를 고려하여 / proc / [0-9] * / smaps의 anon / mapped 정보를 추적합니다.

예약 된 영역은 총 메모리에서 제거 된 청크에 모두 맞는 것으로 보입니다.

총 free메모리는 16345032Kb입니다.
총 시스템 메모리는 16777216Kb입니다.
PCI ' lspci -v hole' - 266520K = 16510696K
Bios Reserved- dmesg 92793K = 16417903K

edit2 나는이 여분의 메모리 사용량이 원래 상자 내에서 실행중인 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 머신에 액세스 할 수 있는지 보는 것이 흥미로울까요?

"프로세스에서 사용하는 메모리"가 아닙니다현대 운영 체제의 명확한 개념. 측정 할 수있는 것은 프로세스의 주소 공간 크기 (SIZE)와 상주 집합 크기 (RSS, 주소 공간의 현재 페이지가 메모리에있는 페이지 수)입니다. RSS의 일부 공유 부모와의 읽기-쓰기 데이터). 반면, 커널이 프로세스에 사용하는 메모리는 페이지 테이블, 커널 버퍼 및 커널 스택과 같이 고려되지 않습니다. 전반적인 그림에서 그래픽 카드 용으로 예약 된 메모리, 커널 사용 및 DOS 및 기타 선사 시대 시스템 용으로 예약 된 여러 "구멍"을 고려해야합니다.

전체적인 그림을 얻는 유일한 방법은 커널이보고하는 것입니다. 알 수없는 겹침과 알 수없는 왼쪽이있는 숫자를 더하는 것은 산술에서 좋은 연습입니다.