App Engine的递延：跟踪内存泄漏App Engine的递延：跟踪内存泄漏(App Engin

我们有一个写入规模比较大到谷歌云存储的许多文件App Engine应用程序。这些文件是动态创建的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 。我们还应该注意到，我们的CSV最终成功写入，尽管这些错误消息。

描述的症状不一定是应用程序内存泄漏的指示。潜在交替的解释包括：

该应用的基线存储器足迹（其中用于脚本语言沙箱状蟒可以比在实例启动时足迹更大，参见内存使用情况有很大的不同（和奇怪的）前端和后端之间）可能过高的实例类配置为应用程序/模块。要修复- 选择一个更高的存储器实例类（其作为副作用，也意味着更快的类实例）。或者，如果实例的杀戮由于超过内存限制的速度是可以容忍的，只是让GAE回收的情况下:)
活性的峰，特别是如果多线程处理请求被启用，意味着更高的内存消耗和存储器垃圾收集器的电势也超载。在优先级较低的任务延迟处理和减少每次的平均请求处理速率其他类似措施限制在并行执行的请求的数量，加入（较高）的延迟可以帮助得到垃圾收集器有机会从请求清理剩菜。可扩展性不应该受到伤害（与动态调整），其他情况下将启动，以帮助活性峰。