갈퀴를 꺼내기 전에 Linux 캐시 시스템에 메모리가 들어가는 위치를 추적하는 데 어려움을 겪습니다. 나는 보았다리눅스가 내 RAM을 먹어치워요!, 그리고실제 메모리 사용량을 기준으로 상위 프로세스를 어떻게 확인할 수 있나요?, 그리고Linux에서 메모리 사용량을 올바르게 결정하지만 이를 예로 들면 숫자가 시스템에 표시되는 숫자와 정확히 일치하지 않습니다.
이 시스템을 사용하면 아마도 "캐시"되었거나 프로그램에서 사용된다는 것을 알지만 그 숫자는 나에게 합산되지도 않습니다.
맨 위에서 나는 그것을 보았다.
top - 09:04:09 up 19 days, 20:38, 2 users, load average: 0.00, 0.10, 0.11
Tasks: 160 total, 1 running, 159 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65974296k total, 43507804k used, 22466492k free, 305336k buffers
Swap: 7548924k total, 0k used, 7548924k free, 1480836k cached
알겠습니다. "사용된" 43GB 메모리는 실제로는 실제가 아니며 아마도 대부분이 캐시되어 있을 것입니다. 그래서 그것을 파헤쳐 보았습니다.
$ free -m
total used free shared buffers cached
Mem: 64428 38845 25582 0 298 1445
-/+ buffers/cache: 37101 27326
Swap: 7371 0 7371
따라서 이는 실제로 37GB가 사용되었고 1445MB만 캐시되었음을 보여줍니다(여기서 20000과 유사한 1445가 표시될 것으로 예상됩니다). 위에 링크한 웹사이트를 보면 "캐시" 열이 일반적으로 상당히 높다는 것을 알 수 있습니다. 그래서 나는 어떤 응용 프로그램이 메모리를 사용하고 있는지 확인하기 위해 더 자세히 조사하고 다음을 수행했습니다.
sudo smem -t
PID User Command Swap USS PSS RSS
9468
21475 root python /usr/bin/smem -t 0 6212 6234 6984
2431 root /opt/OV/lbin/perf/coda 0 7156 8060 12068
2213 root /opt/perf/bin/perfd 0 19056 19485 22032
20849 root /opt/shiny-server/ext/node/ 0 77244 77321 78616
21325 atpa /usr/lib64/R/bin/exec/R --n 0 3729836 3733774 3739520
21287 atpa /usr/lib64/R/bin/exec/R --n 0 4060136 4064074 4069820
-------------------------------------------------------------------------------
63 11
0 7947984 7970344 8054032
따라서 R의 두 응용 프로그램은 약 8GB의 메모리를 사용합니다.
위에 링크한 다른 기사에서는 Linux가 메모리를 "예약"하고 캐시에 보관하고 있음을 보여줍니다(예: free -m은 캐시가 "Mem:" 줄에서 높은 값을 가지고 있음을 보여줍니다). 반면 제 경우에는 실제로 그렇게 보입니다. 사용 중이지만 실제로 메모리 사용량을 보고하는 응용 프로그램이 없으며 Linux가 메모리를 사용(캐싱/예약?)하는 위치를 추적할 수 없는 것 같습니다.
이 기억은 어디로 갔나요? Linux에서 사용하고 있다고 가정하지만 어디에 있는지 알 수 없습니다.
/proc/meminfo
프로그램
MemTotal: 65974296 kB
MemFree: 24191624 kB
Buffers: 305320 kB
Cached: 1480760 kB
SwapCached: 0 kB
Active: 7769776 kB
Inactive: 215532 kB
Active(anon): 6199392 kB
Inactive(anon): 476 kB
Active(file): 1570384 kB
Inactive(file): 215056 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 7548924 kB
SwapFree: 7548924 kB
Dirty: 116 kB
Writeback: 0 kB
AnonPages: 6172696 kB
Mapped: 47400 kB
Shmem: 652 kB
Slab: 255468 kB
SReclaimable: 225620 kB
SUnreclaim: 29848 kB
KernelStack: 1736 kB
PageTables: 18780 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 40536072 kB
Committed_AS: 6455352 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 247288 kB
VmallocChunk: 34359487760 kB
HardwareCorrupted: 0 kB
AnonHugePages: 2586624 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 10240 kB
DirectMap2M: 67098624 kB
답변1
제 문제를 찾은 것 같아요...
내 문제는 VMware의 메모리 팽창 시스템인 것 같습니다. 기본적으로 이는 호스트 시스템이 게스트 운영 체제에 메모리 압력을 가하여 다른 호스트가 많은 메모리를 사용하기 시작할 때 게스트 메모리 할당량을 소비하는 방법입니다.
http://www.vfrank.org/2013/09/18/understanding-vmware-ballooning/
VMware를 사용하는 경우 다음 명령을 실행하십시오.
vmware-toolbox-cmd stat balloon
이것은 부풀어 오른 메모리 양을 보여줍니다.
나를 위한
#:vmware-toolbox-cmd stat balloon
32425 MB
다른 출처:https://serverfault.com/questions/660080/Detect-memory-ballooning-from-within-the-affected-vm
문제를 확인하려면 팽창된 메모리를 끄십시오.
비대화 메모리:https://serverfault.com/questions/528295/unballooning-ram-thats-been-ballooned-by-vmware