用 Memray 追踪 Python 内存热点

它解决的是什么问题

Python 服务的内存问题很少以「崩了」的形式出现，更多是缓慢爬升：一个定时任务每轮多留一点对象，几轮迭代后 RSS 翻倍，最后在某个凌晨变成 OOM。更难的是归因——日志里没有异常，火焰图里看不出分配点，你只知道「涨了」，不知道「谁在涨」。

这个技能把排查工作前移到发布之前：不是等生产环境报警再复盘，而是在本地或预发阶段留下完整的分配记录，然后直接从数据里找答案。

它怎么工作

核心是两步：采集与下钻。

采集阶段，技能通过 memray CLI 对目标进程做分配追踪，拿到一份逐次分配的记录。整个过程不需要改业务代码，也不需要插桩。

下钻阶段，它会从记录里回答三个问题：

• 谁分配得最多：按字节数排序列出头部分配点，把「大概是缓存吧」这种猜测换成具体的文件与行号。
• 谁被留在了内存里：检查 retained objects，区分「正在使用的内存」和「忘了释放的内存」。
• 泄漏路径在哪里：追踪那些只进不出的对象，串出从创建到被遗忘的完整链路。

使用前需要知道的事

这个技能依赖 Python、pip/uv 以及 memray CLI 已经就绪，它不负责安装这些依赖。

更需要注意的一点是：上游仓库中没有可自动提取的安装说明或用法文档。这意味着你需要先在非敏感环境中跑一遍，对着实际输出确认行为符合预期，再决定能不能进生产排障流程。如果工作流涉及客户数据或核心交易链路，这一步不能跳过。