Go 如何以及何时为有界队列通道分配内存?
How and when does Go allocate memory for bounded-queue channels?
我正在使用 Go 的 pprof 工具来调查我的服务的内存使用情况。几乎所有的内存使用都来自一个设置多个有界队列通道的函数。我对 pprof 在这里告诉我的内容感到有些困惑:
$ go tool pprof ~/pprof/pprof.server.alloc_objects.alloc_space.inuse_objects.inuse_space.007.pb.gz
File: server
Type: inuse_space
Time: Dec 21, 2020 at 10:46am (PST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) list foo
Total: 102.73MB
ROUTINE ======================== github.com/******/foo in ***.go
79.10MB 79.10MB (flat, cum) 77.00% of Total
. . 135:
. . 136:func foo() {
. . 137:
14.04MB 14.04MB 138: chanA := make(chan chanAEntry, bufferSize)
. . 139: defer close(chanA)
. . 140:
. . 141:
19.50MB 19.50MB 142: chanB := make(chan chanBCEntry, bufferSize)
. . 143: defer close(chanB)
. . 144:
. . 145:
27.53MB 27.53MB 146: chanC := make(chan chanBCEntry, bufferSize)
. . 147: defer close(chanC)
. . 148:
. . 149:
7.92MB 7.92MB 150: chanD := make(chan chanDEntry, bufferSize)
. . 151: defer close(chanD)
. . 152:
看起来第 142 行负责 19.50MB 的分配,而第 146 行负责 27.53MB,但这些行在做同样的事情 - 它们创建具有相同输入类型和相同容量的缓冲通道。
- 这是 pprof 随机抽样的产物吗?
- Go 是否延迟分配通道(顺便说一下,在让服务 运行 几天后这些值最终相等)?
- pprof 是否报告沿通道发送的对象所需的内存以及通道本身所需的内存?
好的,我相信我已经弄明白了。看起来 Go 急切地分配,差异只是由于 Go 内存分析器获取样本的方式。
Go急切分配通道内存
docs make
承诺
The channel's buffer is initialized with the specified
buffer capacity.
我查看了 makechan 的代码,它在 make(chan chantype, size)
期间被调用。它总是直接调用 mallocgc
- 没有懒惰。
查看 mallocgc 的代码,我们可以确认 mallocgc
中没有惰性(除了文档注释没有提到惰性,mallocgc
直接调用 c.alloc
).
pprof 在堆分配级别采样,而不是调用函数级别
在环顾四周 mallocgc
时,我找到了分析代码。在每个 mallocgc
调用中,Go 将检查是否满足其采样条件。如果是这样,它会调用 mProf_Malloc 将记录添加到堆配置文件中。我无法确认这是 pprof
使用的配置文件,但该文件中的评论表明它是。
采样条件基于自上次采样以来分配的字节数(它从指数分布中得出样本,平均每分配 runtime.MemProfileRate 字节后)。
这里的重要部分是每次调用 mallocgc
都有一定的采样概率,而不是每次调用 foo
。这意味着如果对 foo
的调用对 mallocgc
进行多次调用,我们预计只有 mallocgc
中的一些调用会被采样。
综合起来
每次我的函数 foo
是 运行 时,它都会急切地为 4 个通道分配内存。在每次内存分配调用中,Go 都有可能记录堆配置文件。平均而言,Go 会每 512kB(默认值 runtime.MemProfileRate)记录一次堆配置文件。由于这些通道的总大小为 488kB,平均而言,我们预计每次调用 foo
时只会记录一次分配。我上面分享的配置文件是在服务重新启动后相对较短的时间内拍摄的,因此分配字节数的差异是纯粹统计差异的结果。让服务运行一天后,配置文件稳定下来显示第142行和146行分配的字节数相等
我正在使用 Go 的 pprof 工具来调查我的服务的内存使用情况。几乎所有的内存使用都来自一个设置多个有界队列通道的函数。我对 pprof 在这里告诉我的内容感到有些困惑:
$ go tool pprof ~/pprof/pprof.server.alloc_objects.alloc_space.inuse_objects.inuse_space.007.pb.gz
File: server
Type: inuse_space
Time: Dec 21, 2020 at 10:46am (PST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) list foo
Total: 102.73MB
ROUTINE ======================== github.com/******/foo in ***.go
79.10MB 79.10MB (flat, cum) 77.00% of Total
. . 135:
. . 136:func foo() {
. . 137:
14.04MB 14.04MB 138: chanA := make(chan chanAEntry, bufferSize)
. . 139: defer close(chanA)
. . 140:
. . 141:
19.50MB 19.50MB 142: chanB := make(chan chanBCEntry, bufferSize)
. . 143: defer close(chanB)
. . 144:
. . 145:
27.53MB 27.53MB 146: chanC := make(chan chanBCEntry, bufferSize)
. . 147: defer close(chanC)
. . 148:
. . 149:
7.92MB 7.92MB 150: chanD := make(chan chanDEntry, bufferSize)
. . 151: defer close(chanD)
. . 152:
看起来第 142 行负责 19.50MB 的分配,而第 146 行负责 27.53MB,但这些行在做同样的事情 - 它们创建具有相同输入类型和相同容量的缓冲通道。
- 这是 pprof 随机抽样的产物吗?
- Go 是否延迟分配通道(顺便说一下,在让服务 运行 几天后这些值最终相等)?
- pprof 是否报告沿通道发送的对象所需的内存以及通道本身所需的内存?
好的,我相信我已经弄明白了。看起来 Go 急切地分配,差异只是由于 Go 内存分析器获取样本的方式。
Go急切分配通道内存
docs make
承诺
The channel's buffer is initialized with the specified buffer capacity.
我查看了 makechan 的代码,它在 make(chan chantype, size)
期间被调用。它总是直接调用 mallocgc
- 没有懒惰。
查看 mallocgc 的代码,我们可以确认 mallocgc
中没有惰性(除了文档注释没有提到惰性,mallocgc
直接调用 c.alloc
).
pprof 在堆分配级别采样,而不是调用函数级别
在环顾四周 mallocgc
时,我找到了分析代码。在每个 mallocgc
调用中,Go 将检查是否满足其采样条件。如果是这样,它会调用 mProf_Malloc 将记录添加到堆配置文件中。我无法确认这是 pprof
使用的配置文件,但该文件中的评论表明它是。
采样条件基于自上次采样以来分配的字节数(它从指数分布中得出样本,平均每分配 runtime.MemProfileRate 字节后)。
这里的重要部分是每次调用 mallocgc
都有一定的采样概率,而不是每次调用 foo
。这意味着如果对 foo
的调用对 mallocgc
进行多次调用,我们预计只有 mallocgc
中的一些调用会被采样。
综合起来
每次我的函数 foo
是 运行 时,它都会急切地为 4 个通道分配内存。在每次内存分配调用中,Go 都有可能记录堆配置文件。平均而言,Go 会每 512kB(默认值 runtime.MemProfileRate)记录一次堆配置文件。由于这些通道的总大小为 488kB,平均而言,我们预计每次调用 foo
时只会记录一次分配。我上面分享的配置文件是在服务重新启动后相对较短的时间内拍摄的,因此分配字节数的差异是纯粹统计差异的结果。让服务运行一天后,配置文件稳定下来显示第142行和146行分配的字节数相等