Skip to content

内存使用去向不明:MemTotal 8GB 但实际可用常不足 1GB,约 6.35GB 在虚拟机内部无法解释 #1031

Description

@WR-Class

反馈内容:开发环境疑似 Firecracker microVM(/proc/cmdline 含 init=/firecracker-init,无 PCI,virtio-mmio)。/proc/meminfo 显示 MemTotal 为 8.0GB,但内存去向存在约 6.35GB 的"黑洞":

进程实际占用:所有进程 RSS 合计约 0.95GB(opencode ~438MB + 机器人进程 ~244MB + searxng ~88MB + 其他)。
可解释内存合计约 1.5GB:AnonPages ~0.93GB + Cached ~0.25GB + Slab/页表/内核栈/buffers 约 0.05GB + MemFree 0.22GB。
差额约 6.35GB 无法观测:MemTotal − 上述可解释项 = 6.35GB,既不在任何进程 RSS 中,也不在内核 slab/页表/缓存中。
实际可用极低:MemAvailable 常只有 300
500MB,最低曾到 127MB;无 swap;zone 的 present/managed 与 DirectMap1G 显示存在 5GB+ 的直接映射,疑似被虚拟化层或宿主预留(virtio DMA 缓冲、大页映射或内存 balloon),guest 内用 /proc/meminfo、/proc/zoneinfo、free、/proc/slabinfo 均无法定位去向。
影响:由于实际可用内存严重不足,运行的 NapCat(QQ 机器人)在启动登录阶段发生 native 库段错误(NTSdk/wrapper.node,内核日志 segfault,退出码 11,10 秒内连续崩溃 3 次后主进程退出),需要手工释放 page cache 后才能勉强拉起,稳定性无法保证。

期望效果:说明该 6.35GB 内存的具体去向(若为虚拟化层/宿主预留,请给出 guest 内可观测或可配置的方式)。
提升 guest 实际可用内存,或将 MemTotal 调整为真实可用的数值,避免误导。
提供更高内存规格的实例,使 NapCat 等内存敏感服务能稳定运行,不再因内存不足段错误。

我的 UID:5ed6626d-4d2e-4e0e-abd3-1806d5cc69cf

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions