Python监控进程内存变化\_psutil自动记录数据

本文深入剖析了使用psutil监控Python进程内存变化的实战要点，指出memory_info()返回的是rss、vms等绝对内存值而非增量，直接将其当作增长量会导致严重误判（如将正常初始化误报为内存泄漏）；强调需通过连续采样计算斜率或累计增幅，并结合业务场景设定动态阈值，同时规避高频采样带来的系统干扰、跨平台rss语义差异、子进程内存遗漏等陷阱；还详解了稳定采样策略、安全异常处理（精准捕获No such process）、高效日志格式设计（isoformat时间戳+CSV结构化）等生产级实践，直击“取得到数据”和“判得准问题”之间的关键鸿沟。

psutil.Process().memory_info() 返回什么，为什么不能直接当内存增长值用

它返回的是一个命名元组，包含 rss（常驻集大小）和 vms（虚拟内存大小）等字段，但这些是**绝对值**，不是增量。直接记录 rss 看趋势没问题，但若想算“增长了多少 MB”，必须自己做差值计算——否则你会看到一条直线上升的曲线，其实只是进程启动后内存自然驻留的结果。

常见错误现象：每秒采集一次 rss，画图发现从 50MB 涨到 120MB 就报警，结果发现是加载配置、初始化缓存导致的正常行为，根本不是泄漏。

• 只看单次 rss 值容易误判；要观察连续 10~30 秒的斜率或累计增幅
• memory_info() 在 Windows 和 Linux 下语义一致，但 macOS 的 rss 可能含压缩内存，数值偏低且波动大
• 如果进程 fork 了子进程，rss 不包含子进程内存，得用 children(recursive=True) 手动加总

怎么稳定采样而不拖慢被监控进程

psutil 的 Process.memory_info() 调用本身开销不大（微秒级），但高频轮询（比如 100ms 一次）会显著增加系统调用次数，在负载高的机器上反而干扰目标进程调度。

使用场景：你不是在压测，而是在长期观测服务稳定性，所以采样节奏比精度更重要。

• 生产环境建议间隔 ≥ 2 秒；若需捕捉短时峰值，可配合突发采样策略（例如检测到 3 秒内增幅 >10MB，临时切到 500ms 采样 10 次）
• 避免在主线程里阻塞式轮询；用 threading.Timer 或 asyncio.call_later 更轻量
• 别用 psutil.process_iter() 全局扫描找进程——它每次遍历所有进程，开销远大于直接用 psutil.Process(pid)

记录数据到文件时，时间戳和格式怎么选才方便后续分析

很多人用 time.time() 写浮点秒，看着精确，但 Python 默认 float 是双精度，写进 CSV 后可能变成 1718234567.1234567，用 pandas 读的时候类型推断出错，或者时区混乱。

性能影响：字符串格式化比直接写数字慢，但日志 IO 本身才是瓶颈，这点差异可忽略。

• 用 datetime.now().isoformat()，生成类似 "2024-06-12T14:23:45.123" 的字符串，无歧义、可排序、pandas 开箱即用
• 每行一条记录，字段用逗号分隔：timestamp, pid, rss_bytes, vms_bytes；不要用 JSON 行，解析成本高且不易用 shell 工具快速查看
• 文件名带上日期，如 memlog_20240612.csv，避免单文件无限增长导致追加变慢或损坏后全丢

OSError: [Errno 3] No such process 错误怎么安静处理

这是最常遇到的异常：你拿到一个 pid 开始监控，但目标进程在下次采样前已退出。不捕获就崩，但全吞掉又会丢失“进程意外终止”的信号。

关键点在于区分“进程结束”和“暂时不可读”。Linux 下 /proc/PID 目录消失才真死了；Windows 上 pid 复用快，更易误判。

• 只对 OSError 中 errno == 3 做静默处理，其他错误（如权限不足 errno==13）仍要抛出
• 捕获后记录一行日志：f"Process {pid} exited at {datetime.now().isoformat()}"，而不是啥也不做
• 别在 except 里重试 new Process(pid)——pid 可能已被复用，你会监控到另一个完全无关的进程

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。