Golang gRPC Server内存占用居高不下排查咨询

• 调整Go runtime的内存回收策略：Go 1.12+默认使用MADV_FREE策略通知OS回收空闲内存，该策略仅在系统内存压力较高时才会真正回收页，会导致RSS数值居高不下。可以在服务启动时添加环境变量GODEBUG=madvdontneed=1，强制runtime使用MADV_DONTNEED策略主动归还空闲内存，配合debug.FreeOSMemory()调用验证是否是回收策略导致的内存未释放。
• 排查cgo/非Go runtime管理的内存泄漏：pprof默认仅统计Go内存分配器管理的堆内存，cgo分配的内存、第三方依赖通过mmap/系统调用直接申请的内存不会被统计，这是pprof统计值和RSS差异极大的最常见原因。重点检查数据库驱动、gRPC底层依赖、JSON序列化库是否使用了cgo实现，是否存在资源未释放的逻辑，比如数据库查询的Rows迭代器未调用Close()、gRPC连接未正常关闭等场景。
• 排查goroutine泄漏：检查pprof的goroutine指标，确认是否存在大量阻塞、未退出的goroutine，即使单goroutine内存占用较低，数万量级的goroutine累积的栈内存、持有资源也可能导致总内存占用异常升高。
• 排查内存碎片化问题：批量处理2万条商品数据时如果频繁申请大内存块，可能导致Go内存分配器产生大量无法合并的空闲内存碎片，这部分内存虽然对Go runtime可用，但是无法归还给OS，会体现为RSS高但堆使用低。可以调整业务逻辑，使用sync.Pool复用高频申请的大切片、JSON序列化缓冲区，避免频繁分配/释放大内存块。
• 使用系统级工具定位内存分布：使用pmap -x <pid>查看进程的内存段分布，确认高占用内存是匿名页、共享库还是内存映射文件；使用bcc工具集的memleak工具可以直接检测用户态进程的内存泄漏点，定位未释放的内存分配调用栈。
• 排查内核缓冲区占用：如果gRPC存在大量未正常关闭的连接、或者并发调用时的内核Socket缓冲区未释放，也会被计入进程的RSS统计，可以用ss -s查看当前进程的连接状态，确认是否存在连接泄漏。

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