ActiveRecord内存未释放问题求助：Sidekiq导出任务内存占用过高

你遇到的这个问题其实是Ruby MRI（以及ActiveRecord）内存管理机制的典型表现，结合你的测试结果，我们可以从几个角度拆解原因：

1. Ruby MRI的内存分配特性：不会主动归还内存给操作系统 #

Ruby的垃圾回收（GC）确实会标记并回收不再使用的对象，但不会主动把释放的内存还给操作系统——这部分内存会被保留在Ruby进程的内存池（由malloc管理）中，供后续的内存分配复用。

你的测试里，第一次加载100万条记录后，内存涨到2.4GB，GC后只降了15MB左右，这是因为：

• GC回收了ActiveRecord实例，但释放的内存依然留在进程的内存池里，进程的RSS（常驻内存）不会下降
• 第二次加载数据时，内存只小幅增长，正是因为Ruby直接复用了之前内存池里的空闲空间，不需要向操作系统申请新内存

你设置的MALLOC_ARENA_MAX=2只是限制了malloc的内存区域数量，减少内存碎片，但无法改变Ruby不主动归还内存给OS的特性。

2. ActiveRecord实例的额外内存开销 #

每个ActiveRecord实例远不止存储数据库字段的值，它还包含大量元数据：

• 属性哈希（跟踪每个字段的原始值、当前值）
• 关联缓存（即使你没定义关联，框架也会预留相关结构）
• 变更追踪、验证规则、回调上下文等

一次性创建100万个这样的实例，会让Ruby的堆内存急剧膨胀。即使GC回收了这些实例，堆的大小也不会自动收缩——Ruby只会在堆空间不足时才会扩容，不会主动缩小堆来释放内存给OS。

另外，uncached方法只是禁用了查询结果缓存，不会影响ActiveRecord实例本身的内存结构。

3. 长生命周期进程的内存累积 #

Sidekiq是长生命周期进程，和Web服务器的短生命周期worker（比如Unicorn的worker，处理一定请求后会重启）不同：

• Web请求结束后，进程可能被重启，内存会被OS回收
• 但Sidekiq进程会一直运行，内存池里的空闲空间会被持续复用，进程的RSS只会缓慢增长（或维持在高位），不会主动下降

解决建议 #

针对你的Sidekiq数据导出场景，有几个可行的优化方向：

（1）改用批量迭代，避免一次性加载所有数据 #

不要用to_a一次性把100万条记录加载到内存，而是用find_each分批处理：

Variant.limit(1_000_000).find_each(batch_size: 1000) do |variant|
  # 处理单条记录
end

这样每次只在内存中保留1000个实例，处理完一批后GC可以回收，内存占用会大幅降低。

（2）使用更轻量的数据获取方式 #

如果不需要ActiveRecord实例的功能（比如关联、验证），直接获取原始数据可以节省大量内存：

• 用pluck获取指定字段的数组：

  Variant.limit(1_000_000).pluck(:id, :sku, :price)
  

• 用select_all获取哈希数组：

  Variant.connection.select_all("SELECT * FROM variants LIMIT 1000000")
  

这两种方式都不会创建ActiveRecord实例，内存占用只有前者的几分之一。

（3）调整Ruby GC参数（针对Ruby 2.6） #

虽然Ruby 2.6没有GC.compact（Ruby 2.7+引入的堆压缩功能），但可以调整GC参数让回收更积极：
在启动Sidekiq时设置环境变量：

export RUBY_GC_HEAP_GROWTH_FACTOR=1.1
export RUBY_GC_HEAP_GROWTH_MAX_SLOTS=100000
export RUBY_GC_MALLOC_LIMIT=50000000

这些参数会让Ruby在内存增长时更频繁地触发GC，减少堆的膨胀幅度。

（4）拆分Sidekiq任务 #

把大导出任务拆分成多个小任务，比如每个任务处理10万条数据，通过Sidekiq的批量任务（或手动创建多个子任务）分散内存压力，单个任务完成后内存可以被后续任务复用，避免单个进程占用过高内存。

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