google-app-engine - 追踪 Google App Engine Golang 应用程序中的内存泄漏？

Question

我看到了这个 Python 问题:App Engine Deferred: Tracking Down Memory Leaks

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

Exceeded soft private memory limit of 128 MB with 128 MB after servicing 384 requests total

...

After handling this request, the process that handled this request was found to be using too much memory and was terminated. This is likely to cause a new process to be used for the next request to your application. If you see this message frequently, you may have a memory leak in your application.

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

检查完应用程序后，我看不到任何明显的泄漏可能在哪里(例如，未关闭的缓冲区等)......所以无论它是什么，它都必须是一个非常小但可能很常见的地方错误。

因为这是在 GAE 上运行的，所以据我所知，我无法在本地很容易地分析它，因为那是运行时环境。 对于如何继续并确保正确回收内存有任何建议吗？——我是 Go 的新手，但到目前为止我很喜欢使用它。

Answer 1

作为起点，您可以尝试 pprof.WriteHeapProfile .它会写入任何 Writer，包括 http.ResponseWriter，因此您可以编写一个 View 来检查某些身份验证并为您提供堆配置文件。一个恼人的事情是，它实际上是在跟踪分配，而不是在 GC 之后分配的剩余。因此，从某种意义上说，它告诉您什么是 RAM-hungry，但并不专门针对泄漏。

标准的 expvar 包可以公开一些 JSON，包括 memstats，它告诉您有关 GC 和特定分配大小 (example) 的分配 和释放 的数量。如果存在泄漏，您可以使用 allocs-frees 来了解随时间增长的是大分配还是小分配，但这不是很细粒度。

最后，有 a function to dump the current state of the heap ，但我不确定它在 GAE 中是否有效，而且似乎很少使用。

请注意，为了减少 GC 工作，Go 进程增长到其实际实时数据的两倍左右，作为正常稳态操作的一部分。 (它在 GC 之前增长的确切百分比取决于 runtime.GOGC，人们有时会增加它以节省收集器工作以换取使用更多内存。)一个(非常旧的)线程建议 App Engine processes regulate GC like any other ，尽管自 2011 年以来他们就可以对其进行调整。无论如何，如果您分配缓慢(对您有好处!)，您应该预计进程增长缓慢；只是在每个收集周期后使用率应该再次下降。