当用户报告与垃圾回收器(GC)相关的潜在问题时，我们首先要求的是GC跟踪(GODEBUG=gctrace=1)。但我们很少得到它。将gctrace设置为1是足够便宜的，可以一直保持开启，但向stderr发送垃圾信息是不礼貌的。相反，运行时可以在内存中的某个地方记录它，无论是文本还是结构化数据，并在/debug处理程序或其他地方公开它。这样就更容易按需提取了。这对于GODEBUG=sched{detail,trace}也可能是有用的，但我还没有看到这种情况经常出现。
toe950271#
/cc @aclements
bt1cpqcv2#
有人在做这个吗？如果没有，我可以尝试一下。原型：78ec37e它将runtime.MemStats(几乎包含了gctrace=1打印的所有内容)放入内部循环缓冲区，并通过runtime.ReadAllMemStats()暴露出来。它还没有在/debug处理器上暴露任何内容。是否应该从GODEBUG中获取缓冲区大小？
runtime.MemStats
gctrace=1
runtime.ReadAllMemStats()
/debug
plicqrtu3#
目前我所知的，没有人在做这件事，所以请随意。但如果我们只想要MemStats,我们可以直接调用ReadMemStats。通常我们想要知道每个阶段的CPU/墙钟时间，而这并不在里面，只有STW暂停墙钟时间。也许最简单的方法是将额外的信息添加到MemStats中。但这将被Go兼容性承诺覆盖...
kcrjzv8t4#
也许实现这个目标最简单的方法是将额外的信息添加到MemStats中。但这将受到Go兼容性承诺的限制我假设这里有一个拼写错误。因为评论说“由于向后兼容性，我们不能改变MemStats”。或者我漏掉了什么？
rbpvctlc5#
我假设(没有验证)这是指内部含义发生变化的字段，我们不能将这种变化传播到公共结构中，因为它可能会破坏现有的代码。添加字段应该是可以的。
rggaifut6#
有一个明确的检查，用于在添加新字段时失败。它于2010年添加：dc9a3b2#diff-17dbb5a92bd43f80a1909a1814e2d42eR82。据我所知，当时部分代码是用C编写的，部分用Go编写；这个检查是为了确保两个大小匹配。但现在情况已经不同了。那么，我们可以安全地移除这个检查吗？
y4ekin9u7#
感谢您承担这项工作。无需通过添加GODEBUG标志来过度工程化代码。添加标志是一个非常重的更改。为了上下文，垃圾回收器目前只有1个标志，经过10个发布。代码应该选择一个合理的大小，并将其作为实现特定值进行记录。如果大小太小，我们可以在了解用例后向上调整...。2018年2月28日星期三晚上7:11,Dhananjay Nakrani @***. >写道：有人在做这个吗？如果没有，我可以试试看。原型：78ec37e < JayNakrani@78ec37e>。它将运行时.MemStats输出到内部循环缓冲区，并通过runtime.ReadAllMemStats()公开。它尚未在/debug处理程序上公开任何内容。是否应该从GODEBUG中获取缓冲区大小？—您收到此邮件是因为您订阅了此线程。直接回复此电子邮件，查看GitHub上的<#23815 (comment)>或静音线程< https://github.com/notifications/unsubscribe-auth/AA7Wn4TDetKNLbohW8LCGI-NMP6xPMaaks5tZzyrgaJpZM4SEU3A > 。
kkih6yb88#
关于在合理的缓冲区预算下，有人调试垃圾回收(GC)问题时希望看到的内容的一些想法：
——Rick Hudson
yrefmtwq9#
https://golang.org/cl/98335提到了这个问题：runtime: Expose MemStats for previous GC cycles.
runtime: Expose MemStats for previous GC cycles.
9条答案
按热度按时间toe950271#
/cc @aclements
bt1cpqcv2#
有人在做这个吗？如果没有，我可以尝试一下。
原型：78ec37e
它将
runtime.MemStats(几乎包含了gctrace=1打印的所有内容)放入内部循环缓冲区，并通过runtime.ReadAllMemStats()暴露出来。它还没有在/debug处理器上暴露任何内容。是否应该从GODEBUG中获取缓冲区大小？
plicqrtu3#
目前我所知的，没有人在做这件事，所以请随意。但如果我们只想要MemStats,我们可以直接调用ReadMemStats。通常我们想要知道每个阶段的CPU/墙钟时间，而这并不在里面，只有STW暂停墙钟时间。
也许最简单的方法是将额外的信息添加到MemStats中。但这将被Go兼容性承诺覆盖...
kcrjzv8t4#
也许实现这个目标最简单的方法是将额外的信息添加到MemStats中。但这将受到Go兼容性承诺的限制
我假设这里有一个拼写错误。因为评论说“由于向后兼容性，我们不能改变MemStats”。或者我漏掉了什么？
rbpvctlc5#
我假设(没有验证)这是指内部含义发生变化的字段，我们不能将这种变化传播到公共结构中，因为它可能会破坏现有的代码。添加字段应该是可以的。
rggaifut6#
有一个明确的检查，用于在添加新字段时失败。它于2010年添加：dc9a3b2#diff-17dbb5a92bd43f80a1909a1814e2d42eR82。
据我所知，当时部分代码是用C编写的，部分用Go编写；这个检查是为了确保两个大小匹配。但现在情况已经不同了。那么，我们可以安全地移除这个检查吗？
y4ekin9u7#
感谢您承担这项工作。无需通过添加GODEBUG标志来过度工程化代码。添加标志是一个非常重的更改。为了上下文，垃圾回收器目前只有1个标志，经过10个发布。代码应该选择一个合理的大小，并将其作为实现特定值进行记录。如果大小太小，我们可以在了解用例后向上调整...。
2018年2月28日星期三晚上7:11,Dhananjay Nakrani @***. >写道：有人在做这个吗？如果没有，我可以试试看。原型：78ec37e < JayNakrani@78ec37e>。它将运行时.MemStats输出到内部循环缓冲区，并通过runtime.ReadAllMemStats()公开。它尚未在/debug处理程序上公开任何内容。是否应该从GODEBUG中获取缓冲区大小？—您收到此邮件是因为您订阅了此线程。直接回复此电子邮件，查看GitHub上的<#23815 (comment)>或静音线程< https://github.com/notifications/unsubscribe-auth/AA7Wn4TDetKNLbohW8LCGI-NMP6xPMaaks5tZzyrgaJpZM4SEU3A > 。
kkih6yb88#
关于在合理的缓冲区预算下，有人调试垃圾回收(GC)问题时希望看到的内容的一些想法：
这是一个固定的50个周期的缓冲区，覆盖了最后10K个GC周期。
——Rick Hudson
yrefmtwq9#
https://golang.org/cl/98335提到了这个问题：
runtime: Expose MemStats for previous GC cycles.