VPS内存缩水排查：消失的 800MB 内存去哪了？

刚买了一台 4GB 内存的 VPS，兴冲冲地安装面板后一看，却显示只有 3.2GB？ 面对这凭空蒸发的 800MB，我第一反应是遇到了黑心商家“缺斤短两”，甚至一度怀疑自己是不是犯了低级错误，给机器 装了个 32 位系统。但经过一番排查，我发现这消失的内存并非硬件缩水，而是被系统默认开启的 Kdump 机制悄悄“私吞”了。面对VPS内存无故减少的问题，本文详解了从硬件验证到系统配置的完整排查流程，并最终通过禁用Kdump释放内存。本文将记录我从发现内存不足，到修改 Grub 参数成功找回内存的全过程。

缘起：从“佛系”到“崩心态”

熟悉我的朋友都知道，我一向是比较“佛系”的。

其实早在云服务器刚部署好，装好各种东西后，我就发现了这个奇怪的现象：明明我买的是 4GB 的规格，系统里怎么看都只有 3.2GB 左右。

当时看到这个数字，我心里的第一个念头是：“我去，服务商该不会是在给我搞‘缩水机’吧？” 难道这所谓的 4G 实例其实是 3.2G 的残次品？但紧接着，作为一名折腾多年的业余 DIY 玩家，这“3.2G”的诡异数字让我脑海里瞬间闪过一丝不祥的预感——这数值也太像 32 位系统的寻址上限了！

那一瞬间我甚至有点自我怀疑：“难道我手滑，给这台机器装了个 32 位的 Ubuntu？如果不小心把古董级的 32 位系统装在了现代 VPS 上，那可真是运维生涯的黑历史了……”

我赶紧敲了一行 uname -a 压压惊。看到屏幕上明明白白显示着 x86_64，我这才松了一口气：还好，系统没装错，脑子也还正常。

既然排除了“因为蠢装错系统”和“服务商虚假发货”的可能性（凉心云不至于的，况且一般哪有 3.5G 的机器），因为当时老机器上的原有服务已经全部完成迁移到这台新机器并上线运行了有几天了，我想着反正跑个 WordPress 加上几个 Docker 小容器，3GB 也绰绰有余，再加上那时候还是个 linux 萌新，面对折腾系统总有种恐惧感，也就懒得去深究那消失的 800MB 到底去了哪。这一拖，就是4年多过去了（这到底算佛系还是算拖延症呢）。

直到前几天，我遭遇了一次恶意的刷流攻击。虽然通过各种手段挡住了攻击，但那当时看着服务器内存水位线一直处于报警阈值边缘，我的心态终于崩了。

资源寸土寸金，在关键时刻，这“莫名失踪”的 内存可能就是压死骆驼的最后一根稻草。于是，我决定不再佛系，彻底查清这笔“内存烂账”。

验明正身：物理内存还在吗？

虽然早就排除了 32 位系统的嫌疑，但我还是得确认一下底层的硬件规格。使用 dmidecode 命令查看底层硬件信息：

sudo dmidecode -t memory

输出结果非常明确，物理插槽上确实是实打实的 4096 MB：

Physical Memory Array
    Location: Other
    Use: System Memory
    Maximum Capacity: 4 GB
    ...
Memory Device
    Size: 4096 MB
    Type: RAM
    ...

然而，当我切换回系统视角，使用 top 命令或者在面板一看，画风就变了：

MiB Mem :   3419.1 total

4096 – 3419 ≈ 677 MB。 既然物理内存没少，系统也是 64 位的，那只能说明一件事：这部分内存被操作系统内核在启动阶段就已经“私吞”了，导致用操作系统实际可支配的内存减少。

抽丝剥茧：谁吃掉了内存？

系统可用内存比机器规格小不少，在虚拟化环境（云服务器，VPS）中是非常常见的。一般无非是3个地方

可能吃内存的元凶一：虚拟化开销

现在云服务器，都有一些魔改虚拟化机制，可能会在客户机底层埋一些小玩意，这些“小玩意”会占用一点点客户机内存作为通信缓冲区，不过一般都非常克制，不至于直接砍下去 800 MB 吧

可能吃内存的元凶二：硬件/BIOS 保留内存

毕竟虚拟的主板 BIOS 和硬件设备也需要占用地址空间嘛，比如我还开了VNC，几十MB的虚拟显存占用总要有。但是这玩意一般最多也就吃个200M，不应该啊。
我不放心可以执行一下命令，看了下内存映射日志。

dmesg | grep "Memory:"

输出： Memory: 3319136K/4194304K available (14336K kernel code, ...)，嗯……这，被吃的内存可真多。

可能吃内存的元凶三：Kdump (崩溃转储机制)

1. 先检查当前状态：

kdump-config show

显示 current state: ready to kdump，说明它正在占用内存。

2. 看一眼 Grub 默认配置：

cat /proc/cmdline

返回的配置最后赫然写着：crashkernel=2G-16G:512M,16G-:768M
破案了！元凶就是它——Kdump。

什么是 Kdump？
Ubuntu 默认会启用 kdump 。目的是在为了实现当系统内核崩溃时记录错误日志的功能。为了保证系统内存被用户打满后再崩溃时，还有地方存放数据，所以会在系统启动时预先强行划走一部分内存。这部分内存对普通应用是不可用，也不可见的，因此 top 、php、Nginx 统统都统计不到。
不得不说，这也太狠了吧，2G-16G:512M，合着，物理内存在 2G 到 16G 之间，强制保留 512MB？？？我4G砍512MB还不太明显，2G的机器，你给人家砍 512MB，还让不让人用了？

解决问题：让服务器把内存吐出来（禁用 Kdump）

对于像咱们这样的个人站长，服务器主要运行 Web 服务，要这玩意干啥，我又不需要去调试内核崩溃这种底层代码级错误。（主要完全不会……）如果系统内核真崩了，我不应该直接重启或者回滚快照吗。

所以，这 512MB 的“昂贵的买路钱”，我不交了。

第一步：编辑 Grub 配置文件

 sudo vim /etc/default/grub
# 当然，你要是习惯用 nano 的话 用sudo nano /etc/default/grub

第二步：修改参数

找到 GRUB_CMDLINE_LINUX 这一行。

# 原配置：
GRUB_CMDLINE_LINUX="... crashkernel=2G-16G:512M,16G-:768M ..."
# 修改为（直接禁用）
GRUB_CMDLINE_LINUX="... crashkernel=0M ..."

注意：
1. 保留该行内原有的其他参数，只修改 crashkernel 部分
2. 如果你的参数是写在GRUB_CMDLINE_LINUX_DEFAULT里的话，那就改这里的参数。

第三步：更新 Grub 并重启

这一步至关重要，不更新引导文件，改了配置也没用。
注意：执行后，服务器（系统）会被重启

sudo update-grub
sudo reboot

优化结果：瞬间回血

重启服务器后，第一时间打开终端输入 free -m.可用总内存从 3.2GB 瞬间跃升到了 3.9G。舒坦，这么多年拖延的问题终于解决了。虽然平时看着不起眼，但在流量高峰期或者 Docker 容器跑得比较多的时候，它就是从卡顿到流畅运行之间的那道分界线。如果你也发现你的 VPS 内存“缩水”严重，不妨检查一下 /etc/default/grub，说不定也能找回这笔“私房钱”。

总结

1. 感觉最近怎么总是在折腾一些陈年旧故障（笑哭）
2. 这次排故过程其实并不复杂，但它提醒了我：系统的默认配置（尤其是云服务商提供的系统镜像内的配置）未必就是最优配置。
3. 系统默认开启 Kdump 是为了生产环境的稳定性调试考虑的，但对于小内存（尤其是 2G/4G 档位）的 VPS 来说，这却是一种极大的资源浪费。
4. 毕竟操作了系统配置，切记操作前做好快照备份。 如果未来服务器经常莫名其妙死机且无日志可查，那时候才需要重新开启 Kdump 来抓取崩溃现场。但对于绝大多数像我一样只是跑跑博客、Docker 的用户，关了它吧，真香！
5. 熟悉运维的读者应该早已经看出来了，标题说是缺失了800MB内存，这只是我那时候不太熟悉换算得出的错误数字，实际应该是677 MB。那为什么我当时算出了800MB呢，是因为实际是物理内存4096MiB，其中3419Mib可用，但面板里不是这样算的，面板是用10进制算的，所以变成了3419Mib/1024/1024X1000X1000=3.26G内存可用，然后面板还隐藏了百分位，变成了3.2G，然后我（4G-3.2G）X1000=800MB，得出了“我擦，怎么少了快800MB”的结论。正确算法应该是 4096-3419=677MB 不过琢磨了下，我决定还是按照当时的实际心路历程去如实写吧。