4

我最近遇到了一个问题,App Engine 会终止我的 Go 实例,因为它说它内存不足。实例的内存限制设置为 128Mb。

但是,我无法确定所有内存的分配位置。当我运行以下代码时:

var s runtime.MemStats
runtime.ReadMemStats(&s)
c.Debugf("allocated memory: %d", s.Alloc)

它告诉我,当分配的内存达到大约 39-40Mb 时,我的应用程序会因以下错误而终止:

在服务 1 个请求后,超过了 135.082 MB 的软私有内存限制

同样,当runtime.ReadMemStats(&s)指示我正在使用 20 Mb 时,App Engine 控制台会显示我的实例正在使用 92 Mb。重做相同的请求,runtime.ReadMemStats(&s)仍然显示 20Mb,而 App Engine 控制台显示 119Mb。

我已经禁用了appstats,仍然没有帮助。

我的大部分内存都被内存缓存用完了,我可以减少它以适应约束(或增加我的实例的内存限制),但我想知道所有内存都在哪里使用。如果有人能对此有所了解,或者如何正确分析 App Engine 上的内存使用情况,那将有很大帮助。

更新:设法在本地重现。

以下是一个示例应用程序,它在一个请求中分配一些整数,并在下一个请求中将它们垃圾收集:

// Package test implements a simple memory test for Google App Engine.
package test

import (
    "net/http"
    "runtime"

    "appengine"
)

var buffer []int64

func init() {
    http.HandleFunc("/", handler)
}

func handler(w http.ResponseWriter, r *http.Request) {
    var s runtime.MemStats
    c := appengine.NewContext(r)
    if len(buffer) == 0 {
        // Allocate 2^22 integers.
        runtime.ReadMemStats(&s)
        c.Debugf("Memory usage: %d bytes (%d system).", s.Alloc, s.Sys)
        buffer = make([]int64, 4*1024*1024)
        for i, _ := range buffer {
            buffer[i] = int64(i*i)
        }
        runtime.ReadMemStats(&s)
        c.Debugf("Memory usage increased to: %d bytes (%d system).", s.Alloc, s.Sys)
    } else {
        // Remove all references to the slice pointed to by buffer.
        // This should mark it for garbage collection.
        runtime.ReadMemStats(&s)
        c.Debugf("Memory usage: %d bytes (%d system).", s.Alloc, s.Sys)
        buffer = nil
        runtime.GC()
        runtime.ReadMemStats(&s)
        c.Debugf("After GC event: %d bytes (%d system).", s.Alloc, s.Sys)
    }
    w.WriteHeader(http.StatusTeapot)
}

使用开发服务器运行时:

$ ./go_appengine/dev_appserver.py test

2013/09/16 12:28:28 DEBUG: Memory usage: 833096 bytes (272681032 system).
2013/09/16 12:28:28 DEBUG: Memory usage increased to: 34335216 bytes (308332616 system).
INFO     2013-09-16 12:28:28,884 module.py:593] default: "GET / HTTP/1.1" 418 -
2013/09/16 12:28:29 DEBUG: Memory usage: 34345896 bytes (308332616 system).
2013/09/16 12:28:29 DEBUG: After GC event: 781504 bytes (308332616 system).
INFO     2013-09-16 12:28:29,560 module.py:593] default: "GET / HTTP/1.1" 418 -
2013/09/16 12:28:30 DEBUG: Memory usage: 791616 bytes (308332616 system).
2013/09/16 12:28:30 DEBUG: Memory usage increased to: 34337392 bytes (308332616 system).
INFO     2013-09-16 12:28:30,276 module.py:593] default: "GET / HTTP/1.1" 418 -
2013/09/16 12:28:36 DEBUG: Memory usage: 34347536 bytes (308332616 system).
2013/09/16 12:28:36 DEBUG: After GC event: 783632 bytes (308332616 system).
INFO     2013-09-16 12:28:36,224 module.py:593] default: "GET / HTTP/1.1" 418 -

看来内存分配和垃圾收集工作正常。但是,查看ps输出,似乎释放内存并不会减少进程的虚拟内存使用量:

$ ps axo command,vsize,rss | ag go_app
/usr/bin/python2.7 ./go_app 381248 56608
$ ps axo command,vsize,rss | ag go_app
/usr/bin/python2.7 ./go_app 676324 57652
$ ps axo command,vsize,rss | ag go_app
/usr/bin/python2.7 ./go_app 750056 57856
$ ps axo command,vsize,rss | ag go_app
/usr/bin/python2.7 ./go_app 750056 57856

运行底层 Go 实例的 Python 进程似乎一直在增长其虚拟内存,但它从未被释放。生产服务器上似乎也发生了类似的事情:实例运行时报告的分配内存与内核报告的已用内存不同。

正如@Kluyg 所建议的那样,管理控制台似乎显示了系统分配的内存,这是有道理的。

4

1 回答 1

5

根据文档 Alloc字段显示已分配且仍在使用的字节。然而,在垃圾收集语言中,当内存被 GC 释放时,它并不会立即返回给系统(它可以很快再次请求,所以为什么还要麻烦返回呢?)。所以你真正需要监控的是Sys字段,它计算从系统获得的字节数。您可能会对这篇文章感兴趣,了解如何最大限度地减少内存使用。

于 2013-09-16T16:15:08.097 回答