甲骨文1H1G AMD实例内存虚标？教你找回被“吃”掉的内存

最近薅甲骨文（Oracle Cloud）“永久免费”羊毛的朋友可能发现了一个奇怪的现象：新开的 1核1G AMD 架构实例，明明配置写着 1GB 内存，但进系统一查，实际可用竟然只有不到 500MB？这剩下的 500M 内存去哪儿了？难道是被甲骨文“偷吃”了？

其实这并不是内存虚标，而是默认内存管理策略在作祟。今天我们就来扒一扒背后的原理，并给出简单粗暴的解决方案，教你把这部分“消失”的内存找回来。

为什么内存显示少了一半？

Linux 系统内存使用情况示意图

通常情况下，Linux 系统预留一部分内存用于内核操作非常正常。但在甲骨文的 AMD 实例上，这个预留比例被设得非常激进。这是因为其底层使用了特定的内核配置（通常与 KVM 虚拟化和最小内存占用有关），导致系统为了稳定性，人为锁定了大量低内存（LowMem），阻止用户进程使用。

简单来说，系统把那一半内存当成了“公摊面积”，只有系统内核能用，你的 Docker、博客或者脚本都被挡在门外。这对于只有 1G 这种“乞丐版”配置的 VPS 来说，简直是灾难，稍微跑几个服务就 OOM（内存溢出）了。

轻松找回内存：修改内核参数

既然知道了是配置问题，解决办法自然就是修改内核启动参数，告诉系统“别浪费内存，给我用掉”。操作步骤如下，适用于大多数 Linux 发行版（如 Ubuntu、CentOS、Debian）。

第一步：备份启动配置文件

无论是老手还是小白，修改启动项前一定要备份，防止改错起不来机器（虽然甲骨文有 VNC 救援，但能省事还是省事）。

编辑 GRUB 配置文件示例

执行以下命令备份 grub 配置：

cp /etc/default/grub /etc/default/grub.bak

第二步：编辑 GRUB 配置

使用你喜欢的编辑器（比如 vim 或 nano）打开配置文件：

vim /etc/default/grub

找到 GRUB_CMDLINE_LINUX_DEFAULT 这一行。这一行定义了内核启动时的默认参数。我们需要在这里加入一段神奇的代码：transparent_hugepage=never。

修改前可能长这样： GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0"

修改后建议变成这样： GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 transparent_hugepage=never"

原理解析： transparent_hugepage 是 Linux 的一种内存管理特性，旨在通过使用大页内存来提升性能。但在内存较小（如 1GB）的虚拟化环境中，开启此功能有时会因为内存碎片整理机制反而导致内存分配效率低下，或者在统计上显示不可用。关闭它可以让内存管理回归传统模式，释放被锁定的页面，从而增加可用内存。

第三步：更新 GRUB 并重启

修改完配置文件后，需要更新引导加载程序让配置生效。

如果是 Ubuntu/Debian 系统：

update-grub

如果是 CentOS/RHEL 系统（通常为 CentOS 7）：

grub2-mkconfig -o /boot/grub2/grub.cfg

执行成功后，重启 VPS：

reboot

验证成果

重启回来后，再次输入 free -h 或者 htop 查看内存情况。你应该会惊喜地发现，可用的 Mem 已经回升到了 900MB 甚至更多。那消失的一半“豪宅”面积，终于收回自己名下了！

总结与小贴士

1. 适用场景： 此方法主要针对甲骨文云 AMD 实在 1H1G 这种低配机型上出现的大额内存预留问题。如果配置本来就大（如 4G/8G），这几十百把 M 的差异其实没必要折腾。
2. 副作用： 关闭透明大页可能会对极少数依赖内存密集型计算的高负载应用有微乎其微的性能影响，但对于仅用于建站、跑脚本、科学上网等轻度用途，完全感觉不到区别。
3. 稳定性： 该操作在社区已验证多年，相对安全，只要不手滑删错文件，基本不会翻车。

薅羊毛不易，寸土寸金。希望这篇小教程能帮大家榨干甲骨文免费实例的每一滴性能！如果你还有其他服务器优化难题，欢迎留言讨论。