Kube API Server内存异常：pprof inuse_space与实际占用差异排查

首先明确：pprof的inuse_space仅统计Go堆内存，而top/Grafana显示的是进程整体内存（RSS/VMS），两者统计范围完全不同，这就是差异的核心原因。

统计范围的核心区别 #

• pprof inuse_space：只追踪Go runtime管理的堆内存，也就是Go代码中通过new、make等分配的内存，不包含：
  • Go runtime自身的非堆内存（栈内存、调度器内部结构、内存池元数据等）
  • CGO调用分配的内存（Kube API Server依赖的etcd客户端底层、加密库等多用到CGO）
  • 操作系统为进程分配的其他内存（文件缓存、共享库、内核态分配的内存页等）
• top/Grafana的RSS/VMS：统计进程实际占用的所有内存，覆盖上述pprof未统计的全部内容。

进一步排查内存溢出的方向 #

既然Go堆内存仅9G左右，但进程实际占24G，重点排查以下点：

• 用pmap -x <kube-apiserver-pid>查看进程内存映射，找出大的匿名映射或共享库区域，定位CGO组件是否存在内存泄漏
• 通过slabtop检查内核slab分配器的使用情况，确认是否因Kube API Server导致内核内存占用过高
• 排查etcd客户端内存：Kube API Server与etcd交互时，客户端可能缓存大量数据，部分实现基于CGO，这部分内存不会被pprof统计
• 验证Go runtime配置：比如GOGC参数是否过低导致堆内存回收不及时，但结合当前堆内存规模，这大概率不是主因

结论 #

你没有误解inuse_space指标，只是它的统计范围远小于进程整体内存占用。要定位24G内存的来源，需要结合系统级工具（pmap、slabtop）和pprof的其他指标（如inuse_objects、alloc_space）协同分析。

内容的提问来源于stack exchange，提问作者og f91