Celery Worker卡在logging模块acquire方法问题求助

环境信息 #

• Celery 5.2.7
• RabbitMQ
• Django 3.2.7
• Worker启动命令：

celery -A APP_NAME worker -l info -c 8 -P threads -Q main_server_queue,document_queue --without-gossip

问题情况 #

Worker处理随机数量任务后就挂死，必须手动重启；挂起时RabbitMQ正常，但看不到Celery消费者。用strace追踪发现进程卡在futex调用，py-spy分析后确认所有8个线程都堵在logging/__init__.py:903的acquire方法上，第三方库的日志也掺和在里面。去掉-l info参数后挂起频率降了，但还是会触发锁阻塞，确定是日志锁的问题。

解决办法 #

1. 换用线程安全的日志处理器

Python标准logging模块的全局锁在多线程场景下容易出问题，试试用concurrent_log_handler库的ConcurrentRotatingFileHandler替代默认的文件处理器——它靠文件系统原子操作实现线程安全，能避开全局锁竞争。

• 安装库：pip install concurrent-log-handler
• Django配置示例（settings.py）：

from concurrent_log_handler import ConcurrentRotatingFileHandler
import logging
import os

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'celery_file': {
            'level': 'INFO',
            'class': 'concurrent_log_handler.ConcurrentRotatingFileHandler',
            'filename': os.path.join(BASE_DIR, 'logs', 'celery.log'),
            'maxBytes': 1024*1024*5,  # 单日志文件5MB
            'backupCount': 5,  # 保留5个备份
            'formatter': 'celery_verbose',
        },
    },
    'loggers': {
        'celery': {
            'handlers': ['celery_file'],
            'level': 'INFO',
            'propagate': False,
        },
        # 把第三方库的日志也绑定到这个处理器
        'third_party_lib': {
            'handlers': ['celery_file'],
            'level': 'INFO',
            'propagate': False,
        },
    },
    'formatters': {
        'celery_verbose': {
            'format': '{levelname} {asctime} {module} {thread:d} {message}',
            'style': '{',
        },
    },
}

2. 禁用Celery日志传播

Celery默认会把日志传播到根日志器，这会加重锁竞争。在Django的settings.py或者Celery单独的配置文件里加这段：

CELERY_LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'loggers': {
        'celery': {
            'level': 'INFO',
            'propagate': False,
        },
    },
}

3. 改用进程池替代线程池

如果业务允许，把Celery的并发模型从线程（-P threads）改成默认的prefork进程模型——进程之间没有共享的全局锁，能彻底避开线程间的日志锁竞争。
修改后的启动命令：

celery -A APP_NAME worker -l info -c 8 -Q main_server_queue,document_queue --without-gossip

（去掉-P threads参数即可）
注意：进程模型的内存占用比线程高，但对于IO密集型任务影响不大，且能彻底解决锁死锁问题。

4. 优化日志锁粒度

要是必须用线程模型，就想办法缩小日志锁的影响范围：

• 给每个线程创建独立的日志器实例，避免多个线程抢同一个全局锁；
• 用logging.LoggerAdapter给不同线程的日志加上唯一标识，同时确保日志处理器使用细粒度锁。

问题根源 #

Python标准logging模块的acquire方法用的是全局互斥锁，在Celery线程池高并发处理任务时，多个线程同时输出日志（包括第三方库的日志），很容易出现锁等待队列过长，甚至因锁获取顺序问题导致死锁，最终所有线程都堵在锁获取步骤，Worker直接挂死。

内容的提问来源于stack exchange，提问作者Chetan Dhanraj Patil