Sidekiq中周期性任务停止运行的故障排查与解决方案

问题现象分析

在使用Sidekiq Enterprise 7.2.4版本时，发现周期性任务(cron jobs)会在运行一段时间后停止执行，直到手动重启Sidekiq服务才能恢复。这种问题在涉及网络文件系统访问的任务中尤为明显，表现为：

1. 任务不再按计划执行
2. 任务既不在"busy"队列也不在"scheduled"队列中
3. 系统线程资源未被释放

根本原因定位

通过GDB调试工具分析线程堆栈，发现关键线索：

1. 存在名为"agent_thread"的线程在执行DNS查询时卡住
2. 网络IO操作（特别是SMB挂载的文件系统访问和FTP操作）是主要诱因
3. 周期性任务管理器(enqueue loop)的执行流程被中断

解决方案

1. DNS解析优化

在Sidekiq初始化文件中添加纯Ruby的DNS解析器：

require "resolv"

这可以避免系统级DNS查询可能导致的阻塞问题。

2. 网络IO操作防护

对于需要访问网络文件系统的任务：

1. 设置合理的超时机制
2. 使用begin-rescue块捕获异常
3. 考虑将长时间运行的任务拆分为多个小任务

3. 线程监控与恢复

建议实现以下防护措施：

Sidekiq.configure_server do |config|
  config.death_handlers << ->(job, ex) do
    # 自定义异常处理逻辑
  end
end

最佳实践建议

1. 版本选择：如遇类似问题，可考虑回退到稳定版本（如Enterprise 7.2.2）

2. 日志分析：确保配置了JSON格式的日志输出，便于问题追踪

config.logger.formatter = Sidekiq::Logger::Formatters::JSON.new

3. 资源隔离：对关键任务使用专用线程池

config.capsule("critical") do |cap|
  cap.concurrency = 2
  cap.queues = %w[critical]
end

4. 监控指标：建议实现以下监控点：
   • 周期性任务最后一次执行时间
   • 线程池使用情况
   • 任务执行耗时分布

总结

Sidekiq周期性任务中断问题通常与底层系统调用阻塞或资源耗尽有关。通过优化DNS解析、加强网络IO防护、合理配置线程池等措施，可以有效提高任务执行的稳定性。对于生产环境，建议建立完善的任务健康检查机制，确保能及时发现和处理类似问题。