getmemoryinfo能看节点内存吗？

Bitcoin Core getmemoryinfo 的 stats 主要描述锁页内存管理器，并非进程全部内存。本文拆解六个字段、锁页失败、mallocinfo限制及多层告警方案。

getmemoryinfo 的名字很宽，默认 stats 返回却聚焦 locked memory manager。它适合发现敏感内存是否成功锁页、管理器分配是否异常，却不能替代操作系统 RSS、虚拟内存、交换区或容器限额。

这不是Bitcoin进程的总内存

getmemoryinfo 的 stats 模式返回守护进程内存使用信息中的 locked memory manager 统计。它观察的是一个专门管理敏感锁页区域的组件。进程 RSS、文件缓存、mmap 与其他堆分配都可能在这组字段之外变化。

bitcoin-cli getmemoryinfo stats

先保存完整 locked 对象，不把 total 改名为“节点总内存”。

locked六字段怎样互相校验

stats字段	组件内解释	告警前复核
used / free / total	锁页管理器的使用、空闲和总量	先检查三者关系再画图
locked	实际成功锁定的字节数	小于total可能存在锁页失败
chunks_used / chunks_free	管理器块数量	不是操作系统内存页数
mallocinfo	glibc低层堆XML	平台和编译条件会限制可用性

locked 对象包含 used、free、total、locked、chunks_used 和 chunks_free；locked 小于 total 表示曾有锁页失败。 used、free 与 total 提供管理器内部关系；locked 更接近实际锁页成功量。比例异常优先查 memlock 限制、权限和内核日志。

mallocinfo何时可用又有何风险

mallocinfo 模式返回低层堆状态 XML，并且只有使用 glibc 编译时才可用。

bitcoin-cli getmemoryinfo mallocinfo 可能返回低层 XML，但只在 glibc 编译环境可用。它适合受控诊断，不应成为跨平台健康检查硬依赖，也不宜不加限制地暴露给外部监控。

三层内存告警应该怎样分工

三层面板分别采集：

locked manager：stats 六字段；
bitcoind 进程：RSS、虚拟内存、文件描述符与 swap；
宿主或容器：内存限额、压力事件和 OOM 记录。

locked manager 统计不能替代操作系统 RSS、虚拟内存和容器限额指标，节点告警应把它们分开采集。 1. 保存节点版本、平台、容器限制与启动参数。 2. 采集 stats 原始对象并做字段一致性校验。 3. 并行读取进程 RSS、虚拟内存和 swap。 4. 把 locked 比例与系统压力设为独立告警。 5. 版本或平台变化后重新建立正常基线。

锁页统计常见误判清单

如果 locked 小于 total，而系统 RSS 很平稳，问题可能是锁页权限或系统限制，不应报警为“内存泄漏”。如果 RSS 持续增长但 locked 字段不变，也不能据此判定节点正常，因为增长可能发生在锁页管理器之外。

把 total 画成 bitcoind 总内存。
看到 free 较少便认定系统即将 OOM。
在非 glibc 环境强依赖 mallocinfo。
把 locked 失败和堆增长归为同一告警。

锁页失败告警和进程增长告警必须有不同名称、阈值与处置人，避免值班人员沿错误路径扩容或重启。

节点内存观测表和官方索引

连续采集十个 stats 样本，同时记录 RSS 与容器限额。复核者为每个异常选择“锁页问题、进程内存问题、系统压力或证据不足”，并说明选择依赖哪些字段；只引用 total 的结论一律退回。

内存诊断依赖操作系统、编译方式和部署隔离。RPC 可提供一块证据，但故障结论仍需结合进程指标、内核日志和容器事件，不能由单个快照完成。

告警阈值应来自同平台、同编译方式和同负载的基线。新节点初始同步、索引构建与稳定运行的内存形态不同，不宜共用一个阈值。出现 OOM 风险时优先保留内核和容器事件，再决定是否重启；先重启会清掉最有价值的现场，并让累计指标回到起点。

需要继续确认：操作系统锁页上限和容器安全策略因部署环境而异，文章不提供通用阈值。

getmemoryinfo 依据：Bitcoin Core 31 getmemoryinfo
getmemoryinfo 依据：Bitcoin Core 31 RPC Index

配套运行状态 getrpcinfo运行状态、索引同步判断、内存池压力指标。