如何分析golang内存 [英] how to analyse golang memory

问题描述

我写了一个golang程序，它在运行时耗资1.2GB。
当我使用

  go工具pprof http://10.10.58.118:8601/debug/pprof/heap 
  

得到转储。

它显示堆中只有323.4MB。
什么是其他内存不见了？

有没有更好的工具可以解释golang运行时内存？

---

当我使用gcvis时，我得到了这个

和堆形式配置文件

我的代码

  https://github.com/sharewind/push-server/blob/v3/broker 
  

$ b $堆配置文件显示活动内存，运行时认为正在被go程序使用的内存（即：未被垃圾收集器收集）。 GC收集内存时，配置文件会缩小，但不会将内存返回到系统。您的未来分配将尝试使用先前收集的对象池中的内存，然后向系统请求更多内容。

从外部看，这意味着程序的内存使用增加或保持水平。外部系统表现为程序的常驻大小是指程序分配给程序的RAM字节数，无论它是持有正在使用的值还是收集的值。

这两个数字通常有很大不同的原因是：

1. GC采集内存对外部视图没有影响程序


2. 内存碎片


3. GC仅在正在使用的内存在前一个GC之后加倍使用的内存时运行（默认情况下，请参阅： http://golang.org/pkg/runtime/#pkg-overview ）

如果您想精确分析Go如何查看内存，可以使用runtime.ReadMemStats调用：http://golang.org/pkg/runtime/#ReadMemStats

另外，由于您使用的是web-如果您可以通过您的br访问分析数据，则可以使用基于分析的分析owser at： http://10.10.58.118:8601/debug/pprof/ ，单击heap链接会显示堆配置文件的调试视图，该视图具有打印输出在底部有一个runtime.MemStats结构。

runtime.MemStats文档（ http://golang.org/pkg/runtime/#MemStats ）对所有字段都有解释，但讨论中有趣的是：

• HeapAlloc：分析器给你的内容（活动堆内存）


• Alloc：类似于HeapAlloc，但是对于所有的管理内存
>

• Sys：从操作系统请求的内存总量（地址空间）
  

Sys之间的差异以及操作系统报告的内容，因为Go对系统的要求以及操作系统赋予的内容并不总是相同。另外，CGO / syscall（例如：malloc / mmap）内存不会被go跟踪。

I wrote a golang program, It cost 1.2GB at the runtime. when I use

go tool pprof http://10.10.58.118:8601/debug/pprof/heap

to got a dump。

It show only 323.4MB in the heap. what is other memory gone ?

Is there any better tool to explain golang runtime memory ?

---

when I use gcvis I got this

and the heap form profile

my code on

https://github.com/sharewind/push-server/blob/v3/broker

解决方案

The heap profile shows active memory, memory the runtime believes is in use by the go program (ie: hasn't been collected by the garbage collector). When the GC does collect memory the profile shrinks, but no memory is returned to the system. Your future allocations will try to use memory from the pool of previously collected objects before asking the system for more.

From the outside, this means that your program's memory use will either be increasing, or staying level. What the outside system presents as the "Resident Size" of your program is the number of bytes of RAM is assigned to your program whether it's holding in-use go values or collected ones.

The reason why these two numbers are often quite different are because:

1. The GC collecting memory has no effect on the outside view of the program
2. Memory fragmentation
3. The GC only runs when the memory in use doubles the memory in use after the previous GC (by default, see: http://golang.org/pkg/runtime/#pkg-overview)

If you want an accurate breakdown of how Go sees the memory you can use the runtime.ReadMemStats call: http://golang.org/pkg/runtime/#ReadMemStats

Alternatively, since you are using web-based profiling if you can access the profiling data through your browser at: http://10.10.58.118:8601/debug/pprof/ , clicking the heap link will show you the debugging view of the heap profile, which has a printout of a runtime.MemStats structure at the bottom.

The runtime.MemStats documentation (http://golang.org/pkg/runtime/#MemStats) has the explanation of all the fields, but the interesting ones for this discussion are:

• HeapAlloc: essentially what the profiler is giving you (active heap memory)
• Alloc: similar to HeapAlloc, but for all go managed memory
• Sys: the total amount of memory (address space) requested from the OS

There will still be discrepancies between Sys, and what the OS reports because what Go asks of the system, and what the OS gives it are not always the same. Also CGO / syscall (eg: malloc / mmap) memory is not tracked by go.

这篇关于如何分析golang内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！