我们有一个 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需要关闭。
我们在a中运行上述过程deferred，由 App Engine 的任务队列调用。最终，在几次调用我们的任务后，我们收到以下错误：
总共处理 11 个请求后，超出了 128 MB 的软专用内存限制，达到 142 MB
显然，我们的应用程序中存在内存泄漏。但是，如果上面的代码是正确的（我们承认情况可能并非如此），那么我们唯一的其他想法是通过服务我们的请求而保留了一些大量的内存（如错误消息所示）。
因此，我们想知道 App Engine 在执行过程中是否保留了一些实体deferred。我们还应该注意到，尽管有这些错误消息，我们的 CSV 最终还是成功写入的。
所描述的症状不是一定应用程序内存泄漏的指示。潜在的替代解释包括：
- 应用程序的基线内存占用量（对于像 python 这样的脚本语言沙箱来说，它可能比实例启动时的占用量更大，请参阅前端和后端之间的内存使用情况差异很大（而且很奇怪） https://stackoverflow.com/questions/34268508/memory-usage-differs-greatly-and-strangely-between-frontend-and-backend/34269395#34269395）对于实例类 https://cloud.google.com/appengine/docs/python/modules/#Python_Instance_scaling_and_class为应用程序/模块配置。修理 -选择了更高内存的实例类 https://cloud.google.com/appengine/docs/python/config/appconfig#scaling_and_instance_types（作为副作用，这也意味着更快的类实例）。或者，如果由于超出内存限制而导致的实例终止率是可以忍受的，那么就让 GAE 回收实例:)
- 活动高峰，特别是在启用多线程请求处理的情况下，意味着更高的内存消耗以及内存垃圾收集器的潜在过载。限制并行执行的请求数量、在较低优先级的延迟任务处理中添加（较高）延迟以及降低每个实例的平均请求处理速率的其他类似措施可以帮助垃圾收集器有机会清除请求中的剩余内容。可扩展性不应受到损害（动态缩放 https://cloud.google.com/appengine/docs/python/scaling#scaling_dynamic_instances），因为其他实例将启动以帮助应对活动高峰。
相关问答：
- 应用程序引擎（python）如何跨请求管理内存（超出软私有内存限制） https://stackoverflow.com/questions/32981118/how-does-app-engine-python-manage-memory-across-requests-exceeded-soft-privat
- Google App Engine DB 查询内存使用情况 https://stackoverflow.com/questions/31853703/google-app-engine-db-query-memory-usage
- Google ndb 库中的内存泄漏 https://stackoverflow.com/questions/33036334/memory-leak-in-google-ndb-library
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
