Rails 3.2下Sidekiq并发数>1时任务无法处理求助

这种情况我之前在维护老Rails项目时碰到过类似的，结合Rails 3.2和Sidekiq的特性，你可以从这几个方向逐一排查：

1. 线程安全问题 #

Rails 3.2不是默认线程安全的（Rails 4之后才开启默认线程安全模式），如果你的任务代码里用到了非线程安全的逻辑，比如全局可变变量、未正确封装的类实例变量，或者一些老旧的第三方gem没有做线程安全处理，多并发时就会出现任务卡住的情况。
你可以先写一个极简的测试任务（比如只打印日志+sleep几秒），把并发数设为2试试，如果这个测试任务能正常完成，那基本可以确定是业务代码里存在线程安全隐患。

2. 数据库连接池配置 #

Sidekiq的并发数不能超过数据库连接池的大小，否则会出现线程等待数据库连接的情况，看起来任务一直在"busy"状态但无法推进。
检查你的database.yml里的pool参数，比如如果Sidekiq并发设为2，数据库连接池至少要设为2（最好给Web进程留1-2个余量，比如设为4）。另外，Rails 3.2里有时候需要在Sidekiq初始化文件里手动处理连接回收，避免连接泄漏。

3. 资源竞争或死锁 #

如果多个任务需要竞争同一个资源（比如同一条数据库行的排他锁、本地文件锁、外部服务的并发连接限制），多并发时可能会出现死锁或者长时间等待的情况。

• 可以查看数据库的死锁日志（比如PostgreSQL的pg_locks视图，MySQL的SHOW ENGINE INNODB STATUS），看有没有等待锁的线程；
• 在任务的关键步骤添加日志，追踪任务执行到哪一步卡住了。

4. Sidekiq版本兼容性 #

Rails 3.2是比较老旧的版本，要确认你使用的Sidekiq版本是否和它兼容。比如Sidekiq 4.x及以后的版本对Rails的要求更高，可能和Rails 3.2存在兼容性问题，导致多线程环境下出现异常。建议换成Sidekiq 3.x系列的稳定版本（这是官方支持Rails 3.2的最后一个大版本）。

5. 服务器资源限制 #

如果服务器的内存不足，当Sidekiq并发数提升时，进程可能因为内存耗尽被系统OOM杀死，或者频繁swap导致性能急剧下降，任务无法正常执行。
用top或htop命令监控Sidekiq进程的内存使用情况，看看并发数设为2时内存占用是不是飙升到了服务器的限制阈值。

6. 任务中的阻塞操作 #

如果任务里有同步的阻塞操作（比如长时间的HTTP请求、大文件IO、慢查询），多并发时这些操作可能会导致线程被长时间占用，看起来任务一直处于busy状态但无法完成。
检查任务里的阻塞逻辑，比如外部服务是不是有并发请求限制（比如同一个IP只能同时发起1个请求），或者数据库查询有没有添加合适的索引导致慢查询。

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