英文:
Why 'Total MB' in golang heap profile is less than 'RES' in top?
问题
我有一个用Go语言编写的服务，在运行时占用6-7G的内存（在top命令中的RES）。所以我使用了pprof工具来找出问题所在。
go tool pprof --pdf http://<service>/debug/pprof/heap > heap_prof.pdf
但是结果中只有大约1-2G的内存（pdf中的'Total MB'）。剩下的内存在哪里？
我还尝试使用GOGC=off来对我的服务进行性能分析，结果'Total MB'与top命令中的'RES'完全相同。看起来内存已经被垃圾回收了，但没有被归还给内核，所以无法进行性能分析。
有什么想法吗？
附注：我在1.0.3和1.1rc3版本中都进行了测试。
英文:
I have a service written in go that takes 6-7G memory at runtime (RES in top). So I used the pprof tool trying to figure out where the problem is.
go tool pprof --pdf http://<service>/debug/pprof/heap > heap_prof.pdf
But there are only about 1-2G memory in result ('Total MB' in pdf). Where's the rest ?
And I've tried profile my service with GOGC=off, as a result the 'Total MB' is exactly the same as 'RES' in top. It seems that memory is GCed but haven't been return to kernel won't be profiled.
Any idea?
P.S, I've tested in both 1.0.3 and 1.1rc3.
答案1
得分: 9
这是因为Go目前不会将被垃圾回收的对象的内存返还给操作系统，准确地说，只有小于预定义限制（32KB）的对象才会被返还。相反，内存会被缓存以加快未来的分配速度Go:malloc。此外，似乎这个问题将在未来得到解决TODO。
编辑：
新的垃圾回收行为：如果内存一段时间没有被使用（大约5分钟），运行时会建议内核从未使用的虚拟范围中删除物理映射。可以通过调用runtime.FreeOSMemory()来强制执行此过程。
英文:
This is because Go currently does not give memory of GC-ed objects back to the operating system, to be precise, only for objects smaller then predefined limit (32KB). Instead memory is cached to speed up future allocations Go:malloc. Also, it seems that this is going to be fixed in the future TODO.
Edit:
New GC behavior: If the memory is not used for a while (about 5 min), runtime will advise the kernel to remove the physical mappings from the unused virtual ranges. This process can be forced by calling runtime.FreeOSMemory()
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论