如何避免Sidekiq循环处理数据时内存膨胀？解析内存未复用原因

数据老陈

2026-5-15

Sidekiq任务处理大型JSON时内存膨胀问题

问题描述

我有一个通过Sidekiq执行的简单任务，该任务加载大型JSON文件并在数据库中创建/更新记录。以下是任务简化版本：

def call
  clients_data = HTTParty.get(@url).parsed_response
  create_or_update_clients(clients_data)
end

private

def create_or_update_clients(clients_data)
  clients_data.each do |client_item|
    begin
      process_remote_client(client_item)
    rescue => e
      Appsignal.add_exception(e)
    end
  end
end

def process_remote_client(client_item)
  client = Client.find_or_initialize_by(reference: client_item['ID']) do |new_client|
    new_client.company = @company
  end
  client.save!
end

尽管采用循环处理数据，但内存仍随时间增长，最终因内存消耗超出阈值导致Sidekiq重启。请问为何内存未被复用？如何避免该内存膨胀问题？

分析与解决方案

为什么内存没被复用？

核心问题不是循环本身，而是几个Ruby/Rails特性导致内存无法及时回收：

ActiveRecord对象缓存（Identity Map）：每次调用find_or_initialize_by时，ActiveRecord会把创建/查询到的Client实例存入内存缓存，哪怕处理完对象，这些实例也不会立即被GC回收，累积后会占用大量内存。
一次性加载整个JSON：HTTParty.get(@url).parsed_response会把大型JSON直接解析成Ruby哈希数组，这个大对象会一直驻留内存直到任务结束。
Ruby GC延迟性：Ruby垃圾回收不是实时触发的，只有当内存达到内部阈值时才会启动。如果任务内存增长速度快于GC触发速度，就会先触达Sidekiq的内存限制导致重启。
异常上下文与监控数据：rescue块会保留异常的调用栈上下文，加上Appsignal记录异常时可能持有对象引用，进一步延缓了内存释放。

具体解决办法

1. 流式处理JSON，避免一次性加载全部

最有效的方式是不把整个JSON加载到内存，用流式解析逐对象处理。推荐配合yajl-ruby流式JSON库和HTTParty的流式响应：

# 先添加gem到Gemfile：gem 'yajl-ruby'
def call
  counter = 0
  HTTParty.get(@url, stream_body: true) do |fragment|
    parser = Yajl::Parser.new do |client_item|
      begin
        process_remote_client(client_item)
        # 每处理100个对象手动触发GC，帮助回收内存
        GC.start if (counter += 1) % 100 == 0
      rescue => e
        Appsignal.add_exception(e)
      end
    end
    parser << fragment
  end
end

这样每次只处理一个JSON对象，不会把整个数据集都放在内存中。

2. 绕过ActiveRecord对象缓存，减少实例驻留

如果必须一次性加载JSON，可以用uncached块让ActiveRecord不缓存实例，处理后手动清理关联缓存：

def process_remote_client(client_item)
  Client.uncached do
    client = Client.find_or_initialize_by(reference: client_item['ID']) do |new_client|
      new_client.company = @company
    end
    client.save!
    # 手动清理对象关联缓存，帮助GC回收
    client.clear_association_cache
    client.destroyed_by_association = nil
  end
end

也可以在分批处理后调用Client.connection.clear_query_cache清理查询缓存。

3. 用数据库级Upsert代替对象实例化

Rails 6+支持的upsert方法直接在数据库层面执行「存在则更新，不存在则创建」，完全不需要实例化ActiveRecord对象，内存开销大幅降低：

def process_remote_client(client_item)
  Client.upsert(
    { reference: client_item['ID'], company_id: @company.id },
    unique_by: :reference # 确保reference字段是唯一索引
  )
end

这个方法跳过ActiveRecord对象生命周期，直接生成SQL执行，内存占用几乎可以忽略。

4. 分批处理记录，定期清理与GC

如果无法流式解析，就把数据集分成小批次处理，每批处理完主动清理缓存并触发GC：

def create_or_update_clients(clients_data)
  clients_data.each_slice(100) do |batch|
    batch.each do |client_item|
      begin
        process_remote_client(client_item)
      rescue => e
        Appsignal.add_exception(e)
      end
    end
    # 清理查询缓存与数据库连接
    Client.connection.clear_query_cache
    ActiveRecord::Base.clear_active_connections!
    # 手动触发GC
    GC.start
  end
end

each_slice(100)的数值可以根据自身内存情况调整。

5. 调整Sidekiq的GC触发策略

在Sidekiq配置中设置任务间的GC触发，避免内存跨任务累积：

# config/initializers/sidekiq.rb
Sidekiq.configure_server do |config|
  config.on(:startup) do
    # 每处理5个任务触发一次GC
    Sidekiq.options[:gc_interval] = 5
  end
end

注意这个是针对任务间的GC，单个任务内的内存问题还是需要前面的方法解决。

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