17370845950

用psutil.Process(os.getpid()).memory_info().rss可准确获取Python进程真实内存占用（RSS），避免sys.getsizeof()等仅统计Python对象的局限；需每1–5秒采样，结合斜率与GC回落判断泄漏，多进程须独立监控，C扩展内存需依赖RSS趋势识别。

怎么用 psutil 实时查 Python 进程内存占用

直接靠 sys.getsizeof() 或 gc.get_objects() 无法反映真实内存压力，它们只统计 Python 对象堆内大小，不包含 C 扩展、mmap、共享库等。真正可靠的是从操作系统层面读进程 RSS（Resident Set Size）。

用 psutil 是最轻量且跨平台的选择：

import psutil
import os
p = psutil.Process(os.getpid())
rss_mb = p.memory_info().rss / 1024 / 1024  # 转 MB
print(f"当前 RSS: {rss_mb:.1f} MB")

• 务必用 p.memory_info().rss，不是 vms（虚拟内存不可靠）
• Linux 下 RSS 基本等于“实际占物理内存”，Windows/macOS 行为略有差异但足够用于趋势判断
• 不要在循环里频繁调用——psutil.Process() 初始化有开销，建议每 1–5 秒采样一次

怎么定义“内存泄漏”并触发报警

内存泄漏不是“内存一直涨”，而是“持续增长且不回落”。单纯设阈值（如 >500MB）容易误报，比如临时大文件处理。

更稳妥的方式是监控**增长斜率 + 回落失败**：

• 记录最近 N 次 RSS 值（例如 10 次，间隔 3 秒）
• 用线性拟合或简单差分判断是否连续 5 次上涨，且涨幅 >5MB/次
• 同时检查 GC 是否有效：调用 gc.collect() 后 RSS 下降
• 报警前再 sleep 1 秒重采一次，排除瞬时毛刺

示例逻辑片段：

import gc
# ... rss_history 维护一个 deque(maxlen=10)
if len(rss_history) == 10 and all(rss_history[i] < rss_history[i+1] for i in range(5, 9)):
    gc.collect()
    time.sleep(1)
    rss_after_gc = p.memory_info().rss / 1024 / 1024
    if rss_after_gc > rss_history[-1] * 0.99:  # 未回落超 1%
        trigger_alert(rss_after_gc)

报警该怎么做才不被忽略

发个 print() 或写日志基本等于没报。真要起作用，得打通运维链路：

• 写入本地告警文件（如 /tmp/memory_alert.pid），配合 systemd 的 PathExists 监控自动拉起处理脚本
• 调用企业微信/钉钉 Webhook（注意加签名和限频，避免刷屏）
• 向 Prometheus Pushgateway 推送指标（memory_leak_detected{pid="12345"} 1），再由 Alertmanager 发通知
• 切忌用 smtplib 自建邮件——SMTP 很容易被当垃圾邮件拦截，且无送达反馈

为什么多线程/多进程下容易误判

psutil.Process(os.getpid()) 在

子线程里仍返回主进程，没问题；但如果你用 multiprocessing，每个子进程需独立监控——父进程无法直接看到子进程 RSS。

• 子进程启动时，手动传入监控开关和告警通道（如 queue 或 pipe）
• 避免用 fork 后的进程继承父进程监控逻辑，因为 fork 时 RSS 会虚高（写时复制未触发）
• 若用 concurrent.futures.ProcessPoolExecutor，建议改用 ThreadPoolExecutor 配合对象池复用，从源头减少进程级内存震荡

最常被忽略的一点：C 扩展（如 numpy、pandas、cv2）分配的内存不经过 Python GC，RSS 上涨但 gc.get_count() 完全不动——这类泄漏只能靠 RSS 趋势发现，无法靠对象计数定位。