Linux的RAM高使用率未知


9

在搜寻了此内容并仅找到无法正确解释“已缓存”数字的人员的帖子之后,我决定提出此问题。

我手头有一些服务器,它们的行为很奇怪。即,它们的RAM使用率很高,没有明显的原因。似乎不可见的进程有很多“已用” RAM(我的意思是“已用”)。

这是一些信息:

  • 所有服务器都运行SLES 11
  • 内核是3.0.76
  • 所有服务器均在VMWare ESX基础架构下作为来宾运行
  • 我尚未设置服务器,也没有在操作系统选择方面发表意见,也无法访问虚拟化基础架构
  • 所有服务器的设置都类似,并且它们确实运行相同的软件集(这是一个集群,是的,我知道,虚拟集群yada yada,就像我所说的那样:

和一些shell输出:

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内存的总数与“ used- free -m/ + buffers / cache”值的输出大致相符-这就是您所期望的,对?

现在看一下坏的服务器:free -m“ used-/ + buffers / cache”值的输出大约是您期望的3倍,总结所有ps可以显示的内容。

这也/proc/meminfo告诉我。

到目前为止,我什至不知道那怎么可能。这可能是怎么回事?


/proc/meminfo您声称的两个输出都适用于好的服务器?您还能提供错误的服务器参考吗?
马修·伊夫,2015年

您是否可以访问VMware vSphere控制台或Virtual Center?或以任何方式查看与来宾记忆有关的几件事?
ewwhite

请发布/ proc / zoneinfo的输出
Matthew Ife 2015年

@ewwhite不,不幸的是,我绝对不能访问操作系统以外的任何东西。
luxifer

@MatthewIfe meminfo标签是一个错字-已更正...现在提取zoneinfo内容
luxifer

Answers:


12

我认为您可能遇到VMware内存膨胀问题。vSphere基础架构中的内存过量使用可能会太高。如果无法访问vSphere vCenter,将无法修复此问题,但是,如果已安装vmtools,则应该能够从虚拟机中检测到此问题:

你能发布输出vmware-toolbox-cmd stat balloon吗?

另外,您还分配了16GB的RAM。请询问任何人在基础设施的控制权,如果有问题放置在虚拟机上的任何手动RAM的限制。


阅读了气球在vmware linux vms上的工作原理后,我认为这是原因。我很不为所动,但是他们并没有从VM方面为“已用”页面提供解决方案。
马修·伊夫

1
我认为这确实是正确的...好的服务器显示“ o MB” ...坏服务器显示“ 10092 MB”,这与我们看到的内容基本一致!
luxifer

@luxifer所以现在你们必须修复它。这意味着删除虚拟机上的人为RAM限制或vMotioning到另一台ESXi主机。请您的VMware基础架构团队查看这是否是更普遍的问题
ewwhite

@ewwhite我一定会通知他们。但是,这是我们一位客户的基础架构,通常他们应该已经确定了这一点。不幸的是,这并不是大型的IT服务提供商在起作用;)
luxifer

@luxifer认真地说,我发现这可能发生在各种组织中,负责管理vSphere基础架构的人员似乎没有意识到这一点。
ewwhite
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.