Python中如何使用memray精准监控应用常驻内存？-Python教程-PHP中文网

不能。memray只跟踪Python堆内存分配（如malloc、PyObject_Malloc调用），不采集OS级RSS等指标；其报告中的数值源于分配器事件，与/proc/pid/status中的VmRSS无直接对应关系。

python中如何使用memray精准监控应用常驻内存？

memray 能不能直接监控常驻内存（RSS）？

不能。memray 本身不采集 RSS 或 VSS 这类 OS 级内存指标，它只跟踪 Python 对象的堆内存分配（malloc/free），也就是“Python 分配了多少”，而不是“进程占用了多少物理内存”。你看到的 memray run 报告里所有数字，都来自 malloc、PyObject_Malloc 等调用栈，和 ps aux 或 /proc/pid/status 里的 RSS 是两套数据源。

想关联 memray 数据和真实 RSS，得自己加钩子

最可靠的方式是在 memray trace 过程中，定期采样 OS 层内存值，并打上时间戳，最后对齐分析。关键点：

用 psutil.Process().memory_info().rss 获取当前 RSS（单位字节），别用 resource.getrusage() —— 它返回的是峰值 RSS，不是瞬时值
采样频率建议设为 100–500ms，太密会干扰目标进程，太疏会丢失 RSS 尖峰与 Python 分配事件的因果关系
memray 必须启用 --trace-python-allocations（默认开启），否则连 list.append() 这种隐式分配都捕获不到

启动命令示例：

memray run --output memray.bin --trace-python-allocations python -c "
import time, psutil; p = psutil.Process(); 
for i in range(100): 
    print(f'RSS: {p.memory_info().rss}'); time.sleep(0.2)
"

为什么用 memray run 启动后 RSS 不涨，但 memray 报告显示大量分配？

这是典型误判场景。常见原因有：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

Python 的内存池（如 PyMalloc）会复用已释放的 block，malloc 分配了 100MB，但 OS 层 sbrk/mmap 可能只增长了 10MB —— memray 记的是 100MB，RSS 却卡在 10MB
对象被快速创建又销毁（比如循环内建 list），memray 显示高频小分配，但 RSS 几乎不变，因为内存没还给 OS
C 扩展（如 numpy、pandas）绕过 Python 内存管理器，memray 完全看不见它们的分配，但这些分配会直接抬升 RSS
Linux 的 lazy allocation：mmap(MAP_ANONYMOUS) 成功不等于物理页已分配，RSS 增长滞后于 memray 记录

生产环境常驻内存排查，memray 只是起点

memray 能告诉你“哪行 Python 代码申请最多”，但它回答不了“为什么 RSS 居高不下”。真正要定位常驻内存问题，必须配合：

/proc/PID/smaps_rollup 查 MMUPageSize 和 MMUPF，确认是否因大页未回收导致 RSS 虚高
memray live --pid PID 实时观察，但注意它无法捕获 fork 子进程或已加载 C 扩展的分配
如果应用用 mmap 加载大文件或共享内存，RSS 高但 memray 完全沉默——这种就得切到 perf record -e 'syscalls:sys_enter_mmap' 级别

memray 的价值在于快速定位 Python 层的“内存热点”，但把 RSS 当作唯一指标去优化，容易在 C 扩展、内核页缓存、JIT 缓存这些盲区里反复碰壁。