跟踪谷歌应用程序引擎Golang应用程序中的内存泄漏？

Question

我看到了这个Python问题：应用引擎延迟：跟踪内存泄漏

...同样，我也遇到了这个可怕的错误：

在为总共384个请求提供服务后，超过了128 MB的软专用内存限制

...

处理此请求后，发现处理此请求的进程占用了太多内存，因此被终止。这可能会导致应用程序的下一个请求使用新进程。如果经常看到此消息，则应用程序中可能存在内存泄漏。

根据另一个问题，可能是“实例类”太小，无法运行这个应用程序，但是在增加它之前，我想确定一下。

检查应用程序后，我看不到任何明显的泄漏位置（例如，未关闭的缓冲区等）。。。所以不管是什么，这都是一个很小但可能很常见的错误。

因为这是在GAE上运行的，所以就我所知，这是运行时环境，我不能非常容易地在本地配置它。有人能对如何继续并确保内存被正确回收提出建议吗？-我对去有点陌生，但到目前为止我很喜欢和它一起工作。

Answer 1

检查应用程序是否确实存在内存泄漏的一种可能方法是临时升级实例类并检查内存使用模式（在实例页面的开发人员控制台中，选择相应模块版本的内存使用视图）。

如果模式最终变平，实例不再重新启动，那么您的实例类确实太低了。完成：）

如果使用模式持续增长（与应用程序的活动成比例），那么你确实有内存泄漏。在这个练习中，如果您设法将图形增长区域与应用程序的某些活动相关联，您也可以缩小搜索区域。

即使存在泄漏，使用更高的实例类也会增加实例重启之间的时间，甚至可能使它们可以容忍（例如，与动态管理实例的自动关闭相当）。这将允许将内存泄漏调查放在次要位置，并将重点放在更紧迫的问题上，如果您感兴趣的话。可以将此类重启视为实例刷新/自清理“功能”：

Answer 2

作为起点，您可以尝试pprof。WriteHeapProfile。它将写入任何编写器，包括http。ResponseWriter，这样您就可以编写一个视图来检查某些身份验证，并为您提供一个堆配置文件。令人恼火的是，它实际上是在跟踪分配，而不是GC之后剩余的分配。所以，从某种意义上说，它告诉你什么是内存饥饿，但并不针对具体的泄漏。

标准的expvar包可以公开一些JSON，包括memstats，它告诉您GCs以及特定大小分配的alloc和free的数量（例如）。如果出现泄漏，您可以使用allocs-frees来了解随时间增长的是大allocs还是小allocs，但这不是非常细粒度的。

最后，有一个函数可以转储堆的当前状态，但是我不确定它在GAE中是否有效，而且似乎很少使用。

请注意，为了降低GC的工作，作为正常稳态操作的一部分，Go进程的大小大约是其实际实时数据的两倍。（它在GC之前增长的确切百分比取决于runtime.GOGC，人们有时会增加它以节省收集器工作以换取使用更多内存。）一条（非常古老的）线索表明，应用程序引擎进程可以像其他进程一样调节GC，尽管自2011年以来，它们本可以对其进行调整。无论如何，如果你分配的很慢（对你有好处！）你应该期待缓慢的进程增长；只是在每个收集周期之后，使用率应该再次下降。