本文主要介绍最近使用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

 

 posted on 2017-07-08 15:03  TerrellChen  阅读(6171)  评论(1编辑  收藏  举报