当前位置: 首页 > 面试题库 >

谷歌ndb库内存泄漏

华泽语
2023-03-14
问题内容

我想“ndb”库有内存泄漏,但我找不到在哪里。
有没有办法避免下面描述的问题?
你有更准确的测试方法来找出问题所在吗
是?

我就是这样再现这个问题的:
我用2个文件创建了一个极简的Google应用程序引擎。
附录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”的应用程序。
之后,每次对/的调用都会增加实例使用的内存。直到
由于错误“超出了128 MB的软专用内存限制,它将停止
总共为5个请求提供服务后为143 MB。

注意:这个问题可以用“webapp2”以外的其他框架重现,
就像网页.py


问题答案:

经过更多的调查,在谷歌工程师的帮助下,我发现
对我的记忆力消耗的两种解释。
上下文和线程
ndb.上下文是一个“线程本地”对象,只有在新的
请求进入线程。所以线程在请求之间保持它。很多
线程可能存在于一个GAE实例中,它可能需要数百个请求
在第二次使用线程并清除其上下文之前。
这不是内存泄漏,但内存中的上下文大小可能超过
小GAE实例中的可用内存。
解决方法:
不能配置GAE实例中使用的线程数。的确如此
最好使每个上下文尽可能小。避免上下文缓存,并清除
每次请求后都会被删除。
事件队列
NDB似乎不能保证事件队列在一个
请求。同样,这不是内存泄漏。但它在你的生活中留下了未来
线程上下文,回到第一个问题。
解决方法:
将所有使用NDB的代码包装为@ndb.toplevel公司.



 类似资料:
  • 我在SupportMapFragmet上阅读了这篇文档,它说: 从GoogleMap获得的任何对象都与视图相关联。重要的是不要持有超出视图生命周期的对象(例如标记)。否则会导致内存泄漏,因为视图无法释放。 我对此有点困惑,因为没有办法修改,除非您持有它们的引用,就像这里的许多问题所说的那样(像这样和这样)......所以我错过了什么吗? 我目前正在使用哈希映射将我的标记与其他对象关联起来,我看不出

  • 我有以下代码试图在一个大表上循环(~100k行;~30GB) 但是,我不断遇到以下错误: 处理此请求时,发现处理此请求的进程占用了太多内存,因此终止。这可能会导致应用程序的下一个请求使用新进程。如果经常看到此消息,则应用程序中可能存在内存泄漏。 ...有时候...... 在处理总共9个请求后,超过了128 MB的软私有内存限制,达到154 MB 我改变了我的代码,所以我总是在任何给定的时间只提取1

  • 问题内容: 我认为我的android应用正在泄漏内存。我不是绝对确定这是问题所在。 应用程序打开时经常崩溃,并且logcat尝试加载位图图像时会显示“内存不足”异常。 崩溃后,我重新打开了该应用程序,它运行正常。Logcat会显示许多“ gc”,并且JIT表会不时地向上调整大小,而不会向下调整,直到应用程序因内存不足错误而崩溃。 这听起来像是内存泄漏吗?如果是这样,我该如何定位和关闭泄漏点。 这是

  • 问题内容: 我一直在追寻内存泄漏(由“ valgrind –leak-check = yes”报告),它似乎来自ALSA。这段代码已经存在于自由世界中一段时间​​了,所以我猜这是我做错的事情。 输出看起来像这样: 并继续一些页面 这是由于我在一个项目中使用ALSA并开始看到这种巨大的泄漏……或者至少是所说泄漏的报告。 所以问题是:是我,ALSA或valgrind在这里遇到问题吗? 问题答案: ht

  • 问题内容: 我有一个长时间运行的脚本,如果让脚本运行足够长的时间,它将消耗系统上的所有内存。 在不详细介绍脚本的情况下,我有两个问题: 是否有可遵循的“最佳实践”,以防止泄漏发生? 有什么技术可以调试Python中的内存泄漏? 问题答案: 看看这篇文章:跟踪python内存泄漏 另外,请注意,垃圾收集模块实际上可以设置调试标志。看一下功能。此外,请查看Gnibbler的这段代码,以确定调用后已创建