在Go构建 Jmeter 板中，我经常看到OOM失败。
其中一些看起来像是配置错误或尺寸过小的构建器，而其他一些可能是运行时中的bug(例如#52433)。在其他情况下(例如#49957),导致失败的原因就不太清楚了。
能够区分这些情况和失败日志将会非常有帮助。今天，我们得到的是fatal error: runtime: out of memory,但通常情况下，运行时实际上并没有告诉我们发生这种情况时它使用了多少内存。(我们确实得到了一个goroutine转储，但goroutine转储与堆大小的关联并不紧密。)
@golang/runtime:当遇到out of memory条件时，让运行时尽可能地转储堆统计信息摘要会有多大难度？
5条答案
按热度按时间cngwdvgl1#
#52547 是另一个故障模式的例子，其中在运行时发生OOM的转储将是有帮助的。
tktrz96b2#
这也可能有助于解决#51019问题。
m3eecexj3#
这是直接做到的。在
memstats.heapStats上有一个"不安全读取"操作，这让你大部分时间都在那里(可能需要修改，以便所有的读取都是原子性的，只是为了让这个努力更好一点)。我们还可以转储剩下的统计数据，这些只是memstats中的sysMemStat类型的字段(在我未完成的重构CLs之前，这可能不是100%正确的，但之后会是)。这一切都是原子性的(我认为还需要一些数学),不需要锁。vlju58qv4#
我可以在我的堆栈顶部写这个CL。
1cklez4t5#
抱歉，我从未真正着手处理这个问题。我会自己先进行筛选。