甲骨文AMD实例内存显示异常？排查与解决方案

最近在玩甲骨文（Oracle Cloud）总是能碰上各种奇奇怪怪的“特性”。这不，刚抢到一台大家都想要的 AMD 高性价比实例，结果进系统一查 free -m，心态直接崩了——明明标称是 1GB 或者更大的内存，为什么系统里只显示 498MB？

是不是我哪里设置错了？还是被官方“偷”了内存？如果你也遇到了这种情况，先别急着删机重开，这其实是个老生常谈的问题。今天就来聊聊为什么会这样，以及该怎么解决。

一、 内存去哪了？

图1：系统识别内存异常，仅显示 498MB

首先，我们要明白云服务器底层虚拟化的一点点“猫腻”。在甲骨文 ARM 架构的实例上，我们以前经常遇到 24GB 实际只有 23GB 左右的情况，这还好理解。但在 AMD 实例上发现内存直接“腰斩”，确实吓人一跳。

实际上，这 498MB 的显示，通常是因为系统保留了部分内存给特定的底层硬件或内核使用，导致 free 命令或者系统监控面板无法读到这部分被预留的内存。有时候是因为镜像问题，有时候是因为 BIOS/UEFI 的内存映射设置。

图2：修改 GRUB 配置文件以解锁内存

二、 别急着改配置，先看 GRUB

很多时候，这不是硬件坏了，而是引导配置的问题。在 Linux 系统中，GRUB（Grand Unified Bootloader）负责引导内核，它里面有一些参数决定了内核能看到多少内存。

如果你的内核参数中限制了内存地址范围，或者开启了某些特殊的调试模式，就有可能导致内存识别不全。

三、 实操解决：解锁隐藏内存

不用慌，几行命令就能大概率解决问题。我们可以尝试修改 GRUB 配置，移除可能存在的内存限制，然后重启系统让内核重新扫描硬件。

1. 编辑 GRUB 配置文件

使用你喜欢的编辑器（比如 nano 或 vim）打开 /etc/default/grub：

sudo nano /etc/default/grub

2. 检查 GRUB_CMDLINE_LINUX

找到 GRUB_CMDLINE_LINUX="..." 这一行。仔细看看里面是不是有类似 mem=512M 或者 max_addr=... 这样的参数？如果有，这就是罪魁祸首。

通常甲骨文默认配置应该没有这些限制，但如果有，直接删除这些参数即可。

3. 更新 GRUB 并重启

修改完成后（如果原来是空的或者没异常，也可以尝试加入显式声明，不过通常保持默认就好），保存退出。然后运行命令更新引导配置：

sudo update-grub
# 或者对于 CentOS/Oracle Linux 系统可能是：
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
``n```

最后，执行重启大法：

```bash
sudo reboot

4. 再次验证

重启完成后，重新登录系统，再次输入：

free -h

或者查看 top、htop。这时候，你应该就能看到完整的内存容量了（比如 1GB 或者更多）。

四、 如果修改 GRUB 没用怎么办？

如果你打开 /etc/default/grub 发现配置一切正常，而且修改重启后内存依然是 498MB，那么可能就要考虑以下两个原因了：

1. 镜像损坏或版本 BUG：你安装的操作系统镜像可能存在兼容性问题。建议在甲骨文控制台重装一个官方推荐的最新版镜像，比如 Oracle Linux 7/8/9 或者 Ubuntu 22.04 LTS 试试。

2. 底层真的“留了一手”：虽然这种情况少见，但不排除甲骨文在特定机型的 AMD 实例上，利用虚拟化技术预留了大量显存给 GPU 虚拟化或者给管理平面使用，导致可用内存缩水。这时候，你只能考虑通过“Always Free”的权益去尝试开通其他规格，或者看看能不能在控制台更换 Shapes（形状/规格）。

写在最后

玩 VPS（尤其是这种“白嫖”或者低价资源），排查问题的能力比能抢到鸡更重要。遇到内存显示异常别慌，先检查内核启动参数，这是最常见也是最容易被忽略的坑。

希望这篇小文能帮你拯救那“消失”的几百兆内存，毕竟对于小鸡来说，每一兆都很珍贵！