Google ndb 库中的内存泄漏答案

【问题标题】：Memory leak in Google ndb libraryGoogle ndb 库中的内存泄漏
【发布时间】：2015-10-09 10:49:31
【问题描述】：

我认为ndb 库中存在内存泄漏，但我找不到位置。

有没有办法避免下面描述的问题？
您是否有更准确的测试想法来找出问题所在？

这就是我重现问题的方式：

我创建了一个包含 2 个文件的极简 Google App Engine 应用程序。
app.yaml:

application: myapplicationid
version: demo
runtime: python27
api_version: 1
threadsafe: yes


handlers:
- url: /.*
  script: main.APP

libraries:
- name: webapp2
  version: latest

main.py:

# -*- coding: utf-8 -*-
"""Memory leak demo."""
from google.appengine.ext import ndb
import webapp2


class DummyModel(ndb.Model):

    content = ndb.TextProperty()


class CreatePage(webapp2.RequestHandler):

    def get(self):
        value = str(102**100000)
        entities = (DummyModel(content=value) for _ in xrange(100))
        ndb.put_multi(entities)


class MainPage(webapp2.RequestHandler):

    def get(self):
        """Use of `query().iter()` was suggested here:
            https://code.google.com/p/googleappengine/issues/detail?id=9610
        Same result can be reproduced without decorator and a "classic"
            `query().fetch()`.
        """
        for _ in range(10):
            for entity in DummyModel.query().iter():
                pass # Do whatever you want
        self.response.headers['Content-Type'] = 'text/plain'
        self.response.write('Hello, World!')


APP = webapp2.WSGIApplication([
    ('/', MainPage),
    ('/create', CreatePage),
])

我上传了一次名为 /create 的应用程序。
之后，每次调用/ 都会增加实例使用的内存。直到由于错误Exceeded soft private memory limit of 128 MB with 143 MB after servicing 5 requests total 而停止。

内存使用图示例（可以看到内存增长和崩溃）：

注意：这个问题可以用webapp2以外的其他框架重现，比如web.py

【问题讨论】：

我想应该是ndb in-context cache。
我对 python 一无所知，但阅读您的代码我会说您的内存不足，因为您的 ndb.put_multi 试图在单个事务中插入 100 个实体。这可能是导致分配这么多内存的原因。超出软私有内存限制可能是因为当您的下一个请求增加内存负载时，您的事务仍在运行。如果您在调用之间等待一段时间（分别等待事务完成），则不应发生这种情况。如果响应时间急剧增加，App Engine 也应该启动一个额外的实例。
@DanielRoseman “上下文缓存仅在单个线程的持续时间内持续存在。”如果您清除上下文缓存或设置禁用缓存的策略，内存使用量增加得更慢，但泄漏仍然存在。
@konqi 调用MainPage 而不是CreatePage时发生内存泄漏。
@greg 哦，我的错。如果主页获取数据存储中存在的所有内容的 10 倍，那不会导致高内存消耗吗？如果您清除数据存储区，问题是否仍然存在？

标签： python google-app-engine memory-leaks app-engine-ndb webapp2

【解决方案1】：

经过更多调查，并在谷歌工程师的帮助下，我找到了两个解释我的内存消耗的原因。

上下文和线程

ndb.Context 是一个“线程本地”对象，只有在线程中有新请求时才会被清除。所以线程在请求之间保持它。 GAE 实例中可能存在许多线程，并且在第二次使用线程并清除上下文之前可能需要数百个请求。
这不是内存泄漏，但内存中的上下文大小可能会超过小型 GAE 实例中的可用内存。

解决方法：
您不能配置 GAE 实例中使用的线程数。因此，最好尽量减少每个上下文。避免上下文缓存，并在每次请求后清除它。

事件队列

似乎 NDB 不保证在请求后清空事件队列。同样，这不是内存泄漏。但它会在你的线程上下文中留下Futures，你又回到了第一个问题。

解决方法：
使用 @ndb.toplevel 包装所有使用 NDB 的代码。

【讨论】：

Greg，如果这是预期行为还是错误，Google 工程师是否给过您任何指示？对我来说，这当然像是一个错误。
我已经完成了上述所有工作，甚至就这个问题联系了谷歌支持......他们甚至不承认它的存在。我仍然得到一个非常严重的泄漏，以至于一个只做更多的迭代 ndb 条目并将结果排队到 bigquery 的进程在几分钟内泄漏了 500M 的内存。还有其他可能的解释吗？

【解决方案2】：

NDB 存在一个已知问题。你可以阅读关于it here 并且有一个工作around here：

使用 fetch_page 观察到的不确定性是由于 eventloop.rpcs 的迭代顺序，它被传递给 datastore_rpc.MultiRpc.wait_any() 并且 apiproxy_stub_map.__check_one 从迭代器中选择 last rpc .

page_size 为 10 的 rpc 执行 count=10，limit=11，这是一种强制后端更准确地确定是否有更多结果的标准技术。这将返回 10 个结果，但由于解开 QueryIterator 的方式存在错误，因此添加了一个 RPC 来获取最后一个条目（使用获得的游标和 count=1）。 NDB 然后返回这批实体而不处理此 RPC。我相信这个 RPC 在随机选择之前不会被评估（如果 MultiRpc 在必要的 rpc 之前使用它），因为它不会阻塞客户端代码。

解决方法：使用 iter()。此函数没有此问题（计数和限制将相同）。 iter() 可用于解决与上述问题引起的 fetch page 相关的性能和内存问题。

【讨论】：

我已经阅读了这些线程，但是使用iter() 并不能防止内存泄漏。
您应该将您的发现发布到那里的线程上，以便工程师可以看到它。
格雷格，很高兴在巴黎和你聊天。我建议改用“iter()”编辑代码，并提供内存泄漏的证据。

【解决方案3】：

一种可能的解决方法是在 get 方法上使用 context.clear_cache() 和 gc.collect()。

def get(self):

    for _ in range(10):
        for entity in DummyModel.query().iter():
            pass # Do whatever you want
    self.response.headers['Content-Type'] = 'text/plain'
    self.response.write('Hello, World!')
    context = ndb.get_context()
    context.clear_cache()
    gc.collect()

【讨论】：