Sidekiq处理完Excel验证任务后内存未释放问题求助

嘿，这个内存居高不下的问题在处理超大文件的Sidekiq场景里真的很常见，我来给你分享几个实用的排查方向和解决办法：

1. 先搞懂Ruby内存回收的“小特性” #

Ruby的垃圾回收（GC）确实会回收不再使用的对象，但不会主动把内存还给操作系统——也就是说，即使GC清理了堆里的对象，进程占用的内存量在操作系统层面看还是不会降下来。你手动调用GC.start能清理Ruby内部的无效对象，但内存还是留在Sidekiq进程里供后续任务复用。

如果你的容器有严格的内存限制，导致新任务无法分配内存，那这个“内存留存”就成了问题，得用下面的办法解决。

2. 让Sidekiq自动重启进程（最快见效） #

Sidekiq本身自带了进程重启的配置，能让Worker处理完一定数量的任务，或者占用内存超过阈值时自动重启，彻底释放内存。

比如在你的sidekiq.yml里加上这些配置：

:concurrency: 1  # 处理大任务建议单线程，避免内存叠加
:max_jobs: 1     # 每处理1个任务就重启进程
# 或者用内存阈值触发重启
:max_memory: 450 # 当内存超过450MB时自动重启（单位是MB）

这个方法简单粗暴但有效，尤其适合Docker这种隔离环境，重启进程后内存会直接回到初始的120MB左右。

3. 排查代码里的内存泄漏点 #

虽然你说已经做了大量优化，但还是要检查有没有“隐性泄漏”：

• 全局/类变量残留：比如有没有把处理过程中的数据存在类变量（@@xxx）或者全局变量里，任务完成后没清空？这些对象会被GC视为“仍在使用”，永远不会被回收。
• Excel对象未及时释放：如果你用了Roo、Axlsx这类库，有没有在处理完后关闭文件或者销毁工作表对象？比如调用sheet.close或者把对象置为nil。
• 流式处理代替全量加载：有没有把整个Excel文件都加载到内存里？试试用流式解析，比如Roo的each_row_streaming方法，每次只加载一行数据，而不是把20万条都存到数组里。

可以用memory_profiler gem来定位泄漏点：

# 在Worker里加入内存分析代码
require 'memory_profiler'

def perform(file_path)
  report = MemoryProfiler.report do
    # 把你的Excel处理逻辑放在这里
  end
  report.pretty_print(to_file: 'tmp/memory_report.txt')
end

运行任务后查看报告，就能看到哪些对象占用了大量内存且没有被回收。

4. 优化批次处理的内存清理 #

你已经做了每1万条处理一次的批次优化，那可以在每批处理完成后，主动清空相关对象：

def perform(file_path)
  sheet = Roo::Excelx.new(file_path)
  sheet.each_row_streaming(offset: 1, batch_size: 10000) do |batch|
    batch.each do |row|
      # 处理单条记录
    end
    # 清空当前批次的引用，帮助GC回收
    batch = nil
    GC.start
  end
  # 处理完整个文件后，销毁sheet对象
  sheet = nil
  GC.start
end

虽然Ruby的GC会自动处理，但手动清空引用能加快回收速度。

5. 调整Docker容器的内存限制 #

如果你的容器内存限制设得太严（比如刚好512MB），那内存到500MB后新任务可能触发OOM Kill。可以适当调高容器的内存上限，同时配合Sidekiq的max_memory配置，让进程在接近上限前自动重启，避免被系统强制杀死。

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