当内存中有巨大的数据结构无任何交换时，Python会持续运行10分钟以上在程序中的最后一条语句之后

问题描述

我需要解析一个巨大的gz文件（压缩后约为10GB，未压缩时约为100GB）。该代码在内存中创建数据结构（'data_struct'）。我运行的机器是Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz，具有16个CPU和足够的RAM（即200+ GB），运行CentOS-6.9。我已经使用Python3.6.3（CPython）中的类实现了这些东西，如下所示：

class my_class():
    def __init__(self):
        cmd = f'gunzip huge-file.gz'
        self.process = subprocess(cmd,stdout=subprocess.PIPE,shell=True)
        self.data_struct = dict()

    def populate_struct(self):
        for line in process.stdout:
            <populate the self.data_struct dictionary>
        
    def __del__():
        self.process.wait()
        #del self.data_struct  # presence/absence of this statement decreases/increases runtime respectively
#================End of my_class===================

def main():
    my_object = my_class()
    my_object.populate_struct()
    print(f'~~~~ Finished populate_struct() ~~~~')  # last statement in my program.
    ## Python keeps running at 100% past the previous statement for 10+mins

if __name__ == '__main__':
    main()
#================End of Main=======================

我的data_struct在内存中的常驻内存消耗（仅RAM，无交换）约为33GB。我做了$ top来查找Python进程的PID，并使用$ strace -p <PID> -o <out_file>跟踪了Python进程（以查看Python在做什么）。当它执行populate_struct()时，我可以在strace的out_file中看到Python正在使用mmap(NULL,262144,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x2b0684160000 之类的调用来创建data_struct。当Python运行超过最后一个print()语句时，我发现Python仅发出munmap()操作，如下所示：

munmap(0x2b3c75375000,41947136)        = 0
munmap(0x2b3c73374000,33558528)        = 0
munmap(0x2b4015d2a000,262144)          = 0
munmap(0x2b4015cea000,262144)          = 0
munmap(0x2b4015caa000,262144)          = 0
munmap(0x2b4015c6a000,262144)          = 0
munmap(0x2b4015c2a000,262144)          = 0
munmap(0x2b4015bea000,262144)          = 0
munmap(0x2b4015baa000,262144)          = 0
...
...

在最后一个print()语句之后，Python会在10分钟以上至12分钟之间的任何时间运行。一个观察结果是，如果我在del self.data_struct方法中有__del__()条语句，则只需要2分钟。我已经多次进行了这些实验，并且由于del self.data_struct中是否存在__del__()而导致运行时间减少/增加。

我的问题：

1. 我的理解是Python正在通过使用munmap()进行清理工作，但是与Python不同，Perl之类的其他语言会立即释放内存并退出程序。通过执行上述步骤，我做对了吗？有没有办法告诉Python避免使用此munmap()？
2. 如果del self.data_struct中没有__del__()语句，为什么要花10分钟以上的时间进行清理，如果del self.data_struct中有__del__()语句，为什么只需要2分钟的时间来进行清理？ ？
3. 是否可以加快清理工作，例如munmap()？
4. 有没有一种方法可以立即退出程序而不进行清理工作？

对解决此问题的其他想法/建议表示赞赏。

解决方法

请尝试使用最新版本的Python（至少3.8）？这表明在CPython的对象解除分配器中最坏情况的二次时间算法是温和（！）形式的几种迹象，在这里被重写了（请注意，链接到此处的问题又包含指向旧的StackOverflow帖子的链接，带有更多详细信息）：

https://bugs.python.org/issue37029

一些光泽

如果我的猜测是正确的，那么内存的数量并不是特别重要-而是由CPython的“小对象分配器”（obmalloc.c）管理大量不同的Python对象，再加上“运气不好” ”以释放其记忆的顺序。

首次编写该代码时，RAM不足以容纳数百万个Python对象，因此没有人注意到释放逻辑的一个特定部分可以花费的时间是分配的“竞技场”（详细信息并不是真正有用，但是“竞技场”是系统mmap()和munmap()调用的粒度-256 KiB块）。

不是那些映射调用会占用大量时间，并且使用操作系统内存映射工具对任何语言进行的任何体面实现都会最终调用munmap()来释放其mmap()所消耗的OS资源电话。

那是一条红鲱鱼。 munmap()被多次调用仅仅是因为您分配了许多对象，这需要许多mmap()调用。

没有任何清晰或简单的方法可以确切地说明问题何时出现。参见上面的“运气不好” ;-)而是将CPython 3.8的相关代码重写为最坏情况的线性时间，这为触发问题报告的特定程序提供了〜250的加速系数（请参阅已经给出的链接）

正如评论中指出的那样，您可以随时通过调用os._exit()立即退出程序，但是前导的下划线是要吓“您：“立即” 表示“立即” 。不会执行任何形式的清理。例如，您班上的__del__方法？跳过。 __del__作为释放的副作用而运行，但是如果您实际上是“立即释放内存并退出程序”，则不会运行任何类型的 no 析构函数，也不会运行任何在{ {1}}模块等。它像程序一样死掉，例如，出现段错误。