Heroku部署Rails应用使用zipline流式下载ZIP文件内存持续升高问题

根因分析 #

该现象属于Ruby MRI 默认内存分配机制的固有特性，并非代码层面的内存泄漏：

• MRI 进程向操作系统申请的内存页，即使内部对象被GC回收标记为空闲，也不会主动归还给操作系统，只会保留在进程内部供后续新对象复用，这就是多次下载时内存涨幅逐步收窄的核心原因
• 流式ZIP传输过程中产生的临时IO缓冲、字符串对象会触发MRI持续申请新内存页，下载结束后对象被回收，但对应的内存页仍然被进程持有，Heroku的内存指标采集的是进程总占用内存，所以会显示内存持续上涨不回落

排查步骤 #

• 验证GC运行状态：在下载逻辑前后插入GC.start强制触发GC，观察内存是否停止上涨，排除GC被意外阻塞的问题
• 确认中间件无缓冲：检查Rack中间件栈，移除Rack::Deflater、Rack::Cache等会全量缓冲响应体的中间件，这类中间件会完全抵消流式传输的内存优化效果，直接占用和ZIP大小相当的内存
• 验证内存复用逻辑：连续触发5次相同大小的ZIP下载，若第3次之后内存不再继续上涨，即可确认是MRI内存保留机制导致的问题
• 检查Web服务器配置：若使用Puma，确认permanent_request_timeout、first_byte_timeout参数配置合理，避免慢连接导致响应对象长时间驻留内存

修复方案 #

• 替换内存分配器：使用jemalloc替代系统默认的glibc malloc，jemalloc对Ruby这类高频小对象分配的场景做了专门优化，会主动将长时间空闲的内存页归还操作系统，在Heroku上可直接通过官方支持的jemalloc buildpack配置启用，实测内存占用可降低30%~40%
• 调整流式块大小：将ZipTricks的输出块大小调整为32KB~64KB，减少小对象创建频率，降低内存碎片化程度
• 配置dyno定期重启：如果不想调整运行时配置，可设置Heroku dyno每日低峰期自动重启，主动释放进程持有的全部内存
• 大文件走异步生成逻辑：若单ZIP大小普遍超过200MB，放弃实时流式下载方案，改为后台异步生成ZIP上传到对象存储，再给用户返回临时下载链接，完全规避web进程的内存压力

内容的提问来源于stack exchange，提问作者taylorthurlow