Psutil 项目中的内存映射查询优化：解决大内存进程监控时的段错误问题

在 Linux 系统上使用 Python 的 psutil 库监控大型进程时，当目标进程占用数百GB内存时，调用 memory_maps() 方法可能会触发段错误(Segmentation Fault)。这个问题源于 Python 解释器内部在处理超长列表时的递归限制，而非 psutil 本身的代码缺陷。

问题现象与定位

当监控一个内存占用极高的进程（如大型数据库服务 impalad）时，执行以下简单代码就会导致 Python 解释器崩溃：

import psutil
import sys
pid = int(sys.argv[1])
process = psutil.Process(pid)
mm = psutil.Process.memory_maps(process)

通过分析核心转储文件发现，崩溃发生在 Python 解释器的 list_extend() 函数内部，调用栈深度超过 65,500 层。这表明当进程的内存映射区域数量极大时，Python 解释器在处理列表扩展操作时会达到递归限制。

技术背景

psutil 的 memory_maps() 方法原本的实现逻辑是：

1. 读取 /proc/[pid]/maps 文件获取内存映射信息
2. 将结果解析为内存映射对象列表
3. 使用 Python 内置的列表操作处理这些数据

问题出在当内存映射区域数量极大时，Python 解释器在内部处理列表扩展操作时会使用递归方式，最终导致栈溢出。这是 Python 解释器本身的一个已知限制，在标准库的列表处理逻辑中难以避免。

解决方案

优化后的实现采用了分批处理策略：

1. 仍然从 /proc 文件系统读取原始内存映射信息
2. 但改为使用生成器逐步产生结果，而不是一次性构建完整列表
3. 通过限制单次处理的数据量，避免触发解释器的递归限制

这种改进既保持了原有功能完整性，又解决了大内存进程监控时的稳定性问题。从用户角度看，API 接口保持不变，但内部实现更加健壮。

实际影响与建议

这个问题主要影响需要监控大型内存密集型服务的场景，如：

• 大数据处理系统
• 内存数据库
• 科学计算应用

建议所有使用 psutil 监控此类应用的用户升级到包含此修复的版本。对于自行构建监控系统的开发者，这也提供了一个很好的案例参考——在处理可能很大的系统数据时，采用流式处理或分批处理策略往往比一次性加载更可靠。

这个优化展示了即使在依赖底层系统组件的情况下，通过合理的架构设计仍然可以提供稳定的抽象接口，是系统编程中一个值得借鉴的实践。