我的生产系统偶尔会出现内存泄漏，我无法在开发环境中重现。我在开发环境中使用了Python 内存分析器（特别是 Heapy）并取得了一些成功，但它无法帮助我处理无法重现的事情，而且我不愿意使用 Heapy 来检测我们的生产系统，因为它需要一段时间才能完成它的工作，并且它的线程远程接口在我们的服务器中无法正常工作。
我想我想要的是一种方法来转储生产 Python 进程（或至少 gc.get_objects）的快照，然后离线分析它以查看它在哪里使用内存。 如何获得这样的 python 进程的核心转储？ 一旦我有了一个，我该如何用它做一些有用的事情？
使用 Python 的gc垃圾收集器接口，sys.getsizeof()可以转储所有 Python 对象及其大小。这是我在生产中用于解决内存泄漏的代码：
rss = psutil.Process(os.getpid()).get_memory_info().rss
# Dump variables if using more than 100MB of memory
if rss > 100 * 1024 * 1024:
memory_dump()
os.abort()
def memory_dump():
dump = open("memory.pickle", 'wb')
xs = []
for obj in gc.get_objects():
i = id(obj)
size = sys.getsizeof(obj, 0)
# referrers = [id(o) for o in gc.get_referrers(obj) if hasattr(o, '__class__')]
referents = [id(o) for o in gc.get_referents(obj) if hasattr(o, '__class__')]
if hasattr(obj, '__class__'):
cls = str(obj.__class__)
xs.append({'id': i, 'class': cls, 'size': size, 'referents': referents})
cPickle.dump(xs, dump)
请注意，我只保存具有__class__属性的对象的数据，因为这些是我关心的唯一对象。应该可以保存完整的对象列表，但您需要注意选择其他属性。另外，我发现获取每个对象的引用非常慢，所以我选择只保存引用。无论如何，在崩溃之后，可以像这样读回生成的腌制数据：
with open("memory.pickle", 'rb') as dump:
objs = cPickle.load(dump)
Python 3.6 版本在这里：
import gc
import sys
import _pickle as cPickle
def memory_dump():
with open("memory.pickle", 'wb') as dump:
xs = []
for obj in gc.get_objects():
i = id(obj)
size = sys.getsizeof(obj, 0)
# referrers = [id(o) for o in gc.get_referrers(obj) if hasattr(o, '__class__')]
referents = [id(o) for o in gc.get_referents(obj) if hasattr(o, '__class__')]
if hasattr(obj, '__class__'):
cls = str(obj.__class__)
xs.append({'id': i, 'class': cls, 'size': size, 'referents': referents})
cPickle.dump(xs, dump)
我将根据我最近的经验扩展布雷特的答案。Dozer 包维护得很好， 尽管有一些进步，比如tracemalloc在 Python 3.4 中添加了 stdlib，但它的gc.get_objects计数图表是我解决内存泄漏的首选工具。下面我使用dozer > 0.7的是在撰写本文时尚未发布的（嗯，因为我最近在那里贡献了几个修复）。
让我们看一个不平凡的内存泄漏。我将在这里使用Celery 4.4 并最终发现一个导致泄漏的功能（并且因为它是一种错误/功能类型的东西，它可以被称为纯粹的错误配置，由于无知）。所以有一个 Python 3.6 venv我pip install celery < 4.5. 并具有以下模块。
演示.py
import time
import celery
redis_dsn = 'redis://localhost'
app = celery.Celery('demo', broker=redis_dsn, backend=redis_dsn)
@app.task
def subtask():
pass
@app.task
def task():
for i in range(10_000):
subtask.delay()
time.sleep(0.01)
if __name__ == '__main__':
task.delay().get()
基本上是一个安排一堆子任务的任务。会出什么问题？
我将procpath用来分析 Celery 节点的内存消耗。pip install procpath. 我有 4 个终端：
procpath record -d celery.sqlite -i1 "$..children[?('celery' in @.cmdline)]"记录 Celery 节点的进程树统计信息docker run --rm -it -p 6379:6379 redis运行 Redis，它将作为 Celery 代理和结果后端celery -A demo worker --concurrency 2用 2 个工作人员运行节点python demo.py最后运行示例(4) 将在 2 分钟内完成。
然后我使用sqliteviz（预建版本）来可视化procpath记录器的内容。我放下celery.sqlite那里并使用这个查询：
SELECT datetime(ts, 'unixepoch', 'localtime') ts, stat_pid, stat_rss / 256.0 rss
FROM record
在 sqliteviz 中，我使用 , 创建折线图跟踪X=ts，Y=rss并添加 split transform By=stat_pid。结果图为：
任何与内存泄漏作斗争的人都可能非常熟悉这种形状。
现在是时候了dozer。我将展示非仪器案例（如果可以的话，您可以以类似的方式检测您的代码）。要将 Dozer 服务器注入目标进程，我将使用Pyrasite。关于它有两点需要了解：
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope，这可能存在安全风险有了这个警告，我：
pip install https://github.com/mgedmin/dozer/archive/3ca74bd8.zip（我上面提到的应该是0.8）pip install pillow（dozer用于制图）pip install pyrasite之后，我可以在目标进程中获取 Python shell：
pyrasite-shell 26572
并注入以下内容，这将使用 stdlib 的wsgiref服务器运行 Dozer 的 WSGI 应用程序。
import threading
import wsgiref.simple_server
import dozer
def run_dozer():
app = dozer.Dozer(app=None, path='/')
with wsgiref.simple_server.make_server('', 8000, app) as httpd:
print('Serving Dozer on port 8000...')
httpd.serve_forever()
threading.Thread(target=run_dozer, daemon=True).start()
在浏览器中打开http://localhost:8000应该会看到如下内容：
之后，我python demo.py再次从 (4) 运行并等待它完成。然后在 Dozer 中，我将“Floor”设置为 5000，这就是我所看到的：
随着子任务的调度，与 Celery 相关的两种类型会增长：
celery.result.AsyncResultvine.promises.promiseweakref.WeakMethod具有相同的形状和数字，一定是由同一事物引起的。
此时，从泄漏类型和趋势来看，您的情况可能已经很清楚了。如果不是，Dozer 每个类型都有“TRACE”链接，它允许跟踪（例如查看对象的属性）选择的对象的引用者（gc.get_referrers）和引用者（gc.get_referents），并再次遍历图继续该过程。
但是一张图片说一千个字，对吧？因此，我将展示如何使用objgraph来呈现所选对象的依赖关系图。
pip install objgraphapt-get install graphviz然后：
python demo.py再次从 (4)运行floor=0，filter=AsyncResult
然后在 Pyrasite shell 中运行：
objgraph.show_backrefs([objgraph.at(140254427663376)], filename='backref.png')
PNG 文件应包含：
基本上有一些Context对象包含一个list被调用的对象，而该对象_children又包含许多celery.result.AsyncResult泄漏的实例。Filter=celery.*context我看到的是推土机的变化：
所以罪魁祸首是celery.app.task.Context。搜索该类型肯定会引导您进入Celery 任务页面。在那里快速搜索“孩子”，它是这样说的：
trail = True如果启用，请求将跟踪此任务启动的子任务，并且此信息将与结果一起发送 (
result.children)。
通过如下设置禁用跟踪trail=False：
@app.task(trail=False)
def task():
for i in range(10_000):
subtask.delay()
time.sleep(0.01)
然后再次从 (3) 和python demo.py(4) 重新启动 Celery 节点，显示此内存消耗。
问题解决了！
您能否在生产站点上记录流量（通过日志），然后在装有 python 内存调试器的开发服务器上重新播放？（我推荐推土机： http: //pypi.python.org/pypi/Dozer）
使您的程序转储核心，然后使用gdb在足够相似的盒子上克隆该程序的一个实例。有一些特殊的宏可以帮助调试 gdb 中的 python 程序，但是如果你可以让你的程序同时提供一个远程 shell，你可以继续程序的执行，并用 python 查询它。
我从来没有这样做过，所以我不能 100% 确定它会起作用，但也许这些指针会有所帮助。
我不知道如何转储整个 python 解释器状态并恢复它。这会很有用，我会密切关注这个答案，以防其他人有想法。
如果您知道内存泄漏的位置，您可以添加检查对象的引用计数。例如：
x = SomeObject()
... later ...
oldRefCount = sys.getrefcount( x )
suspiciousFunction( x )
if (oldRefCount != sys.getrefcount(x)):
print "Possible memory leak..."
您还可以检查高于对您的应用程序合理的某个数字的引用计数。更进一步，您可以修改 python 解释器以通过用您自己的宏替换Py_INCREF和宏来执行这些类型的检查。Py_DECREF不过，这在生产应用程序中可能有点危险。
这是一篇文章，其中包含有关调试此类事物的更多信息。它更适合插件作者，但大部分都适用。
Meliae看起来很有希望：
这个项目类似于 heapy（在“guppy”项目中），试图了解内存是如何分配的。
目前，它的主要区别在于它将计算内存消耗的汇总统计等任务与实际扫描内存消耗的任务分开。它这样做是因为我经常想弄清楚我的进程中发生了什么，而我的进程正在消耗大量内存（1GB 等）。它还可以显着简化扫描程序，因为我在尝试分析 python 对象内存消耗时不分配 python 对象。