在我的Django应用程序(在ElasticBean秸秆上)中,我使用芹菜和RabbitMQ一起管理后台任务,并使用Supervisor将其去管理。现在的问题是,我定义的期间任务之一失败了(在它正常工作的一周之后),我得到的错误是:
[01/Apr/2014 23:04:03] [ERROR] [celery.worker.job:272] Task clean-dead-sessions[1bfb5a0a-7914-4623-8b5b-35fc68443d2e] raised unexpected: WorkerLostError('Worker exited prematurely: signal 9 (SIGKILL).',)
Traceback (most recent call last):
File "/opt/python/run/venv/lib/python2.7/site-packages/billiard/pool.py", line 1168, in mark_as_worker_lost
human_status(exitcode)),
WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL).
由主管管理的所有进程都已启动并正常运行(supervisorctl status
表示运行)。
我试图读取ec2实例上的几个日志,但似乎没有人帮助我找出SIGKILL
的原因。我该怎么办?我怎么调查?
这是我的芹菜设置
CELERY_TIMEZONE = 'UTC'
CELERY_TASK_SERIALIZER = 'json'
CELERY_ACCEPT_CONTENT = ['json']
BROKER_URL = os.environ['RABBITMQ_URL']
CELERY_IGNORE_RESULT = True
CELERY_DISABLE_RATE_LIMITS = False
CELERYD_HIJACK_ROOT_LOGGER = False
这是我的supervisord.conf
[program:celery_worker]
environment=$env_variables
directory=/opt/python/current/app
command=/opt/python/run/venv/bin/celery worker -A com.cygora -l info --pidfile=/opt/python/run/celery_worker.pid
startsecs=10
stopwaitsecs=60
stopasgroup=true
killasgroup=true
autostart=true
autorestart=true
stdout_logfile=/opt/python/log/celery_worker.stdout.log
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=10
stderr_logfile=/opt/python/log/celery_worker.stderr.log
stderr_logfile_maxbytes=5MB
stderr_logfile_backups=10
numprocs=1
[program:celery_beat]
environment=$env_variables
directory=/opt/python/current/app
command=/opt/python/run/venv/bin/celery beat -A com.cygora -l info --pidfile=/opt/python/run/celery_beat.pid --schedule=/opt/python/run/celery_beat_schedule
startsecs=10
stopwaitsecs=300
stopasgroup=true
killasgroup=true
autostart=false
autorestart=true
stdout_logfile=/opt/python/log/celery_beat.stdout.log
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=10
stderr_logfile=/opt/python/log/celery_beat.stderr.log
stderr_logfile_maxbytes=5MB
stderr_logfile_backups=10
numprocs=1
编辑1
在重新启动芹菜击败之后,问题依然存在。
编辑2
将killasgroup=true
改为killasgroup=false
,问题仍然存在。
发布于 2014-04-03 16:52:49
您的员工收到的SIGKILL是由另一个进程启动的。您的supervisord配置看起来很好,而且杀死组只会影响一个主管启动的杀死(例如ctl或插件)-如果没有这个设置,它将发送信号给调度员,而不是孩子。
最有可能的情况是,您的内存泄漏,而操作系统的目标是暗杀您的进程的不良行为。
grep oom /var/log/messages
。如果你看到留言,那就是你的问题。
如果找不到任何东西,请尝试在shell中手动运行周期性进程:
MyPeriodicTask().run()
看看会发生什么。如果您没有很好的工具,比如仙人掌、ganglia等,我会在另一个终端上监视系统和处理度量。
发布于 2021-06-14 20:38:19
当异步任务(通过芹菜)或您正在使用的脚本由于泄漏而将大量数据存储在内存中时,就会看到这种错误。
在我的例子中,我从其他系统获取数据并将其保存在一个变量上,以便在完成整个过程后,我可以导出所有数据(到Django模型/ Excel文件中)。
这是陷阱。我的脚本正在收集1000万个数据;当我收集数据时,它正在泄漏内存。这导致出现了例外情况。
为了克服这个问题,我将1,000万份数据分成20部分(每部分50万份)。每次数据长度达到50万项时,我都将数据存储到自己喜欢的本地文件/ Django模型中。我对每一批500 000件物品都重复一遍。
不需要执行分区的确切数目。它是将复杂问题分解为多个子问题,逐个求解子问题的思想。:D
https://stackoverflow.com/questions/22805079
复制相似问题