Sidekiq内存泄漏问题分析与解决方案

问题背景

在使用Sidekiq和Sidekiq-Pro的过程中，Redis服务器出现了内存缓慢增长的问题。经过深入调查，发现这与Sidekiq批处理(batch)机制中的键过期策略密切相关。

技术分析

Sidekiq中的TTL机制

Sidekiq为临时数据设置了TTL(生存时间)，包括：

• 批处理数据(batch data)
• 速率限制器(rate limiters)
• 唯一锁(unique locks)
• 进程心跳(process heartbeats)

而全局数据结构如队列、重试集、调度集等则不会设置TTL，因为这些数据结构需要长期存在。

批处理的生命周期

批处理数据在Redis中的存储时间由几个关键因素决定：

1. 成功完成的批处理：默认会保留24小时(LINGER常量)，这是为了支持Status#poll等API检查批处理状态。

2. 失败的批处理：当批处理中的作业耗尽重试次数后，会被标记为"死亡"状态。这类批处理会保留180天(dead_timeout_in_seconds默认值)。

内存增长原因

内存缓慢增长的主要原因包括：

1. 每日创建的批处理数量不断增加
2. 成功批处理默认保留24小时，导致重叠的批处理占用内存
3. 失败批处理保留时间过长(180天)

解决方案

调整批处理保留时间

1. 成功批处理的LINGER时间：

Sidekiq::Batch::LINGER = 3600 # 设置为1小时

这可以显著减少成功批处理占用的内存时间。

2. 失败批处理的dead_timeout_in_seconds：

Sidekiq.configure_server do |config|
  config.dead_timeout_in_seconds = 30 * 24 * 3600 # 30天
end

虽然可以设置更短，但不建议低于30天，以便有足够时间处理可能的作业恢复。

批处理状态转换机制

1. 批处理失败条件：当批处理中的任一作业耗尽重试次数时，整个批处理会被标记为失败。

2. 失败批处理存储：所有失败作业会存储在同一个"b-{bid}-died"键下，而不是为每个失败作业创建单独的键。

3. 成功批处理清理：成功完成的批处理会在LINGER时间后从Redis中自动删除。

最佳实践建议

1. 根据业务需求合理设置LINGER时间，平衡内存使用和调试需求。

2. 监控批处理的成功率，优化容易失败的作业，减少失败批处理的数量。

3. 定期检查Redis内存使用情况，使用Redis命令分析大键和过期策略。

4. 考虑升级到最新版本的Sidekiq-Pro，其中对批处理的内存管理有所优化。

通过合理配置这些参数，可以有效控制Redis内存增长，同时保持系统的稳定性和可维护性。