我的RAM到哪里去了&如何解释atop的内存输出？
我的RAM到哪里去了&如何解释atop的内存输出？
提问于 2014-09-10 12:54:10
有一段时间，我在我的Debian VPS服务器(VPS/虚拟机)上遇到了RAM不足。如果这些事件是定期发生的，这将不是不寻常的。但他们没有。这是穆宁的一张图表：
为了解决这些谜语，我使用atop跟踪我的系统。下面是7:00 RAM和9:00 RAM在内存短缺期间和之后的两个快照(使用-m选项查看与内存相关的信息)：
ATOP - <snip> 2014/09/10 07:00:02 ------ 10m0s elapsed
<snip>
MEM | tot 2.0G | free 79.1M | cache 102.4M | dirty 0.1M | buff 53.2M | slab 90.8M | | |
SWP | tot 2.0G | free 2.0G | | | | | vmcom 748.1M | vmlim 3.0G |
DSK | sda | busy 1% | read 917 | write 1695 | KiB/w 13 | MBr/s 0.01 | MBw/s 0.04 | avio 1.22 ms |
<snip>
PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW RUID EUID MEM CMD 1/15
13717 102 18 10709K 874.5M 206.2M 0K 128K mysql mysql 10% mysqld
4086 166 0 450K 228.1M 21896K 0K 0K www-data www-data 1% apache2
19131 1659 99 450K 225.5M 19604K -2652K -2292K www-data www-data 1% apache2
1469 608 0 450K 222.6M 18508K 256K 64K www-data www-data 1% apache2
23038 347 0 450K 222.3M 18496K 0K 0K www-data www-data 1% apache2
4085 721 0 450K 222.1M 18308K 0K 0K www-data www-data 1% apache2
10639 790 0 450K 224.9M 18284K 768K 932K www-data www-data 1% apache2
19158 199 1 450K 222.1M 18064K 0K 52K www-data www-data 1% apache2
1895 330 0 450K 221.8M 18020K 0K 0K www-data www-data 1% apache2
6661 3346 22 450K 224.0M 17700K 1512K -780K www-data www-data 1% apache2
12570 808 0 450K 221.7M 17668K 512K 508K www-data www-data 1% apache2
19817 0 0 450K 214.5M 15336K 0K 0K root root 1% apache2
18209 3996 0 2277K 55592K 14728K 55592K 14728K till till 1% python
18210 2760 0 4K 43292K 10544K 43292K 10544K munin munin 1% munin-update
11976 506 0 149K 18788K 6512K 0K 0K root root 0% atop
1934 175 0 4K 52228K 5852K 0K 0K root root 0% munin-node
17993 0 0 4K 67020K 5712K 0K 0K postgrey postgrey 0% /usr/sbin/post
2000 0 0 346K 244.3M 5668K 0K 0K root root 0% rsyslogd
14557 0 0 7163K 234.9M 5284K 0K 0K root root 0% php5-fpm
14558 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
14559 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
328 0 0 134K 572.6M 2932K 0K 0K root root 0% console-kit-da
<snip>还有..。
ATOP - vmd1989 2014/09/10 09:00:02 ------ 10m0s elapsed
<snip>
MEM | tot 2.0G | free 1.5G | cache 88.8M | dirty 0.1M | buff 19.2M | slab 25.8M | | |
SWP | tot 2.0G | free 2.0G | | | | | vmcom 748.0M | vmlim 3.0G |
DSK | sda | busy 0% | read 453 | write 1991 | KiB/w 12 | MBr/s 0.01 | MBw/s 0.04 | avio 1.01 ms |
<snip>
PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW RUID EUID MEM CMD 1/16
13717 189 0 10709K 874.5M 206.3M 0K 0K mysql mysql 10% mysqld
23038 743 7 450K 222.6M 18620K 0K 40K www-data www-data 1% apache2
23930 692 0 450K 220.6M 18568K 0K 0K www-data www-data 1% apache2
28738 4784 0 4K 126.4M 18328K 126.4M 18328K munin munin 1% munin-update
26990 392 1 450K 220.5M 18088K 0K 112K www-data www-data 1% apache2
26552 1150 2 450K 220.3M 17788K 512K 576K www-data www-data 1% apache2
28744 1443 0 4K 129.1M 17636K 129.1M 17636K munin munin 1% /usr/share/mun
27424 602 0 450K 219.8M 17504K 8K 240K www-data www-data 1% apache2
27000 216 0 450K 219.8M 17308K 8K 104K www-data www-data 1% apache2
28290 2977 0 450K 219.9M 17200K 219.9M 17200K www-data www-data 1% apache2
19817 68 0 450K 214.5M 15340K 0K 0K root root 1% apache2
28287 429 1 450K 215.0M 10384K 215.0M 10384K www-data www-data 1% apache2
28727 184 0 450K 214.5M 9300K 214.5M 9300K www-data www-data 0% apache2
28728 191 0 450K 214.5M 9300K 214.5M 9300K www-data www-data 0% apache2
11976 490 0 149K 18788K 6512K 0K 0K root root 0% atop
1934 428 0 4K 52228K 5852K 0K 0K root root 0% munin-node
2000 0 0 346K 244.3M 5668K 0K 0K root root 0% rsyslogd
28745 1036 0 4K 52228K 5580K 52228K 5580K root root 0% munin-node [::
14557 0 0 7163K 234.9M 5284K 0K 0K root root 0% php5-fpm
17993 0 0 4K 67020K 4844K 0K 0K postgrey postgrey 0% /usr/sbin/post
14558 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
14559 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
328 0 0 134K 572.6M 2932K 0K 0K root root 0% console-kit-da
<snip>抱歉，名单太长了-只是不想错过原因。然而，我的问题是:我看不出原因。状态(顶部)中的“空闲”内存明显较少，但没有任何进程可以解释为什么，内存将流向何处.
我的想法不对吗？
更新
根据帕特里克的建议，我收集了/proc/meminfo -在内存短缺的阶段和以后。为了便于查看，我将内容放在一个表中：
mem-shortage a bit later
MemTotal: 2060776 kB 2060776 kB
MemFree: 252896 kB 1608532 kB *
Buffers: 15464 kB 12060 kB
Cached: 71864 kB 62800 kB
SwapCached: 4160 kB 4160 kB
Active: 268020 kB 253368 kB
Inactive: 134988 kB 132300 kB
Active(anon): 225940 kB 220872 kB
Inactive(anon): 97296 kB 220872 kB *
Active(file): 42080 kB 32496 kB
Inactive(file): 37692 kB 29116 kB
Unevictable: 6540 kB 6680 kB
Mlocked: 6540 kB 6680 kB
SwapTotal: 2096476 kB 2096476 kB
SwapFree: 2081568 kB 2081568 kB
Dirty: 0 kB 116 kB
Writeback: 0 kB 0 kB
AnonPages: 318084 kB 313364 kB
Mapped: 20692 kB 20408 kB
Shmem: 4208 kB 9896 kB
Slab: 24336 kB 23936 kB
SReclaimable: 10252 kB 9316 kB
SUnreclaim: 14084 kB 14620 kB
KernelStack: 1464 kB 1544 kB
PageTables: 8396 kB 9544 kB
NFS_Unstable: 0 kB 0 kB
Bounce: 0 kB 0 kB
WritebackTmp: 0 kB 0 kB
CommitLimit: 3126864 kB 3126864 kB
Committed_AS: 744764 kB 761812 kB
VmallocTotal: 34359738367 kB 34359738367 kB
VmallocUsed: 272976 kB 272976 kB
VmallocChunk: 34359464431 kB 34359464431 kB
HardwareCorrupted: 0 kB 0 kB
AnonHugePages: 0 kB 0 kB
HugePages_Total: 0 0
HugePages_Free: 0 0
HugePages_Rsvd: 0 0
HugePages_Surp: 0 0
Hugepagesize: 2048 kB 2048 kB
DirectMap4k: 282560 kB 282560 kB
DirectMap2M: 1814528 kB 1814528 kB我只看到两个有意义的差异(不是统计意义上的)差异，用星号(*)标记，但我不认为，它们告诉我RAM到哪里去了。
我还检查了共享内存(尽可能好).却一无所获。
# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status我还使用unhide检查隐藏进程。但是，除了一个假阳性(已知的Debian问题)，似乎没有任何隐藏的进程。
还有更多的想法吗?为什么使用1.2 GB内存--然后就不使用了？这是否是由虚拟服务器架构引起的另一个问题？
更新
我遵循塞尔吉奥的提示去咨询lsmod并检查内存膨胀。size列没有提供任何有用的信息，但是存在一个进程vmw_balloon --因此它实际上是一个在虚拟机之间移动内存的问题。问题回答:)
# During high RAM usage (removed middle part)
$ lsmod | sort -r -k 2,2n
Module Size Used by
crc16 12343 1 ext4
crc_t10dif 12348 1 sd_mod
libcrc32c 12426 2 xfs,btrfs
mperf 12453 0
ata_generic 12490 0
pcspkr 12632 0
vmw_balloon 12657 0 <=
ac 12668 0
i2c_piix4 12704 0
coretemp 12898 0
<snip>
reiserfs 193501 0
drm 211856 2 ttm,vmwgfx
ext4 381419 1
xfs 628913 0
btrfs 641551 0回答 1
Unix & Linux用户
回答已采纳
发布于 2014-09-18 14:33:50
可能您的虚拟机正在遭受某种从虚拟化平台订购的内存膨胀操作。您可以通过使用lsmod查找相关模块(名称从一个虚拟化平台更改到另一个虚拟化平台，但它应该非常独特)来确认这一点。
当启用内存膨胀时，虚拟化主机可以在需要时将内存资源从一个VM移动到另一个VM。在所述主机的请求下，来自客户的内核模块保留所指示的物理RAM数量(从操作系统运行在来宾上的角度来看)，以确保没有其他进程可以使用它。然后，主机将真正的物理资源重新分配给另一位来宾。
对客人的影响正是你所看到的，很多内存使用的内存没有明显的所有者。
如果您无法控制该虚拟化平台，您应该向您的提供者询问有关虚拟机膨胀参数的实际配置的信息。
页面原文内容由Unix & Linux提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://unix.stackexchange.com/questions/154806
复制相关文章
相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号