本文主要介绍最近使用celery遇到的两个坑。关于时区,以及是否保留结果(celery使用rabbitmq)。
先说结论:定时任务记得配置时区;丢弃结果对使用rabbitmq对celery来说,性能提升巨大。
第一部分:celery使用定时任务功能的时候,通常配置如下
CELERYBEAT_SCHEDULE = { 'query-every-day': { 'task': 'xxx', 'schedule': crontab(hour=16, minute=35) }, 'delete-every-1-second': { 'task': xxxx', 'schedule': crontab(minute='*/1') }, 'update-every-1-second': { 'task': 'xxxxx, 'schedule': timedelta(seconds=60) } }
针对xxxxx任务,每60秒执行一次;针对xxxx任务,每分钟执行一次;针对xxx任务,每天16时35分执行一次。
启动
celery -A start.celery beat -s celerybeat-schedule
这样配置,后面俩间隔时间执行的定时任务执行良好。
而第一个设置每天绝对时间的任务没有在配置的时间执行,查询发现有时区这个东西。需要配置如下:
CELERY_TIMEZONE = 'Asia/Shanghai'
ps:最开始尝试的'Asia/Hongkong',报错了。看来祖国大陆的地位越来越高。
第二部分:celery的是否保留结果配置
丢弃结果配置如下:
CELERY_IGNORE_RESULT = True
为什么会推荐丢弃结果呢?
在压测使用rabbitmq对celery时发现,每次执行单个的简单加减任务,会耗时0.1秒左右(慢哭)。
完成任务至7000时,rabbitmq出问题了,日志显示:
Recovering 7008 queues, avilable file handles: 4764. Please increase mas open file handles limit to at least 7008
Mnesia(rabbit@localhost): ** WARNING ** Mnesia is overloaded: {dump_log,write_threshold}
这才发现,使用rabbitmq的celery,每一次完成任务,都会为这个任务建一个队列。。。在获取这个结果之后队列才删除。
并且这个建队列的性能开销非常大:保留结果完成一个任务耗时0.1秒左右,丢弃结果平均一个任务耗时0.001秒左右
google了一下Mnesia的配置,找到有解决方案,但最后并没有使用,因为这个确实用不着保留结果,并且性能的损失不太能接受。
后来发现了一篇celery最佳实践有讲到丢弃结果这个事情:http://blog.csdn.net/siddontang/article/details/34447003