RQ 工作进程异常终止问题分析与解决方案

问题背景

在使用Python RQ任务队列系统时，部分用户报告了工作进程(worker)异常终止的问题。具体表现为作业被意外移动到失败作业注册表(FailedJobRegistry)，并伴随错误信息："Work-horse terminated unexpectedly; waitpid returned 134 (signal 6)"。

技术分析

信号6的含义

信号6(SIGABRT)是操作系统发送的异常终止信号，通常由程序自身调用abort()函数触发。这表明工作进程遇到了严重错误而主动终止，而非被外部强制杀死。

可能的原因

1. 内存问题：工作进程可能因内存不足或内存泄漏而被终止
2. Python运行时错误：如未捕获的异常、递归过深等
3. C扩展模块崩溃：某些Python C扩展中的bug可能导致进程abort
4. 系统资源限制：如ulimit设置过低

环境差异分析

问题在生产环境(EC2+ElastiCache)出现而在本地开发环境无法复现，可能原因包括：

• 生产环境负载更高，更容易暴露资源竞争问题
• 网络延迟差异导致Redis连接行为不同
• 生产环境使用了不同版本的依赖库

解决方案

1. 实现失败回调机制

RQ提供了作业回调功能，可以通过实现on_failure回调来捕获和处理这类失败：

def failure_handler(job, exc_type, exc_value, traceback):
    # 自定义失败处理逻辑
    logger.error(f"Job {job.id} failed with {exc_type}: {exc_value}")

queue.enqueue(work_function, on_failure=failure_handler)

2. 增强日志记录

在RQ配置中启用DEBUG级别日志，并在工作进程启动时添加详细日志：

import logging
logging.basicConfig(level=logging.DEBUG)

3. 资源监控与限制

对于内存密集型任务，可以：

• 使用rq worker --max-mem-per-child限制单个工作进程内存
• 设置适当的--job-monitoring-interval来更频繁地检查工作进程状态

4. 优雅的错误处理

在工作函数中添加全面的异常捕获：

def work_function(*args, **kwargs):
    try:
        # 实际工作代码
    except Exception as e:
        logger.exception("Work function failed")
        raise  # 仍将作业标记为失败，但记录了完整信息

最佳实践建议

1. 环境一致性：尽量保持开发、测试和生产环境的一致性
2. 渐进式部署：新版本RQ应先在小规模生产环境测试
3. 监控告警：对失败作业设置监控告警
4. 资源隔离：对不同类型的任务使用不同的工作队列
5. 定期维护：定期重启长时间运行的工作进程

总结

RQ工作进程的SIGABRT问题通常表明底层存在严重错误。通过实现适当的错误处理机制、增强监控和日志记录，可以更好地诊断和处理这类问题。对于生产环境，建议结合系统级监控(如内存、CPU使用率)来全面分析问题根源。