Question

我们有一个App Engine应用程序，可以将大量相对较大的文件写入Google Cloud Store。这些文件是动态创建的CSV，因此我们使用Python的StringIO.StringIO作为缓冲区，csv.writer作为写入该缓冲区的接口。

一般来说，我们的流程如下：

# imports as needed
# (gcs is the Google Cloud Store client)

buffer = StringIO.StringIO()
writer = csv.writer(buffer)

# ...
# write some rows
# ...

data = file_buffer.getdata()
filename = 'someFilename.csv'

try:
    with gcs.open(filename, content_type='text/csv', mode='w') as file_stream:
        file_stream.write(data)
        file_stream.close()

except Exception, e:
    # handle exception
finally:
    file_buffer.close()

据我们了解，csv.writer不需要自行关闭。相反，只需要关闭上面的buffer和file_stream。

我们在deferred中运行上述过程，由App Engine的任务队列调用。最终，我们在几次调用任务后得到以下错误：

在为11个请求提供服务后，超过128 MB的软私有内存限制（142 MB）

显然，我们的应用程序中存在内存泄漏。但是，如果上面的代码是正确的（我们承认可能不是这种情况），那么我们唯一的另一个想法是通过服务我们的请求来保存大量内存（如错误消息所示）。

因此，我们想知道在执行deferred期间App Engine是否保留了某些实体。我们还应该注意，尽管存在这些错误消息，但我们的CSV最终已成功写入。

Answer 1

描述的症状不是必然指示应用程序内存泄漏。可能的替代解释包括：

应用程序的基线内存占用（对于像python这样的脚本语言沙箱可能比实例启动时的占用空间大，请参阅Memory usage differs greatly (and strangely) between frontend and backend）对于配置为instance class的chose a higher memory instance class来说可能太高了app / module。修复 - dynamic scaling（作为副作用，也意味着更快的类实例）。或者，如果由于超出内存限制而导致的实例查杀率是可以容忍的，那么让GAE回收实例：）
活动高峰，特别是在启用多线程请求处理的情况下，意味着更高的内存消耗以及内存垃圾收集器的潜在过载。限制并行执行的请求数量，在较低优先级延迟任务处理中添加（较高）延迟以及降低每个实例的平均请求处理速率的其他类似措施可以帮助垃圾收集器有机会清除请求中的剩余数据。不应该损害可扩展性（使用How does app engine (python) manage memory across requests (Exceeded soft private memory limit)），因为其他实例将开始帮助实现活动高峰。

App Engine推迟：追踪内存泄漏

1 个答案: