pprof与ps内存使用差异：如何定位缺失的约3GB内存？

首先明确：pprof的MemProfileHeap仅统计Go堆上的内存，而RSS是进程实际占用的物理内存，包含堆外内存、未还给OS的Go内存碎片、Cgo分配的内存、mmap的文件/匿名内存等，两者的差异大概率来自这些未被统计的部分。给你几个具体的排查方向：

• 调整pprof采集范围
  把profile.MemProfileHeap替换为profile.MemProfileAll，该选项会包含堆外内存（比如Cgo调用、syscall直接分配的内存）。重新生成profile后分析，看是否能覆盖那3GB的缺口——如果是sonic或其他依赖使用了Cgo，这部分内存就会被统计到。

• 检查Go runtime的内存释放情况
  在代码中加入runtime.ReadMemStats打印关键指标：

  var m runtime.MemStats
  runtime.ReadMemStats(&m)
  fmt.Printf("HeapInuse: %.2f GB\nHeapReleased: %.2f GB\n", 
      float64(m.HeapInuse)/1024/1024/1024, 
      float64(m.HeapReleased)/1024/1024/1024)
  

  如果HeapReleased远小于HeapInuse，说明Go runtime回收了内存但没还给OS（因内存碎片或批量释放策略导致）。可以尝试设置环境变量GOGC=50（默认值为100），让GC更频繁触发，观察RSS是否下降。

• 用OS工具分析内存映射
  运行程序时记下PID，用pmap -x <pid>（Linux）或vmmap <pid>（macOS）查看进程的内存分布，重点关注：

  • 大的匿名映射区域（anon）：可能是Cgo分配的内存或syscall.Mmap创建的内存
  • 大的文件映射（file）：如果用mmap加载大文件后未执行unmap，这部分会算进RSS但pprof不统计
    找到占用大的区域后，对应到代码中的操作逐一排查。

• 追踪GC行为
  用GODEBUG=gctrace=1运行程序，观察GC日志里的heap、released字段，看每次GC后内存回收是否正常，有没有内存持续增长无法释放的情况。比如日志中如果heap一直维持在高位，说明存在内存泄漏或内存池持有大量未释放的内存。

• 排查自定义内存操作
  检查代码中是否有直接调用syscall.Mmap、unsafe分配内存后未释放的情况；是否使用了第三方内存池库，是否存在内存池预先分配大量内存但未正确回收的问题。

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