【Python】memory_profiler

1.1 引用计数与垃圾回收：Python的“贴身管家”与“清洁工”

Python，特别是其标准实现CPython，其内存管理的核心是建立在一个优雅而高效的组合机制之上的：以引用计数为主，分代垃圾回收为辅。

1. 引用计数（Reference Counting）：主要的内存管家

这是CPython内存管理的基石。其原理极其简单：CPython中的每一个对象（一个整数、一个列表、一个自定义类的实例），其内部都维护着一个名为ob_refcnt的计数器。这个计数器记录了当前有多少个“引用”指向这个对象。

• 引用增加: 当一个对象被一个新的变量名引用时，其引用计数会+1。
  • x = my_list
  • y = x (此时my_list对象的引用计数为2)
  • my_dict['key'] = my_list (引用计数变为3)
  • 将对象作为参数传递给函数 (引用计数增加)
• 引用减少: 当一个指向对象的引用被销毁时，其引用计数会-1。
  • x = None (一个引用消失)
  • 一个变量被赋予新的对象 (x = another_list)
  • 一个引用离开了它的作用域（例如，一个函数执行完毕，其局部变量被销_毁）
• 内存的释放: 当一个对象的引用计数变为0时，CPython知道，这个对象在程序中已经不再可达，没有任何人需要它了。于是，它的“生命”就走到了尽头。CPython会立即调用该对象的析构函数（__del__方法，如果定义了的话），然后释放其占用的内存。

这种机制的优点是实时性和高效性。对象的内存在其不再被使用的那一刻，就会被立刻回收，不会有长时间的延迟。这使得Python程序的内存使用在通常情况下，都表现得非常平稳。

2. 分代垃圾回收（Generational Garbage Collection）：处理“循环引用”的专业清洁工

引用计数有一个致命的、无法解决的缺陷——循环引用（Reference Cycles）。

考虑以下情况：

# 文件名: circular_reference_demo.py
# 作用: 演示一个经典的循环引用场景

class MyNode: # 定义一个节点类
    def __init__(self, name): # 初始化方法
        self.name = name # 设置节点名称
        print(f"节点 '{
     self.name}' 已创建。") # 打印创建信息
        self.partner = None # 初始化一个指向伙伴的引用
    
    def __del__(self): # 定义析构函数
        # 当对象被销毁时，这个方法会被调用
        print(f"节点 '{
     self.name}' 已被销毁！内存被释放。") # 打印销毁信息

# 创建两个节点实例
node_a = MyNode("A") # 创建节点A，其引用计数为1 (被变量node_a引用)
node_b = MyNode("B") # 创建节点B，其引用计数为1 (被变量node_b引用)

print(f"\n节点A的引用计数: {
     sys.getrefcount(node_a)}") # 使用sys.getrefcount查看引用计数（注意它会比实际多1，因为函数调用本身也是一个引用）
print(f"节点B的引用计数: {
     sys.getrefcount(node_b)}") # 查看B的引用计数

# 关键步骤：创建循环引用
print("\n创建循环引用...")
node_a.partner = node_b # A引用了B, B的引用计数变为2
node_b.partner = node_a # B引用了A, A的引用计数变为2

# 销毁外部引用
print("\n销毁外部引用 del node_a, del node_b...")
del node_a # 销毁变量node_a, A的引用计数从2变为1 (因为B还引用着它)
del node_b # 销毁变量node_b, B的引用计数从2变为1 (因为A还引用着它)

# 此时，我们已经无法从程序的任何地方访问到A和B这两个节点了。
# 它们在逻辑上已经是垃圾。
# 但是，由于它们互相引用，它们的引用计数都永远不可能变为0！
# 如果只有引用计数机制，这两个节点占用的内存将永远无法被回收，造成内存泄漏。

print("\n循环引用创建完毕，外部引用已删除。")
# 你会发现，析构函数__del__并没有被调用！

为了解决这个“循环引用”的顽疾，CPython引入了“分代垃圾回收”这个辅助机制。它像一个定期的“清洁工”，专门来寻找并清理这些引用计数无法处理的“小团体”。

其核心思想基于一个弱分代假说（Weak Generational Hypothesis）：绝大多数对象的生命周期都很短，而活得越长的对象，就越不可能是垃圾。

基于此，GC将对象分为三代：第0代（Young Generation）、第1代（Middle-aged Generation）和第2代（Old Generation）。

• 所有新创建的对象，都属于第0代。
• GC会定期（当第0代对象数量达到某个阈值时）对第0代进行扫描。在这次扫描中存活下来的对象（即不是循环引用垃圾的对象），会被“晋升”到第1代。
• 当第1代对象的数量也达到某个阈值时，GC会扫描第1代。存活下来的对象会被“晋升”到第2代。
• 对第2代（最老的一代）的扫描，频率是最低的。

这个机制通过“区别对待”不同年龄的对象，将GC的开销主要集中在最可能产生垃圾的“年轻”对象上，从而提高了效率。当GC启动一次扫描时，它会暂停你的程序（Stop-the-World），找到那些循环引用的垃圾，打断它们的引用链，并回收其内存。

1.2 自动管理的“裂痕”：常见内存问题的根源

尽管CPython的内存管理机制非常智能，但它并非万无一失。在很多情况下，内存问题并非源于CPython的“失误”，而是源于我们的代码逻辑，在不经意间，为对象提供了“不死的理由”。memory_profiler正是要帮助我们找到这些“裂痕”。

1. 不受控制的“全局性”数据结构

这是最常见、也最隐蔽的内存杀手。一个在模块级别定义的列表、字典或任何可变容器，如果只被不断地添加元素，而没有相应的删除机制，它的内存占用将会无限增长。

# 文件名: memory_eater_global_cache.py
# 作用: 演示一个无限增长的全局缓存导致的内存泄漏。

# 假设这是一个用于缓存计算结果的字典，以避免重复计算
# 它在模块的顶层被定义，拥有和整个应用一样长的生命周期
COMPUTATION_CACHE = {
   } # 定义一个全局缓存字典

def process_data(data_id: str, data_payload: bytearray): # 一个处理数据的函数
    """
    一个模拟的函数，它处理数据，并将结果存入缓存。
    """
    # 模拟一次昂贵的计算
    result = f"processed_{
     data_id}" # 假设这是计算结果
    
    # 将结果存入全局缓存
    # 问题在于：这里只有写入，没有任何清理逻辑！
    COMPUTATION_CACHE[data_id] = (result, data_payload) # 将结果和原始的大负载都存入缓存
    print(f"数据 '{
     data_id}' 已处理并缓存。当前缓存大小: {
     len(COMPUTATION_CACHE)}") # 打印缓存大小

if __name__ == '__main__':
    import uuid # 导入uuid模块生成唯一的ID

    # 模拟一个持续运行的服务，不断处理新的数据
    for i in range(1000): # 循环1000次
        # 每次都生成一个大的数据负载 (例如，1MB的字节数组)
        large_payload = bytearray(1024 * 1024) # 创建一个1MB的字节数组
        # 生成一个唯一的ID
        unique_id = str(uuid.uuid4())
        # 调用处理函数
        process_data(unique_id, large_payload)

    # 循环结束后，COMPUTATION_CACHE 中将包含1000个1MB的数据负载，
    # 仅这个缓存就占用了大约 1GB 的内存。
    # 只要程序不退出，这1GB的内存就永远不会被释放，因为它被一个全局变量引用着。
    print("\n处理完成。但大量的内存被全局缓存锁定。")

在这个例子中，COMPUTATION_CACHE是完全合法的Python代码，它的引用计数也都是正确的。CPython的GC无法知道你“不再需要”那些旧的缓存项。从GC的视角看，这些对象被一个全局变量引用着，因此它们是“存活”的。内存的泄漏，源于我们自己的程序逻辑。

2. “不经意”的对象生命周期延长

有时候，对象被引用的链条，会比我们想象的要长、要隐蔽。一个典型的例子就是在闭包（Closures）或某些类的实例方法中。

# 文件名: memory_eater_closure.py
# 作用: 演示闭包如何意外地延长大对象的生命周期。

def create_request_handler(large_data_set): # 定义一个创建请求处理器的函数
    """
    这个工厂函数接收一个大的数据集，并返回一个能够处理请求的函数。
    """
    # large_data_set 是一个很大的列表或字典
    print(f"工厂函数接收到 {
     len(large_data_set)} 条数据。")

    def handle_request(request_id): # 定义一个内部函数（闭包）
        # 这个内部函数需要访问外部的 large_data_set 来完成它的工作
        # 因此，Python会创建一个闭包，将 large_data_set 的引用“捕获”并绑定到 handle_request 函数对象上
        print(f"处理请求 {
     request_id}... (需要访问大数据集)")
        # ... 假设这里有一些使用 large_data_set 的逻辑 ...
        return f"Request {
     request_id} processed using data."

    return handle_request # 返回这个内部函数

if __name__ == '__main__':
    # 1. 加载一个巨大的数据集
    print("加载大型数据集...")
    big_data = [i for i in range(10**7)] # 创建一个包含一千万个整数的列表

    # 2. 使用这个数据集创建一个请求处理器
    # handle_request_func 这个变量，现在引用的不仅仅是一个函数，
    # 而是一个包含了对 big_data 引用的“闭包”对象。
    handle_request_func = create_request_handler(big_data) 
    
    # 3. 我们以为可以释放 big_data 的内存了
    print("删除对 big_data 的原始引用...")
    del big_data # 我们删除了变量 big_data

    # 但是，因为 handle_request_func 仍然存在，并且它的闭包中还“活捉”着对那个大数据集的引用，
    # 所以那个包含一千万个整数的列表，其引用计数不为0，内存无法被释放！
    
    # 只要 handle_request_func 这个变量还存活，那部分巨大的内存就将一直被占用。
    print("\n即使 'del big_data' 被调用，内存依然被闭包锁定。")
    # ... 在程序的其他地方，我们可能只是偶尔调用一下 handle_request_func ...
    # handle_request_func(1)
    # handle_request_func(2)

这个例子揭示了一个常见的陷阱：我们以为通过del删除了一个大对象的引用，但实际上，这个对象被一个我们意想不到的、生命周期更长的对象（在这里是handle_request_func这个闭包）悄悄地“续命”了。

3. C扩展中的内存泄漏

这是最棘手的一类问题。许多高性能的Python库（如NumPy, Pandas, lxml）为了追求速度，其核心逻辑都是用C或C++编写的。这些C扩展在管理内存时，需要手动地、精确地调用Python的C-API来增加或减少对象的引用计数。

如果C扩展的代码中存在bug，比如在某个分支中忘记了为某个对象减少引用计数（Py_DECREF），那么这个对象的引用计数将永远无法归零，即使在Python层面，所有对它的引用都已消失。这就造成了真正的、连分代GC也无能为力的内存泄漏。

memory_profiler本身无法直接看到C代码内部发生了什么，但它可以成为诊断这类问题的“症状探测器”。如果我们观察到一个函数在反复调用后，内存持续稳定增长，并且这个函数内部主要调用了某个C扩展的库，那么我们就有了高度的怀疑理由，去检查这个库是否存在已知的内存泄漏问题，或者我们的使用方式是否不当。

1.3 内存问题的“并发症”：当幽灵开始尖叫

程序中的内存问题，很少会以一个清晰的“内存已泄漏”的错误信息呈现在我们面前。更多的时候，它会以一系列“并发症”的形式表现出来，影响着整个系统的健康。

• 性能的缓慢衰减（Slow Degradation）: 随着内存占用的不断攀升，需要GC扫描的对象越来越多，GC的执行会变得越来越频繁、越来越耗时。尤其是对年老代的扫描，可能会导致程序出现明显的、周期性的卡顿。
• Swap区的悲鸣（Swapping Hell）: 当物理内存（RAM）被耗尽时，操作系统会启用最后的救命稻草——交换空间（Swap Space）。它会将内存中一些不常用的“内存页”，写入到速度慢得多的硬盘上，以腾出物理内存空间。当程序需要访问那些被换出的数据时，又需要从硬盘上将其读回内存。这个过程极其缓慢，会导致你的程序性能急剧下降，甚至变得完全不可用。这就是所谓的“内存抖动（Thrashing）”。
• OOM Killer的无情审判（The OOM Killer）: 在Linux系统中，当系统内存极度不足，甚至连Swap空间都无法挽救时，内核会触发一个名为“OOM Killer”（Out-of-Memory Killer）的终极机制。它会根据一套复杂的评分系统，选择一个它认为“最该死”的进程，然后毫不留情地将其杀死（SIGKILL），以释放内存，保护整个系统的存活。你的Python程序很可能就是那个“倒霉蛋”，它会在没有任何预警、不触发任何finally块或__del__方法的情况下，瞬间从这个世界消失。

1.4 memory_profiler：我们的“内存听诊器”

面对这些潜藏在代码深处的、可能引发严重后果的“内存幽灵”，我们不能再仅仅依赖于猜测和祈祷。我们需要一个科学的、定量的诊断工具，一个能够让我们精确地听到程序内存“心跳”的“听诊器”。

这，就是memory_profiler存在的意义。

它允许我们：

• 逐行监控: 精确地看到函数中每一行代码执行前后，内存发生了怎样的变化——是增加了还是减少了，变化了多少。
• 定位内存峰值: 找到程序在哪个时间点、哪个函数中，消耗了最多的内存。
• 可视化分析: 将内存随时间变化的过程，绘制成直观的图表，帮助我们快速定位内存异常增长的区间。

2.1 安装memory_profiler及其“搭档”psutil

memory_profiler库本身是一个轻量级的分析框架，但它需要一个“搭档”来帮助它从操作系统那里获取到进程的真实内存使用情况。这个搭档就是psutil（process and system utilities）库。

psutil是一个跨平台的库，能够轻松地访问正在运行的进程和系统利用率（CPU、内存、磁盘、网络、传感器）等信息。memory_profiler通过调用psutil，来获取当前Python进程所占用的**RSS（Resident Set Size，常驻集大小）**内存。

什么是RSS？
RSS是指一个进程在物理内存（RAM）中实际占用了多少空间。它包含了进程的代码段、数据段、堆和栈，但不包括被交换到硬盘（Swap）上的部分。对于内存分析来说，RSS是一个非常关键且直观的指标，它直接反映了你的程序对宝贵的物理内存资源的消耗情况。

安装步骤：
安装memory_profiler和psutil非常简单，只需要一行pip命令：

# 同时安装 memory_profiler 和它的核心依赖 psutil
pip install memory_profiler psutil

安装完成后，你就在你的环境中同时拥有了“分析引擎”（memory_profiler）和“数据探针”（psutil）。

2.2 @profile装饰器：开启逐行分析的魔法开关

memory_profiler最核心、最直接的用法，是通过一个名为@profile的装饰器。你只需要将这个装饰器，添加到你想要进行内存分析的那个函数的定义上方。

一个重要的细节：@profile装饰器并不是Python内置的，也不是在memory_profiler库中直接可见的。当你通过memory_profiler的特定方式运行你的脚本时，它会自动地、在“运行时”将@profile这个名字注入到Python的__builtins__（内置函数）命名空间中。这意味着，你的IDE（如VSCode, PyCharm）可能会在@profile下面画上红线，提示“未定义的变量”。请忽略这个提示，这是memory_profiler的正常工作方式。

你的第一个内存分析脚本

让我们编写一个简单的脚本，来体验一下@profile装饰器的魔力。我们将创建一个函数，该函数会创建几个不同大小的列表，以便我们观察内存的增长。

# 文件名: first_memory_profile.py
# 作用: 我们的第一个使用memory_profiler进行分析的脚本。

# 注意：我们不需要在这里写 from memory_profiler import profile
# 这个装饰器是由后续的命令行工具在运行时自动注入的。

@profile # 将@profile装饰器应用到我们想要分析的函数上
def create_some_lists():
    """
    一个用于演示内存增长的简单函数。
    """
    print("函数开始执行...") # 打印开始信息
    
    # 创建一个包含100万个整数的列表
    # 这应该会消耗几MB的内存
    list_a = [i for i in range(1000000)] # 使用列表推导式创建列表A
    
    # 创建一个更大的列表，包含500万个整数
    # 我们期望看到一个显著的内存增量
    list_b = [i for i in range(5000000)] # 使用列表推导式创建列表B
    
    # 模拟一些计算，使用这两个列表
    total_sum = sum(list_a) + sum(list_b) # 计算A和B的总和
    print(f"计算完成，总和为: {
     total_sum}") # 打印计算结果
    
    # 删除一个列表的引用，我们期望看到内存的减少
    del list_b # 删除对list_b的引用
    
    print("函数执行结束。") # 打印结束信息
    return total_sum # 返回总和

if __name__ == '__main__':
    # 在这个主执行块中，我们只调用函数
    # 内存分析的启动，将通过命令行来完成
    create_some_lists() # 调用被装饰的函数

2.3 运行分析与解读报告：揭开内存消耗的神秘面纱

我们已经写好了被@profile装饰的脚本，但如何运行它并获取报告呢？我们不能像平常一样直接用python first_memory_profile.py来运行。我们需要使用memory_profiler提供的命令行接口。

打开你的终端（Terminal或CMD），切换到first_memory_profile.py文件所在的目录，然后执行以下命令：

python -m memory_profiler first_memory_profile.py

• python -m memory_profiler: 这个命令告诉Python，不要直接执行一个脚本，而是以模块的方式运行memory_profiler。memory_profiler模块会接管后续的执行过程，它会负责解析脚本，找到被@profile装饰的函数，并在其执行的每一步，都插入内存监控的探针。

当你执行这个命令后，脚本会正常运行，你会看到脚本中的print语句输出。在脚本执行完毕后，memory_profiler会打印出一份详细的、逐行的内存分析报告。这份报告看起来会是这个样子（具体的内存数值会因你的系统、Python版本而略有不同）：

函数开始执行...
计算完成，总和为: 12999997500000
函数执行结束。

Filename: first_memory_profile.py

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
     6     38.5 MiB     38.5 MiB           1   @profile
     7                                         def create_some_lists():
     8                                             """
     9                                             一个用于演示内存增长的简单函数。
    10                                             """
    11     38.5 MiB      0.0 MiB           1       print("函数开始执行...")
    12                                         
    13                                             # 创建一个包含100万个整数的列表
    14                                             # 这应该会消耗几MB的内存
    15     46.2 MiB      7.7 MiB           1       list_a = [i for i in range(1000000)]
    16                                         
    17                                             # 创建一个更大的列表，包含500万个整数
    18                                             # 我们期望看到一个显著的内存增量
    19     84.6 MiB     38.4 MiB           1       list_b = [i for i in range(5000000)]
    20                                         
    21                                             # 模拟一些计算，使用这两个列表
    22     84.6 MiB      0.0 MiB           1       total_sum = sum(list_a) + sum(list_b)
    23     84.6 MiB      0.0 MiB           1       print(f"计算完成，总和为: {total_sum}")
    24                                         
    25                                             # 删除一个列表的引用，我们期望看到内存的减少
    26     46.2 MiB    -38.4 MiB           1       del list_b
    27                                         
    28     46.2 MiB      0.0 MiB           1       print("函数执行结束。")
    29     46.2 MiB      0.0 MiB           1       return total_sum

报告解读：深入每一个数字的含义

这份报告是memory_profiler的核心产出，理解它的每一个字段至关重要。

• Filename: 被分析的Python脚本的文件名。
• Line #: 代码的行号。
• Line Contents: 该行号对应的代码内容。
• Mem usage (Memory Usage): 这是最重要的字段之一。它显示了在执行完这一行代码之后，当前Python进程的总内存使用量（RSS）。这个数字代表了程序运行到这一点的“内存快照”。
• Increment (增量): 这是另一个至关重要的字段。它显示了当前行的代码，相对于上一行代码，所造成的内存变化量。一个大的正数Increment，明确地告诉你：“就是这一行代码，导致了内存的大幅增长！”一个负数Increment，则表明这一行代码触发了内存的回收。
• Occurrences (执行次数): 这个字段记录了这一行代码被执行了多少次。对于循环体内的代码，这个数字会大于1，这对于分析循环中的累积内存增长非常有帮助。

让我们逐行分析这份报告，就像一位侦探在分析案发现场一样：

• Line 6 (@profile): 报告的基准线。在函数create_some_lists被调用之前，整个Python进程已经占用了 38.5 MiB 的内存。这部分内存主要用于加载Python解释器本身、以及memory_profiler和其他导入的模块。
• Line 15 (list_a = ...):
  • Mem usage: 46.2 MiB。执行完这行后，总内存占用上升到了46.2 MiB。
  • Increment: 7.7 MiB。这明确地告诉我们，创建list_a这个包含100万个整数的列表，消耗了大约7.7 MiB的内存。
• Line 19 (list_b = ...):
  • Mem usage: 84.6 MiB。内存占用达到了峰值。
  • Increment: 38.4 MiB。创建list_b这个更大的列表，消耗了惊人的38.4 MiB内存。这立刻成为了我们关注的焦点。
• Line 22 & 23 (total_sum = ..., print(...)):
  • Increment: 0.0 MiB。这两行代码虽然执行了计算和IO操作，但它们几乎没有引起额外的、持久的内存分配。计算的中间结果可能被创建，但很快就被销毁了。
• Line 26 (del list_b):
  • Mem usage: 46.2 MiB。总内存占用瞬间回落。
  • Increment: -38.4 MiB。这是一个负数增量！它精确地告诉我们，del list_b这一行，使得对那个巨大的列表对象的引用计数归零，CPython立刻回收了它占用的38.4 MiB内存。这个数字与Line 19的增量完全吻合，形成了一个完美的闭环。
• Line 29 (return total_sum): 函数执行完毕，返回。此时的内存占用 46.2 MiB，与创建list_a之后的状态一致，因为list_a作为函数内的局部变量，在其返回后，生命周期也结束了，其内存也会被回收（这部分回收发生在函数调用之后，所以没有在报告中直接体现为负增量）。

通过这个简单的例子，我们已经能深刻地体会到memory_profiler的强大之处。它不再让我们对内存的消耗进行猜测，而是为我们提供了定量的、逐行的、无可辩驳的证据。我们能够清晰地看到：

• 哪一行代码是“内存消耗大户”。
• 内存的峰值出现在程序的哪个位置。
• 内存的回收是否符合我们的预期。

3.1 病例一：无限增长的全局缓存

我们回到在第一章中讨论过的那个“失控的缓存”问题。一个模块级的全局字典，在长时间运行的服务中，只进不出，最终耗尽了所有内存。

复现案发现场 (memory_eater_global_cache.py)

让我们稍微改造一下之前的代码，以便于memory_profiler进行分析。我们将把循环处理的逻辑，封装在一个被@profile装饰的函数中。

# 文件名: profile_global_cache.py
# 作用: 使用memory_profiler来诊断由全局缓存引起的内存泄漏。

import uuid # 导入uuid模块，用于生成唯一ID
import time # 导入time模块，用于模拟延时

# 这是我们的“内存幽灵”：一个只增不减的全局缓存
COMPUTATION_CACHE = {
   } # 定义一个全局缓存字典

def get_large_payload():
    """一个辅助函数，用于生成一个大的数据负载(约1MiB)。"""
    return bytearray(1024 * 1024) # 返回一个1MB的字节数组

def process_data(data_id: str, data_payload: bytearray):
    """一个模拟的数据处理和缓存函数。"""
    result = f"processed_{
     data_id}" # 模拟计算结果
    # 将结果和原始的大负载都存入缓存
    COMPUTATION_CACHE[data_id] = (result, data_payload) 

@profile # ★★★ 我们将分析的焦点放在这个主处理循环上 ★★★
def main_processing_loop(num_iterations: int):
    """
    模拟一个持续运行的服务的主循环。
    """
    print(f"开始处理循环，将执行 {
     num_iterations} 次迭代...") # 打印开始信息
    for i in range(num_iterations): # 循环指定的次数
        unique_id = str(uuid.uuid4()) # 生成唯一的ID
        payload = get_large_payload() # 获取大的数据负载
        process_data(unique_id, payload) # 处理并缓存数据
        
        # 打印进度，以便观察
        if (i + 1) % 10 == 0: # 每处理10个数据打印一次
            print(f"  已处理 {
     i + 1}/{
     num_iterations} 个数据项...")
            # 我们在这里加一个小延时，以便让内存分析器有时间采样
            # 这在分析非常快的循环时尤其重要
            time.sleep(0.01)

    print("处理循环结束。") # 打印结束信息

if __name__ == '__main__':
    # 为了让演示更快，我们只循环50次
    # 但这足以清晰地展示出内存增长的趋势
    main_processing_loop(num_iterations=50) # 调用主处理循环

使用memory_profiler进行诊断

在终端中执行：

python -m memory_profiler profile_global_cache.py

你将会得到一份非常长的报告，因为它记录了循环中每一次迭代的情况。让我们截取报告的关键部分，并聚焦于Increment列的变化趋势：

Filename: profile_global_cache.py

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
... (省略前面的行) ...
23     40.2 MiB      0.0 MiB           1   @profile
24                                         def main_processing_loop(num_iterations: int):
... (省略) ...
29     40.2 MiB      0.0 MiB           1       print(f"开始处理循环，将执行 {num_iterations} 次迭代...")
30     40.2 MiB      0.0 MiB           1       for i in range(num_iterations):
31     41.2 MiB      1.0 MiB          50           unique_id = str(uuid.uuid4())
32     41.2 MiB      0.0 MiB          50           payload = get_large_payload()
33     41.2 MiB      0.0 MiB          50           process_data(unique_id, payload)
34                                         
35                                                 # 打印进度，以便观察
36     41.2 MiB      0.0 MiB          50           if (i + 1) % 10 == 0:
37     41.2 MiB      0.0 MiB           5               print(f"  已处理 {i + 1}/{num_iterations} 个数据项...")
38     41.2 MiB      0.0 MiB           5               time.sleep(0.01)
... (后面还有循环的多次记录) ...

等等，这个报告看起来不对劲！ Increment列并没有像我们预期的那样，在每次循环中都显示大约1.0 MiB的增长。总的Mem usage似乎也没有持续攀升。这是为什么？

memory_profiler的“陷阱”与正确解读

这个“迷惑性”的报告，恰好揭示了memory_profiler逐行分析的一个关键特点，以及Python内存管理的一个细节：

1. 分析的粒度: memory_profiler是在每一行代码执行后进行采样的。在for循环这个例子中，payload变量在每次循环的开始被赋予一个新的bytearray对象，在下一次循环开始时，payload这个名字又被赋予了下一个新的bytearray对象。从payload这个变量本身来看，它引用的那个旧的bytearray对象的生命周期，只持续了一次迭代。
2. 内存增长的真正元凶: 内存的持续增长，并不是发生在main_processing_loop函数内部的局部变量上，而是发生在**全局变量COMPUTATION_CACHE**上。process_data函数是修改这个全局缓存的“罪魁祸首”。

正确的诊断姿势：为了看到全局缓存的增长，我们需要将分析的焦点，转移到真正修改全局状态的那个函数上。

让我们修改脚本，将@profile装饰器移动到process_data函数上。

# 文件名: profile_global_cache_correct.py
# 作用: 将@profile装饰器放在正确的位置，以诊断全局缓存问题。

import uuid
import time

COMPUTATION_CACHE = {
   }

def get_large_payload():
    return bytearray(1024 * 1024)

@profile # ★★★ 将装饰器移动到这里！ ★★★
def process_data(data_id: str, data_payload: bytearray):
    """
    一个模拟的数据处理和缓存函数。
    """
    # 这一行代码是内存增长的关键
    COMPUTATION_CACHE[data_id] = (result, data_payload)
    result = f"processed_{
     data_id}"
    # 为了让报告更清晰，我们把赋值语句分开
    # 我们期望在COMPUTATION_CACHE[data_id] = ...这一行看到内存增长
    
def main_processing_loop(num_iterations: int):
    # 这个函数不再被分析
    for i in range(num_iterations):
        unique_id = str(uuid.uuid4())
        payload = get_large_payload()
        process_data(unique_id, payload)

if __name__ == '__main__':
    main_processing_loop(num_iterations=50)

# 注意：上面的代码为了演示，在process_data中使用了未定义的result。
# 我们来修正一下，让它能正确运行。

修正后的、可运行的诊断脚本：

# 文件名: profile_global_cache_correct_runnable.py
# 作用: 一个可运行的、正确诊断全局缓存问题的脚本。

import uuid
import time

COMPUTATION_CACHE = {
   } # 定义全局缓存

def get_large_payload():
    """辅助函数：生成1MB的数据负载。"""
    return bytearray(1024 * 1024)

@profile # ★★★ 分析的焦点是这个函数 ★★★
def process_data_and_cache(data_id: str):
    """
    这个函数现在既负责获取数据，也负责处理和缓存。
    这样我们可以清晰地看到从数据创建到被缓存的完整内存轨迹。
    """
    # 步骤1: 创建一个大的数据对象
    large_payload = get_large_payload()
    
    # 步骤2: 模拟计算
    result = f"processed_{
     data_id}"
    
    # 步骤3: 将数据存入全局缓存
    # 我们期望在这一行看到一个永久性的内存增长
    COMPUTATION_CACHE[data_id] = (result, large_payload)

def main_processing_loop(num_iterations: int):
    """主循环，调用被分析的函数。"""
    for i in range(num_iterations):
        unique_id = str(uuid.uuid4())
        process_data_and_cache(unique_id)
        if (i + 1) % 10 == 0:
            print(f"  已处理 {
     i + 1}/{
     num_iterations} 个数据项...")
            time.sleep(0.01)

if __name__ == '__main__':
    main_processing_loop(num_iterations=50)

再次执行诊断：

python -m memory_profiler profile_global_cache_correct_runnable.py

这次，你得到的报告将会非常不同，并且直指问题的核心。由于process_data_and_cache被调用了50次，报告会很长，但我们可以观察到一个清晰的模式。让我们看看前几次和最后几次调用的情况：

第一次调用 process_data_and_cache:

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
15     40.5 MiB     40.5 MiB           1   @profile
16                                         def process_data_and_cache(data_id: str):
...
21     41.5 MiB      1.0 MiB           1       large_payload = get_large_payload()
22     41.5 MiB      0.0 MiB           1       result = f"processed_{data_id}"
23     41.5 MiB      0.0 MiB           1       COMPUTATION_CACHE[data_id] = (result, large_payload)

第二次调用 process_data_and_cache:

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
15     41.5 MiB      0.0 MiB           1   @profile
16                                         def process_data_and_cache(data_id: str):
...
21     42.5 MiB      1.0 MiB           1       large_payload = get_large_payload()
22     42.5 MiB      0.0 MiB           1       result = f"processed_{data_id}"
23     42.5 MiB      0.0 MiB           1       COMPUTATION_CACHE[data_id] = (result, large_payload)

…
第五十次调用 process_data_and_cache:

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
15     89.5 MiB      0.0 MiB           1   @profile
16                                         def process_data_and_cache(data_id: str):
...
21     90.5 MiB      1.0 MiB           1       large_payload = get_large_payload()
22     90.5 MiB      0.0 MiB           1       result = f"processed_{data_id}"
23     90.5 MiB      0.0 MiB           1       COMPUTATION_CACHE[data_id] = (result, large_payload)

侦探的结论:

1. 持续的基线增长: 我们观察到，每次调用process_data_and_cache时，其入口处（Line 15）的Mem usage都在稳定地增长。第一次是40.5 MiB，第二次是41.5 MiB，…，第五十次已经达到了89.5 MiB。这表明，在函数调用之间，内存没有被完全释放。
2. 函数内部的增量: 在每一次函数调用内部，Line 21 (large_payload = ...) 都产生了1.0 MiB的Increment。
3. 罪魁祸首: Line 23 (COMPUTATION_CACHE[...] = ...) 并没有显示一个Increment，但是它将large_payload的引用传递给了全局变量COMPUTATION_CACHE。正是这个操作，使得在函数执行完毕后，large_payload所指向的那个1MiB的内存块，其引用计数不为0，从而得以“幸存”，导致了下一次函数调用时，我们看到的基线内存的增长。

memory_profiler的报告，像一个忠实的记录者，通过不断攀升的Mem usage基线，清晰地向我们控诉了COMPUTATION_CACHE这个全局变量的“罪行”。

3.2 解决方案：为缓存引入“遗忘”机制

定位了问题，解决方案就变得清晰了。我们不能让缓存无限增长。我们需要引入一种策略，让它能够“遗忘”掉那些旧的、可能不再需要的数据。

策略一：固定大小的缓存（Bounded Cache）

我们可以限制缓存只能存储最近的N个项目。一个简单的方法是使用collections.OrderedDict。

# 文件名: fix_global_cache_bounded.py
# 作用: 使用固定大小的缓存来解决内存泄漏问题。

import uuid
import time
from collections import OrderedDict # 导入有序字典

# 使用一个有序字典，并限制其最大大小
MAX_CACHE_SIZE = 10 # 我们只缓存最近的10个项目
COMPUTATION_CACHE = OrderedDict() # 创建一个有序字典实例

@profile
def process_data_and_cache_fixed(data_id: str):
    large_payload = bytearray(1024 * 1024)
    result = f"processed_{
     data_id}"
    
    # 检查缓存是否已满
    if len(COMPUTATION_CACHE) >= MAX_CACHE_SIZE:
        # 如果已满，使用popitem(last=False)来移除“最老”的一项
        # 这就像一个先进先出(FIFO)队列
        COMPUTATION_CACHE.popitem(last=False) 
        print("  缓存已满，移除最旧的项目。")
        
    COMPUTATION_CACHE[data_id] = (result, large_payload)

# ... (main_processing_loop保持不变) ...
def main_processing_loop(num_iterations: int):
    for i in range(num_iterations):
        unique_id = str(uuid.uuid4())
        process_data_and_cache_fixed(unique_id)

if __name__ == '__main__':
    main_processing_loop(num_iterations=50)

再次运行诊断：

python -m memory_profiler fix_global_cache_bounded.py

这一次，你将看到一个截然不同的报告。Mem usage会在前10次调用中增长，但当缓存达到上限后，它将稳定在一个水平上，不再持续攀升。因为每一次新的添加，都伴随着一次旧的移除，内存的申请与释放达到了动态平衡。memory_profiler会清晰地验证我们的修复是有效的。

策略二：基于时间的缓存（Time-based Cache / TTL Cache）

另一种常见的策略是，为每个缓存项设置一个“存活时间”（Time-to-Live, TTL）。

# 文件名: fix_global_cache_ttl.py
# 作用: 使用带TTL的缓存来解决内存泄漏问题。

import uuid
import time
import random

# 我们需要自己实现一个简单的TTL缓存
CACHE_TTL = 5 # 缓存项的生命周期为5秒
COMPUTATION_CACHE = {
   } # 普通字典即可

# 我们需要一个单独的函数来清理过期缓存
# 在真实应用中，这可能会由一个后台线程定期执行
def cleanup_expired_cache():
    current_time = time.time() # 获取当前时间
    # 找出所有已过期的键
    # 我们不能在迭代字典时删除它，所以先收集要删除的键
    expired_keys = [
        k for k, (timestamp, _) in COMPUTATION_CACHE.items() 
        if current_time - timestamp > CACHE_TTL
    ]
    # 删除所有过期的项
    for k in expired_keys:
        del COMPUTATION_CACHE[k]
        print(f"  缓存项 '{
     k[:8]}...' 已过期并被清理。")

@profile
def process_data_and_cache_ttl(data_id: str):
    large_payload = bytearray(1024 * 1024)
    result = f"processed_{
     data_id}"
    
    # 存储数据时，同时存入当前的时间戳
    COMPUTATION_CACHE[data_id] = (time.time(), (result, large_payload))
    
    # 在每次处理时，都有一定几率触发一次清理
    # 这是一种简单的、模拟的清理策略
    if random.random() < 0.2: # 20%的几率触发清理
        cleanup_expired_cache()


def main_processing_loop(num_iterations: int):
    for i in range(num_iterations):
        unique_id = str(uuid.uuid4())
        process_data_and_cache_ttl(unique_id)
        time.sleep(0.2) # 每次迭代间隔0.2秒，以观察TTL效果

if __name__ == '__main__':
    main_processing_loop(num_iterations=50)

对这个版本进行分析，我们同样会看到内存使用会达到一个动态的平衡，而不是无限增长。memory_profiler再次成为了我们验证优化策略是否有效的、客观公正的裁判。

场景复现：一个基于大型配置的解析器工厂

想象一下，我们正在构建一个数据解析系统。系统的初始化阶段，需要加载一个非常大的配置文件（比如一个包含数百万条规则的JSON或XML文件）。然后，系统需要根据不同的解析请求，动态地创建相应的解析函数。这是一个典型的工厂模式应用场景。

# 文件名: profile_closure_leak.py
# 作用: 使用memory_profiler来诊断由函数闭包导致的内存占用问题。

import json # 导入json库
import gc # 导入垃圾回收模块，用于手动触发GC

# 模拟一个非常大的配置文件，例如一个包含大量解析规则的字典
def load_massive_config(num_rules: int) -> dict:
    """生成一个模拟的大型配置字典。"""
    print(f"正在加载包含 {
     num_rules} 条规则的大型配置...") # 打印加载信息
    config = {
   f"rule_{
     i}": {
   "pattern": f"pattern_{
     i}", "action": f"action_{
     i}"} for i in range(num_rules)} # 使用字典推导式创建配置
    return config # 返回配置字典

def parser_factory(massive_config: dict):
    """
    一个解析器工厂函数。
    它接收大型配置，并返回一个能够根据规则ID进行解析的函数。
    """
    print("解析器工厂已创建。") # 打印工厂创建信息
    
    # 这里是问题的核心
    def create_specific_parser(rule_id: str):
        """
        这是一个内部函数（闭包）。它需要访问外部的massive_config来查找规则。
        """
        if rule_id in massive_config: # 检查规则ID是否存在于配置中
            # 模拟解析过程
            return f"Parsed with rule: {
     massive_config[rule_id]['pattern']}" # 返回解析结果
        else:
            return "Rule not found." # 返回未找到规则信息

    # 工厂返回了这个闭包函数
    return create_specific_parser # 返回创建的特定解析器

@profile # ★★★ 我们将对整个设置和清理过程进行分析 ★★★
def setup_and_teardown_parsers():
    """

    模拟一个服务的启动、使用和关闭过程。
    """
    # 1. 启动阶段：加载大型配置
    config_data = load_massive_config(2 * 10**6) # 加载一个包含200万条规则的配置

    # 2. 创建一个解析器
    # parser 这个变量现在引用的，是一个绑定了对config_data引用的闭包
    parser = parser_factory(config_data)
    
    # 3. 关键步骤：我们认为我们不再需要原始的config_data了
    print("\n尝试删除对原始大型配置的引用...")
    del config_data # 删除对config_data的直接引用
    
    # 4. 强制执行一次垃圾回收
    # 这可以确保任何没有被引用的对象都被清理掉，让我们的内存报告更准确
    # 它会清理掉那些非循环的、引用计数为0的垃圾
    gc.collect() 
    
    print("\n原始配置引用已删除，并已执行GC。")
    print("现在，我们将使用解析器。我们期望内存不应该再被大型配置所占据。")
    
    # 5. 使用阶段：在程序的后续部分，我们只使用这个parser函数
    result = parser("rule_12345") # 使用解析器
    print(f"解析结果: {
     result}") # 打印解析结果
    
    # 6. 在函数结束前，我们再做一次快照，看看内存占用情况
    print("\n函数即将结束...")

if __name__ == '__main__':
    setup_and_teardown_parsers() # 调用设置和拆卸解析器的函数

进行诊断

python -m memory_profiler profile_closure_leak.py

分析报告解读

你将看到一份类似这样的报告（具体数值可能不同，但趋势和关键点是一致的）：

正在加载包含 2000000 条规则的大型配置...
解析器工厂已创建。

尝试删除对原始大型配置的引用...

原始配置引用已删除，并已执行GC。
现在，我们将使用解析器。我们期望内存不应该再被大型配置所占据。
解析结果: Parsed with rule: pattern_12345

函数即将结束...

Filename: profile_closure_leak.py

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
...
31     42.1 MiB     42.1 MiB           1   @profile
32                                         def setup_and_teardown_parsers():
...
36    205.8 MiB    163.7 MiB           1       config_data = load_massive_config(2 * 10**6)
37                                     
38    205.8 MiB      0.0 MiB           1       parser = parser_factory(config_data)
39                                         
40    205.8 MiB      0.0 MiB           1       print("\n尝试删除对原始大型配置的引用...")
41    205.8 MiB      0.0 MiB           1       del config_data
42                                         
43    205.8 MiB      0.0 MiB           1       gc.collect()
44                                         
45    205.8 MiB      0.0 MiB           1       print("\n原始配置引用已删除，并已执行GC。")
...
50    205.8 MiB      0.0 MiB           1       result = parser("rule_12345")
...
54    205.8 MiB      0.0 MiB           1       print("\n函数即将结束...")

侦探的结论:

1. 内存的急剧增长: Line 36 (config_data = ...) 导致了内存从42.1 MiB暴增到205.8 MiB，Increment高达163.7 MiB。这符合我们的预期，加载一个巨大的配置字典确实非常消耗内存。
2. del和gc.collect()的“无效”操作: 这是问题的关键所在！ 在Line 41 (del config_data) 和 Line 43 (gc.collect()) 执行之后，Mem usage一栏的数值丝毫没有下降，依然顽固地停留在205.8 MiB。
3. 内存的持续占用: 直到函数结束前的最后一次快照（Line 54），205.8 MiB的内存占用依然存在。

这份报告清晰地证明了我们的理论：虽然我们删除了config_data这个名字，但是那个巨大的配置字典对象，其引用被parser这个闭包函数“捕获”了。只要parser这个变量还存活，那163.7 MiB的内存就永远无法被释放。memory_profiler通过在del和gc.collect()之后，内存占用毫无变化的现象，为我们提供了无可辩驳的证据。

解决方案：打破或绕开闭包的“捕获”

我们需要找到一种方法，让我们的解析器既能完成工作，又不必保持对整个massive_config的引用。

方案一：在创建时提取所需信息（如果适用）

如果create_specific_parser函数实际上并不需要整个massive_config，而只是其中的一小部分，我们可以在创建它时，就将所需的信息提取出来。

# 文件名: fix_closure_extract.py
# (此方案仅在解析器只需要部分信息时适用)

def parser_factory_fixed_extract(massive_config: dict):
    # 这个工厂现在返回一个“更智能”的工厂
    def create_parser_for_specific_rule(rule_id: str):
        # 在创建最终的解析器时，我们从大配置中只提取需要的那一条规则
        rule_data = massive_config.get(rule_id)
        
        def specific_parser(): # 最终的解析器是一个无参数的闭包
            if rule_data:
                return f"Parsed with rule: {
     rule_data['pattern']}"
            else:
                return "Rule not found."
        
        # 这个返回的specific_parser闭包，只捕获了小得多的rule_data的引用
        return specific_parser

    return create_parser_for_specific_rule

@profile
def setup_and_teardown_fixed_extract():
    config_data = load_massive_config(2 * 10**6) # 加载大配置
    
    # 获取一个“二级工厂”
    parser_creator = parser_factory_fixed_extract(config_data)
    
    # 为特定规则创建一个轻量级的解析器
    # 这个解析器只携带了 'rule_12345' 这一条规则的信息
    lightweight_parser = parser_creator("rule_12345")
    
    # 现在，我们可以安全地删除大配置了
    print("\n删除原始配置引用...")
    del config_data
    del parser_creator # 同时删除二级工厂，确保它捕获的引用也被释放
    gc.collect() # 强制GC
    
    print("\n现在内存应该已被大量释放。")
    result = lightweight_parser()
    print(f"解析结果: {
     result}")

对setup_and_teardown_fixed_extract进行分析，你会看到在del和gc.collect()之后，内存占用会大幅下降。

方案二：使用类和实例变量（更通用的解决方案）

一个更通用、更清晰的解决方案是，放弃使用函数闭包，转而使用类来封装状态。

# 文件名: fix_closure_class.py
# 作用: 使用类来替代闭包，以实现更清晰的生命周期管理。

# ... (load_massive_config函数保持不变) ...
import gc

class Parser: # 定义一个解析器类
    def __init__(self, config: dict): # 初始化方法
        # 将大的配置数据存储为实例变量
        self.config = config
        print("Parser实例已创建，并持有了对配置的引用。")

    def parse(self, rule_id: str) -> str: # 定义一个解析方法
        """根据规则ID进行解析。"""
        return f"Parsed with rule: {
     self.config.get(rule_id, {
     'pattern': 'Not Found'})['pattern']}"

    def __del__(self): # 定义析构函数
        # 我们可以通过这个来观察实例何时被销毁
        print("Parser实例已被销毁，其持有的配置引用被释放。")

@profile
def setup_and_teardown_class_based():
    """使用基于类的解析器进行启动和关闭。"""
    # 1. 加载大配置
    config_data = load_massive_config(2 * 10**6)
    
    # 2. 创建Parser的实例
    # parser_instance现在持有了对config_data的引用
    parser_instance = Parser(config_data)
    
    # 3. 释放对原始配置字典的引用
    # 现在只有parser_instance.config这一个引用指向大配置
    del config_data
    gc.collect()
    
    print("\n原始配置引用已删除。")
    
    # 4. 使用解析器实例
    result = parser_instance.parse("rule_12345")
    print(f"解析结果: {
     result}")
    
    # 5. 关键步骤：当我们不再需要解析器时，删除对实例的引用
    print("\n不再需要解析器，删除其实例...")
    del parser_instance # 删除对parser_instance的引用
    
    # 6. 再次强制GC
    # 此时，没有任何引用指向Parser实例，它将被销毁。
    # Parser实例被销毁时，它持有的self.config的引用也随之消失。
    # 此时，没有任何引用指向那个巨大的配置字典，它的内存将被回收。
    gc.collect()
    
    print("\nParser实例已删除，并已执行GC。内存应该已被完全回收。")

if __name__ == '__main__':
    setup_and_teardown_class_based()

再次进行诊断 (fix_closure_class.py)

python -m memory_profiler fix_closure_class.py

这次的报告将会非常戏剧性，它会清晰地展示出内存的完整生命周期：

1. 加载: 内存暴增，达到205.8 MiB。
2. 持有: 在parser_instance存活期间，内存保持在高位。
3. 释放: 在del parser_instance和gc.collect()之后，Mem usage会断崖式地下降，回落到接近初始的水平。

侦探的最终结论:
通过使用类，我们将对大型数据的引用，从一个生命周期模糊的“闭包捕获”，转变为一个生命周期清晰的“实例变量”。parser_instance这个对象的生与死，现在完全在我们的掌控之中。当我们确定不再需要它时，一个简单的del parser_instance就能确保其所持有的所有资源（包括那个巨大的配置字典）的引用链被干净利落地斩断，从而让GC能够完成它的回收工作。memory_profiler通过量化del操作前后的内存变化，为我们直观地展示了这种显式生命周期管理带来的巨大好处。

这个案例深刻地揭示了memory_profiler作为诊断工具的价值。它不仅能告诉我们“哪里”消耗了内存，更能通过展示内存“何时”被释放（或不被释放），来帮助我们洞察程序中那些隐藏的、由语言特性（如闭包）带来的复杂对象生命周期问题。

3.4 病例三：生成器——“流”的艺术与“物化”的陷阱

生成器是Python语言的精髓之一。与一次性构建并返回整个结果集的普通函数不同，一个生成器函数会返回一个迭代器（Iterator），这个迭代器可以在你每次向它请求（通过next()或for循环）时，才“生成”并交出一个值。在交出值后，它会暂停自己的状态，等待下一次请求。

这种“一次只生成一个”的惰性机制，意味着在任何时刻，内存中都只需要存储当前正在处理的那个元素，以及生成器自身的状态，而不需要存储整个数据集。

场景构建：处理一个巨大的日志文件

想象一下，我们需要编写一个脚本，来处理一个非常大的服务器日志文件（比如，几个GB大小）。我们的任务是，从这个文件中，筛选出所有包含"ERROR"关键字的行，并对这些错误行进行计数。

一个“内存灾难式”的实现

一个初级的Python开发者，可能会很自然地写出下面这样的代码。他使用了readlines()方法，这个方法会一次性读取文件的所有行，并将它们作为一个巨大的字符串列表，加载到内存中。

# 文件名: profile_generator_disaster.py
# 作用: 演示一种内存效率极低的、一次性读取大文件的方式。

import os # 导入os模块，用于文件操作

def create_large_log_file(filename: str, num_lines: int):
    """一个辅助函数，用于创建一个模拟的大型日志文件。"""
    print(f"正在创建模拟日志文件 '{
     filename}'，包含 {
     num_lines} 行...") # 打印创建信息
    with open(filename, "w") as f: # 以写模式打开文件
        for i in range(num_lines): # 循环指定的行数
            if i % 10 == 0: # 每10行插入一个错误日志
                f.write(f"Line {
     i}: Timestamp - 192.168.1.1 - ERROR: Connection failed.\n") # 写入错误日志
            else:
                f.write(f"Line {
     i}: Timestamp - 192.168.1.1 - INFO: Request processed.\n") # 写入普通日志

@profile # ★★★ 我们将对这个灾难性的处理函数进行分析 ★★★
def process_log_disaster(filename