Periodic Tasks

• Introduction
• Entries
• Starting the Scheduler

By default the entries are taken from the CELERYBEAT_SCHEDULE setting, but custom stores can also be used, like storing the entries in an SQL database.

You have to ensure only a single scheduler is running for a schedule at a time, otherwise you would end up with duplicate tasks. Using a centralized approach means the schedule does not have to be synchronized, and the service can operate without using locks.

The periodic task schedules uses the UTC time zone by default, but you can change the time zone used using the setting.

An example time zone could be Europe/London:

This setting must be added to your app, either by configuration it directly using (app.conf.CELERY_TIMEZONE = ‘Europe/London’), or by adding it to your configuration module if you have set one up using app.config_from_object. See Configuration for more information about configuration options.

The default scheduler (storing the schedule in the celerybeat-schedule file) will automatically detect that the time zone has changed, and so will reset the schedule itself, but other schedulers may not be so smart (e.g. the Django database scheduler, see below) and in that case you will have to reset the schedule manually.

Django Users

Celery recommends and is compatible with the new USE_TZ setting introduced in Django 1.4.

For Django users the time zone specified in the TIME_ZONE setting will be used, or you can specify a custom time zone for Celery alone by using the setting.

The database scheduler will not reset when timezone related settings change, so you must do this manually:

>>> from djcelery.models import PeriodicTask
>>> PeriodicTask.objects.update(last_run_at=None)

To schedule a task periodically you have to add an entry to the CELERYBEAT_SCHEDULE setting.

Example: Run the tasks.add task every 30 seconds.

注解

Using a for the schedule means the task will be sent in 30 second intervals (the first task will be sent 30 seconds after celery beat starts, and then every 30 seconds after the last run).

A crontab like schedule also exists, see the section on Crontab schedules.

Like with cron, the tasks may overlap if the first task does not complete before the next. If that is a concern you should use a locking strategy to ensure only one instance can run at a time (see for example ).

• task

• schedule

  The frequency of execution.

  This can be the number of seconds as an integer, a timedelta, or a . You can also define your own custom schedule types, by extending the interface of schedule.

• args

• kwargs

  Keyword arguments ().

• options

• relative

  By default timedelta schedules are scheduled “by the clock”. This means the frequency is rounded to the nearest second, minute, hour or day depending on the period of the timedelta.

  If relative is true the frequency is not rounded and will be relative to the time when celery beat was started.

If you want more control over when the task is executed, for example, a particular time of day or day of the week, you can use the schedule type:

    # Executes every Monday morning at 7:30 A.M
    'add-every-monday-morning': {
        'task': 'tasks.add',
        'schedule': crontab(hour=7, minute=30, day_of_week=1),
    },
}

The syntax of these crontab expressions are very flexible. Some examples:

See celery.schedules.crontab for more documentation.

To start the celery beat service:

You can also start embed beat inside the worker by enabling workers -B option, this is convenient if you will never run more than one worker node, but it’s not commonly used and for that reason is not recommended for production use:

$ celery worker -B

Beat needs to store the last run times of the tasks in a local database file (named celerybeat-schedule by default), so it needs access to write in the current directory, or alternatively you can specify a custom location for this file:

注解

To daemonize beat see .

Custom scheduler classes can be specified on the command-line (the -S argument). The default scheduler is celery.beat.PersistentScheduler, which is simply keeping track of the last run times in a local database file (a ).

$ celery -A proj beat -S djcelery.schedulers.DatabaseScheduler

Using django-celery‘s scheduler you can add, modify and remove periodic tasks from the Django Admin.