用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 osp = 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）容易误报，比如临时大文件处理。
更稳妥的方式是监控**增长斜率 + 回落失败**：
立即学习“Python免费学习笔记（深入）”；
- 记录最近 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 趋势发现，无法靠对象计数定位。
