Python无限期挂起试图删除深度递归对象答案

【问题标题】：Python hangs indefinitely trying to delete deeply recursive objectPython无限期挂起试图删除深度递归对象
【发布时间】：2019-10-07 06:54:43
【问题描述】：

我在 Python 中编写了一个三元搜索树，我注意到当树变得非常深时，尝试删除它会导致 Python 无限期挂起。这是产生这种行为的代码的剥离版本：

import random
import sys
from collections import deque


class Node():
    __slots__ = ("char", "count", "lo", "eq", "hi")

    def __init__(self, char):
        self.char = char
        self.count = 0

        self.lo = None
        self.eq = None
        self.hi = None


class TernarySearchTree():
    """Ternary search tree that stores counts for n-grams
    and their subsequences.
    """

    def __init__(self, splitchar=None):
        self.root = None
        self.splitchar = splitchar

    def insert(self, string):
        self.root = self._insert(string, self.root)

    def _insert(self, string, node):
        """Insert string at a given node.
        """
        if not string:
            return node

        char, *rest = string

        if node is None:
            node = Node(char)

        if char == node.char:
            if not rest:
                node.count += 1
                return node
            else:
                if rest[0] == self.splitchar:
                    node.count += 1
                node.eq = self._insert(rest, node.eq)

        elif char < node.char:
            node.lo = self._insert(string, node.lo)

        else:
            node.hi = self._insert(string, node.hi)

        return node


def random_strings(num_strings):
    random.seed(2)
    symbols = "abcdefghijklmnopqrstuvwxyz"

    for i in range(num_strings):
        length = random.randint(5, 15)
        yield "".join(random.choices(symbols, k=length))


def train():
    tree = TernarySearchTree("#")
    grams = deque(maxlen=4)

    for token in random_strings(27_000_000):
        grams.append(token)
        tree.insert("#".join(grams))

    sys.stdout.write("This gets printed!\n")
    sys.stdout.flush()


def main():
    train()

    sys.stdout.write("This doesn't get printed\n")
    sys.stdout.flush()


if __name__ == "__main__":
    main()

这会打印出“这会被打印”，而不是“不会被打印”。尝试手动删除对象具有相同的效果。如果我将插入的字符串数量从 2700 万减少到 2500 万，一切都很好 - Python 打印出两个语句，然后立即退出。我尝试运行 GDB，这是我得到的回溯：

#0  pymalloc_free.isra.0 (p=0x2ab537a4d580) at /tmp/build/80754af9/python_1546061345851/work/Objects/obmalloc.c:1797
#1  _PyObject_Free (ctx=<optimized out>, p=0x2ab537a4d580)
    at /tmp/build/80754af9/python_1546061345851/work/Objects/obmalloc.c:1834
#2  0x0000555555701c18 in subtype_dealloc ()
    at /tmp/build/80754af9/python_1546061345851/work/Objects/typeobject.c:1256
#3  0x0000555555738ce6 in _PyTrash_thread_destroy_chain ()
    at /tmp/build/80754af9/python_1546061345851/work/Objects/object.c:2212
#4  0x00005555556cd24f in frame_dealloc (f=<optimized out>)
    at /tmp/build/80754af9/python_1546061345851/work/Objects/frameobject.c:492
#5  function_code_fastcall (globals=<optimized out>, nargs=<optimized out>, args=<optimized out>, co=<optimized out>)
    at /tmp/build/80754af9/python_1546061345851/work/Objects/call.c:291
#6  _PyFunction_FastCallKeywords () at /tmp/build/80754af9/python_1546061345851/work/Objects/call.c:408
#7  0x00005555557241a6 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>)
    at /tmp/build/80754af9/python_1546061345851/work/Python/ceval.c:4616
#8  _PyEval_EvalFrameDefault () at /tmp/build/80754af9/python_1546061345851/work/Python/ceval.c:3124
#9  0x00005555556ccecb in function_code_fastcall (globals=<optimized out>, nargs=0, args=<optimized out>, 
    co=<optimized out>) at /tmp/build/80754af9/python_1546061345851/work/Objects/call.c:283
#10 _PyFunction_FastCallKeywords () at /tmp/build/80754af9/python_1546061345851/work/Objects/call.c:408
#11 0x00005555557241a6 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>)
    at /tmp/build/80754af9/python_1546061345851/work/Python/ceval.c:4616
#12 _PyEval_EvalFrameDefault () at /tmp/build/80754af9/python_1546061345851/work/Python/ceval.c:3124
#13 0x00005555556690d9 in _PyEval_EvalCodeWithName ()
    at /tmp/build/80754af9/python_1546061345851/work/Python/ceval.c:3930
#14 0x0000555555669fa4 in PyEval_EvalCodeEx () at /tmp/build/80754af9/python_1546061345851/work/Python/ceval.c:3959
#15 0x0000555555669fcc in PyEval_EvalCode (co=co@entry=0x2aaaaac08300, globals=globals@entry=0x2aaaaaba8168, 
    locals=locals@entry=0x2aaaaaba8168) at /tmp/build/80754af9/python_1546061345851/work/Python/ceval.c:524
#16 0x0000555555783664 in run_mod () at /tmp/build/80754af9/python_1546061345851/work/Python/pythonrun.c:1035
#17 0x000055555578d881 in PyRun_FileExFlags ()
    at /tmp/build/80754af9/python_1546061345851/work/Python/pythonrun.c:988
#18 0x000055555578da73 in PyRun_SimpleFileExFlags ()
    at /tmp/build/80754af9/python_1546061345851/work/Python/pythonrun.c:429
#19 0x000055555578db3d in PyRun_AnyFileExFlags ()
    at /tmp/build/80754af9/python_1546061345851/work/Python/pythonrun.c:84
#20 0x000055555578eb2f in pymain_run_file (p_cf=0x7fffffffd240, filename=0x5555558c5440 L"minimal.py", 
    fp=0x5555559059a0) at /tmp/build/80754af9/python_1546061345851/work/Modules/main.c:427
#21 pymain_run_filename (cf=0x7fffffffd240, pymain=0x7fffffffd350)
    at /tmp/build/80754af9/python_1546061345851/work/Modules/main.c:1627
#22 pymain_run_python (pymain=0x7fffffffd350) at /tmp/build/80754af9/python_1546061345851/work/Modules/main.c:2876
#23 pymain_main () at /tmp/build/80754af9/python_1546061345851/work/Modules/main.c:3037
#24 0x000055555578ec4c in _Py_UnixMain () at /tmp/build/80754af9/python_1546061345851/work/Modules/main.c:3072
#25 0x00002aaaaaf0d3d5 in __libc_start_main () from /lib64/libc.so.6
#26 0x0000555555733982 in _start () at ../sysdeps/x86_64/elf/start.S:103

如果我尝试从该点开始逐步执行，执行将循环通过 obmalloc.c 中的三行 - GDB 在第 1796-98 行表示，但数字似乎已关闭并且回溯中的文件（在 /tmp/ ) 不存在。

这发生在 Python 3.7.3 和 3.6 上，尽管导致挂起所需的字符串数量不同（两个版本都发生了 2700 万个）。此时所需的内存约为 80 GB，打印第一条语句需要 45 分钟。我实际使用的版本是用cython编写的，减少了内存和运行时间，但面临同样的问题。

即使插入了十亿个字符串，也可以按预期使用该对象。保持对象处于活动状态（从函数中返回或将其放入 globals()）将问题推迟到 Python 退出 - 所以至少我可以确保所有工作都在那时完成，但我真的很想知道发生了什么这里错了。

编辑：我通过 conda (4.6.2) 安装了 python，并且我在一个 linux 服务器节点上：

> uname -a
Linux computingnodeX 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

【问题讨论】：

“无限期”是什么意思（你等了多久）？进程是否消耗 CPU 周期？
我发布的那个版本让我运行了几个小时，这个过程从来没有空闲过。我实际使用的那个运行了好几天，从未终止过。正如我所说，如果字符串的数量稍微少一点，它会立即退出。
/tmp/build/80754af9/python_1546061345851/work 看起来像是嵌入到可执行文件中的路径——在构建 Python 的时间和地点，源代码位于构建服务器上。
您实际拥有多少物理 RAM？如果您要交换到磁盘，此问题可能会加剧。
我在服务器上，我已经多次运行脚本，有时它有 150GB 分配给它，所以我认为它不会去交换。如果我没记错的话，作业分配器甚至不允许使用交换空间，如果它使用太多内存，它只会终止作业。

标签： python memory memory-management tree recursive-datastructures

【解决方案1】：

更新

在错误报告中，一台巨型机器上的运行显示回收树存储的时间从近 5 小时减少到大约 70 秒：

master:

build time 0:48:53.664428
teardown time 4:58:20.132930

patched:

build time 0:48:08.485639
teardown time 0:01:10.46670

（建议修复）

这是针对 CPython 项目的 pull request，该项目建议通过完全删除搜索来“解决此问题”。它适用于我的 10 倍小测试用例，但我无法使用任何接近足够 RAM 的机器来运行原始测试用例。所以我在等待一个在合并 PR 之前这样做的人（谁知道？这里可能有不止一个“大量对象”设计缺陷）。

原始回复

感谢您提供了重现您的问题的可执行示例！唉，我不能运行它——需要比我拥有的更多的内存。如果我将字符串的数量减少 10 倍，我最终会在大约 8GB 的 RAM 中得到大约 100,000,000 个Node 实例，并且垃圾收集需要大约 45 秒才能拆除树（Python 3.7.3）。所以我猜你有大约 10 亿个 Node 实例。

我希望您不会收到回复，因为这里没有已知的“一般问题”，而且它甚至需要如此庞大的机器才能尝试。 python-dev 邮件列表可能是一个更好的提问地方，或者在 https://bugs.python.org 上打开问题。

运行结束时垃圾回收非常缓慢的通常原因是内存被换出到磁盘，然后以“随机”顺序将对象读回 RAM 需要“比正常”长数千倍的时间, 把它们拆掉。不过，我假设这里没有发生这种情况。如果是这样，CPU 使用率通常会下降到接近 0，因为进程大部分时间都在等待磁盘读取。

在底层 C 库的 malloc/free 实现中会遇到一些不好的模式。但这在这里似乎也不太可能，因为这些对象足够小，以至于 Python 只向 C 请求“大块” RAM 并自行分割它们。

所以我不知道。因为不能排除任何可能，您还应该详细说明您正在使用的操作系统，以及 Python 的构建方式。

只是为了好玩，您可以试试这个，以了解事情在停止之前能走多远。先把这个方法加到Node：

def delete(self):
    global killed
    if self.lo:
        self.lo.delete()
        self.lo = None
    if self.eq:
        self.eq.delete()
        self.eq = None
    if self.hi:
        self.hi.delete()
        self.hi = None
    killed += 1
    if killed % 100000 == 0:
        print(f"{killed:,} deleted")

在train()的末尾，添加：

tree.root.delete()

将对main()的调用替换为：

killed = 0
main()
print(killed, "killed")

这可能会或可能不会揭示一些有趣的事情。

不为别人而挂

我在python-dev mailing list 上发布了一条关于此的说明，到目前为止，有人私下回复：

我开始使用 Python 3.7.3 | conda-forge 打包| （默认，2019 年 3 月 27 日，23:01:00） [GCC 7.3.0] :: Anaconda, Inc. on linux

$ python fooz.py
This gets printed!
This doesn't get printed

确实需要大约 80 GB 的 RAM 和几个小时，但没有卡住。

所以，除非出现其他人可以复制它，否则我们可能在这里不走运。您至少需要提供有关您正在使用的操作系统以及 Python 是如何构建的更多信息。

【讨论】：

谢谢！我可以确认这一点：我现在给了脚本更多时间，它确实在四个多小时后终止。确实创建了超过 10 亿个节点。我正在使用的完整脚本插入了近十亿个字符串，并且需要大约四倍的内存——从树对象被取消引用并且永不终止的那一刻起，它需要三天的时间。因此，删除树所需的时间似乎在 10 亿左右不连续地增加，并且从那里开始不会线性扩展。那么，接下来我该怎么办？
哦，我还尝试按照您的建议手动跟踪删除（和创建），直到结束。似乎一开始删除的速度要快得多（将前 1 亿个节点设置为 None 只占下一个 1 亿的一小部分，我猜 GC 开始了），甚至可能会变得更糟。对此不确定，我还没有绘制在我输入的时间戳上删除的节点数，但它看起来像是在滚动日志。
谢谢，克里斯蒂安！如果可能的话，请跟进@methane 的建议。在我链接到的 python-dev 线程中有一个更技术性的讨论，现在看起来你很可能被大量“竞技场”的二次时间排序所困扰（不，我不希望有人知道这意味着什么，除非他们非常熟悉 Python 的内存内部结构——重要的是“二次时间”）。
是的，我只是在等待甲烷响应。问题当然是我的代码将被其他人使用，并告诉他们用不同的 arena 大小重新编译 python 或使用不同的分配器并不是一个真正的选择。我想我知道竞技场是什么，但我不明白为什么需要对它们进行排序以进行释放（或者每隔几个块就会发生这种情况，以便为新的分配做准备？）。排序所用的二次时间并不能解释当我从 25 到 2700 万插入时突然增加，对吧？
排序时间是概率性的，并且具有最坏情况的二次时间。数据中的任何变化可能使任何个别情况从线性时间变为二次时间。在任何情况下，Stackoverflow cmets 都不适合对技术细节进行冗长的解释 - 如果需要，请转到 python-dev。 Arenas 按照空闲池数量的增加进行排序，从最繁忙的 arena 中获取新的 pools，既可以增加内存的局部性，也可以让很少使用的 arena 有最好的机会变成完全空的（因此可以将它们返回到系统中）。跨度>

【解决方案2】：

您可以尝试重新编译 Python 吗？

在obmalloc.c中，有ARENA_SIZE宏定义为：

#define ARENA_SIZE              (256 << 10)     /* 256KB */

此默认值未针对超大内存系统进行优化。

您的脚本需要很长时间才能按其中的空闲池数量对竞技场进行排序。最坏的情况可能是 O(N^2)，当许多 arena 有相同数量的空闲池时。

您的脚本以随机顺序释放内存块，这接近于最坏的情况。

N 是这里的竞技场数量。当您将ARENA_SIZE 更改为(1024 << 10) 时， arena 大小为 4x，N 变为 1/4，N^2 变为 1/16。

如果不能重新编译 Python，可以使用 malloc 代替 pymalloc。

$ PYTHONMALLOC=malloc python3 yourscript.py

您可以使用 jemalloc 或使用 LD_PRELOAD 环境变量的 tcmalloc 覆盖 malloc。

【讨论】：

如何在 ARENA_SIZE 改变的情况下重新编译 python？
你知道如何从源代码构建 Python（不做任何更改）吗？如果是这样，请执行相同的操作，但首先将他指出的行中的“256”更改为“1024”。但如果没有，请阅读您正在使用的操作系统的文档。
@methane，仅供参考，在我的小得多（10 倍）的情况下，使此更改将总释放时间从大约 45 秒减少到大约 10 秒。在 python-dev 上，我建议了一种替换“排序”的方法" 使用恒定时间的链表操作（这将需要更改大量代码）。
我可以确认这一点。将 ARENA_SIZE 更改为 (256
使用 PYTHONMALLOC=malloc，插入时间几乎是原来的两倍，但释放只需要 2 分钟！