알 수없는 이유로 Linux 높은 RAM 사용량


9

이것을 둘러보고 "캐시 된"그림을 제대로 이해하지 못하는 사람들의 게시물 만 찾은 후에이 질문을하기로 결정했습니다.

이상한 서버가 있습니다. 즉, 명백한 이유없이 RAM 사용량이 매우 높습니다. 보이지 않는 프로세스에 많은 "사용 된"RAM이있는 것 같습니다 (그리고 "사용 된"을 의미합니다).

여기 몇 가지 정보가 있습니다 :

  • 모든 서버가 SLES 11을 실행
  • 커널은 3.0.76입니다
  • 모든 서버는 VMWare ESX 인프라에서 게스트로 실행
  • 서버를 설정하지 않았으며 OS 선택에 대한 언급이 없었으며 가상화 인프라에 액세스 할 수 없습니다
  • 모든 서버가 비슷하게 설정되고 동일한 소프트웨어 세트를 실행합니다 (클러스터입니다. 예 : 가상화 클러스터, 야다 야다 : 말했듯이 말하지 않았습니다)

그리고 일부 셸 출력 :

root@good-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      14780       1173          0        737       8982
-/+ buffers/cache:       5059      10894
Swap:        31731          0      31731

root@good-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.7 GiB
=================================

root@bad-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      15830        123          0        124       1335
-/+ buffers/cache:      14370       1583
Swap:        31731         15      31716

root@bad-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.0 GiB
=================================

양호한 서버의 / proc / meminfo 내용

MemTotal:       16336860 kB
MemFree:          112356 kB
Buffers:          138384 kB
Cached:          1145208 kB
SwapCached:         1244 kB
Active:          4344336 kB
Inactive:        1028744 kB
Active(anon):    3706796 kB
Inactive(anon):   382724 kB
Active(file):     637540 kB
Inactive(file):   646020 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32477728 kB
Dirty:              1248 kB
Writeback:             0 kB
AnonPages:       4087776 kB
Mapped:            60132 kB
Shmem:               156 kB
Slab:             274968 kB
SReclaimable:     225864 kB
SUnreclaim:        49104 kB
KernelStack:        4352 kB
PageTables:        16400 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6576912 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359418748 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       73728 kB
DirectMap2M:    16703488 kB

불량 서버의 / proc / meminfo 내용

MemTotal:       16336860 kB
MemFree:         1182320 kB
Buffers:          756244 kB
Cached:          8695688 kB
SwapCached:            0 kB
Active:         13499680 kB
Inactive:         843208 kB
Active(anon):    4853460 kB
Inactive(anon):    37372 kB
Active(file):    8646220 kB
Inactive(file):   805836 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32493560 kB
Dirty:              1268 kB
Writeback:             0 kB
AnonPages:       4890180 kB
Mapped:            84672 kB
Shmem:               252 kB
Slab:             586084 kB
SReclaimable:     503716 kB
SUnreclaim:        82368 kB
KernelStack:        5176 kB
PageTables:        19684 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6794180 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359419468 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      112640 kB
DirectMap2M:    16664576 kB

TL; DR-이들을 나란히 비교하면 주요 차이점은 다음과 같습니다 (BADserver-GOODserver).

MemFree       -1070 MB
Cached        -7550 MB
Active        -9155 MB
Active(anon)  -1147 MB
Active(file)  -8009 MB
AnonPages     - 802 MB

다른 차이점은 다소 작으며 예상 한도 내에서 (그러나 직접 볼 수 있음)

보다시피, 양호한 서버에서 모든 프로세스의 모든 RES 및 SHR 메모리의 총계는 free -m"사용 된-/ + 버퍼 / 캐시"값에 대한 출력 과 거의 일치합니다. ?

나쁜 서버를 보자. free -m"used-/ + buffers / cache"값에 대한 출력은 예상보다 약 3 배 높으며, 모든 것을 요약 할 수있다 ps.

이것은 또한 /proc/meminfo나에게 말하는 것과 일치 합니다.

지금까지 나는 그것이 어떻게 가능한지 전혀 모른다. 여기서 무슨 일이 일어나고 있습니까?


/proc/meminfo당신의 두 출력은 모두 좋은 서버를위한 것이라고 주장합니까? 잘못된 서버 참조도 제공 할 수 있습니까?
Matthew Ife

VMware vSphere 콘솔 또는 Virtual Center에 액세스 할 수 있습니까? 아니면 게스트 메모리와 관련된 몇 가지를 볼 수있는 방법이 있습니까?
ewwhite

/ proc / zoneinfo의 출력을 게시하십시오
Matthew Ife

@ewwhite 아니오, 불행히도 나는 운영 체제 자체 이외의 것에 액세스 할 수 없습니다.
luxifer

@MatthewIfe meminfo 라벨이 오타 인 경우-수정했습니다 ... 이제 zoneinfo 컨텐츠를
가져옵니다

답변:


12

VMware 메모리 벌룬 문제 가있을 수 있습니다 . vSphere 인프라에서 메모리 초과 커밋이 너무 높을 수 있습니다. vSphere vCenter에 액세스하지 않고는이를 해결할 수 없지만 vmtools가 설치되어 있다고 가정하면 가상 머신 내에서이를 감지 할 수 있어야합니다.

당신은 출력을 게시 할 수 있습니까 vmware-toolbox-cmd stat balloon?

또한 16GB의 RAM이 할당되었습니다. 누구에게나 문의 해주십시오 문제의 가상 머신에 배치 수동 RAM 한계가있는 경우 인프라의 제어.


vmware Linux vms에서 풍선 도움말이 작동하는 방식을 읽은 것은 이것이 원인이라고 생각합니다. 나는 그들이 '사용 된'페이지를 설명하기 위해 VM 측에서 방법을 제공하지 않는 것에 대해 매우 인상적입니다.
Matthew Ife

1
이것이 사실이라고 생각합니다 ... 좋은 서버는 "o MB"를 보여줍니다 ... 나쁜 서버는 "10092 MB"를 보여줍니다.
luxifer

@luxifer 이제 여러분은 고쳐야합니다 . 이는 VM에서 인공 RAM 제한을 제거하거나 다른 ESXi 호스트로 vMotioning을 제거하는 것을 의미합니다. 이 문제더 광범위한 문제 인지 VMware 인프라 팀에 문의하십시오 .
ewwhite

@ewwhite 확실히 알려 드리겠습니다. 그러나 이는 고객 중 하나의 인프라이며 일반적으로 고객이이를 식별해야합니다. 불행히도 전 세계 IT 서비스 제공 업체의 규모는 그리 크지 않습니다.)
luxifer

@luxifer 진심으로, 이것은 모든 종류의 조직 에서 발생할 수 있으며 vSphere 인프라 관리 업무를 수행하는 사람들은이를 깨닫지 못하는 것 같습니다.
ewwhite
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.