有一段时间，我的 Debian 网络服务器（VPS/虚拟机）遇到 RAM 短缺的问题。如果这种情况经常发生的话，这并不罕见。但他们没有。这是 Munin 的图表：
为了解决这些谜题，我用 跟踪我的系统atop。以下是 RAM 短缺期间和之后上午 7:00 和 9:00 的两个快照（使用-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- 在 RAM 短缺阶段及之后的阶段。为了方便查看，我将内容放在一张表中：
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 RAM 但后来又不使用的想法吗？这是否是虚拟服务器架构导致的另一个问题？
更新
我按照 Sergio 的提示咨询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
可能您的虚拟机正在遭受某种问题内存膨胀从虚拟化平台命令的操作。您可以尝试通过查找相关模块来确认这一点lsmod（名称从一个虚拟化平台到另一个虚拟化平台有所不同，但它应该非常独特）。
启用内存膨胀后，虚拟化主机可以在需要时将内存资源从一个 VM 移动到另一个 VM。根据所述主机的请求，来自来宾的内核模块保留指定数量的身体的RAM（从来宾上运行的操作系统的角度来看是物理的），以确保没有其他进程可以使用它。然后Host将真实的物理资源重新分配给另一个Guest。
对来宾的影响正是您所看到的，大量内存使用了没有明显所有者的内存。
如果您无法控制该虚拟化平台，则应向提供商询问有关虚拟机膨胀参数实际配置的信息。