configuration.rst 7.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265
  1. ============================
  2. Configuration and defaults
  3. ============================
  4. This document describes the configuration options available.
  5. If you're using celery in a Django project these settings should be defined
  6. in your projects ``settings.py`` file. In a regular Python environment using
  7. the default loader you must create the ``celeryconfig.py`` module and make
  8. sure it is available on the Python path.
  9. Concurrency settings
  10. ====================
  11. * CELERYD_CONCURRENCY
  12. The number of concurrent worker processes, executing tasks simultaneously.
  13. Defaults to the number of CPUs in the system.
  14. Task result backend settings
  15. ============================
  16. * CELERY_BACKEND
  17. The backend used to store task results (tombstones).
  18. Can be one of the following:
  19. * database (default)
  20. Use a relational database supported by the Django ORM.
  21. * cache
  22. Use memcached to store the results.
  23. * mongodb
  24. Use MongoDB to store the results.
  25. * tyrant
  26. Use Tokyo Tyrant to store the results.
  27. * CELERY_PERIODIC_STATUS_BACKEND
  28. The backend used to store the status of periodic tasks.
  29. Can be one of the following:
  30. * database (default)
  31. Use a relational database supported by the Django ORM.
  32. * mongodb
  33. Use MongoDB.
  34. Database backend settings
  35. =========================
  36. This applies to both the result store backend and the periodic status
  37. backend.
  38. Please see the Django ORM database settings documentation:
  39. http://docs.djangoproject.com/en/dev/ref/settings/#database-engine
  40. If you use this backend make sure to initialize the database tables
  41. after configuration. When using celery with a Django project this
  42. means executing::
  43. $ python manage.py syncdb
  44. When using celery in a regular Python environment you have to execute::
  45. $ celeryinit
  46. Example configuration
  47. ---------------------
  48. .. code-block:: python
  49. DATABASE_ENGINE="mysql"
  50. DATABASE_USER="myusername"
  51. DATABASE_PASSWORD="mypassword"
  52. DATABASE_NAME="mydatabase"
  53. DATABASE_HOST="localhost"
  54. Cache backend settings
  55. ----------------------
  56. Please see the documentation for the Django cache framework settings:
  57. http://docs.djangoproject.com/en/dev/topics/cache/#memcached
  58. Example configuration
  59. ---------------------
  60. Using a single memcached server:
  61. .. code-block:: python
  62. CACHE_BACKEND = 'memcached://127.0.0.1:11211/'
  63. Using multiple memcached servers:
  64. .. code-block:: python
  65. CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11211/'
  66. Tokyo Tyrant backend settings
  67. =============================
  68. **NOTE** The Tokyo Tyrant backend requires the :mod:`pytyrant` library:
  69. http://pypi.python.org/pypi/pytyrant/
  70. This backend requires the following configuration variables to be set:
  71. * TT_HOST
  72. Hostname of the Tokyo Tyrant server.
  73. * TT_PORT
  74. The port the Tokyo Tyrant server is listening to.
  75. Example configuration
  76. ---------------------
  77. .. code-block:: python
  78. TT_HOST = "localhost"
  79. TT_PORT = 1978
  80. MongoDB backend settings
  81. ========================
  82. * CELERY_MONGODB_BACKEND_SETTINGS
  83. This is a dict supporting the following keys
  84. * host
  85. Hostname of the MongoDB server.
  86. * port
  87. The port the MongoDB server is listening to.
  88. * user
  89. Username to authenticate to the MongoDB server as.
  90. * password
  91. * database
  92. The database name to connect to.
  93. * taskmeta_collection
  94. FIXME
  95. * periodictaskmeta_collection
  96. FIXME
  97. Logging
  98. =======
  99. * CELERYD_LOG_FILE
  100. The default filename the worker daemon logs messages to, can be
  101. overridden using the `--logfile`` option to ``celeryd``.
  102. The default is to log using ``stderr`` if running in the foreground,
  103. when running in the background, detached as a daemon, the default
  104. logfile is ``celeryd.log``.
  105. * CELERYD_DAEMON_LOG_LEVEL
  106. Worker log level, can be any of ``DEBUG``, ``INFO``, ``WARNING``,
  107. ``ERROR``, ``CRITICAL``, or ``FATAL``.
  108. See the :mod:`logging` module for more information.
  109. * CELERYD_DAEMON_LOG_FORMAT
  110. The format to use for log messages. Can be overridden using
  111. the ``--loglevel`` option to ``celeryd``.
  112. Default is ``[%(asctime)s: %(levelname)s/%(processName)s] %(message)s``
  113. See the Python :mod:`logging` module for more information about log
  114. formats.
  115. Process settings
  116. ================
  117. * CELERYD_PID_FILE
  118. Full path to the daemon pid file. Default is ``celeryd.pid``.
  119. Can be overridden using the ``--pidfile`` option to ``celeryd``.
  120. Broker settings
  121. ===============
  122. * CELERY_AMQP_EXCHANGE
  123. Name of the AMQP exchange.
  124. * CELERY_AMQP_EXCHANGE_TYPE
  125. The type of exchange. If the exchange type is ``direct``, all messages
  126. receives all tasks. However, if the exchange type is ``topic``, you can
  127. route e.g. some tasks to one server, and others to the rest.
  128. See `Exchange types and the effect of bindings`_.
  129. .. _`Exchange types and the effect of bindings`:
  130. http://bit.ly/wpamqpexchanges
  131. * CELERY_AMQP_PUBLISHER_ROUTING_KEY
  132. The default AMQP routing key used when publishing tasks.
  133. * CELERY_AMQP_CONSUMER_ROUTING_KEY
  134. The AMQP routing key used when consuming tasks.
  135. * CELERY_AMQP_CONSUMER_QUEUE
  136. The name of the AMQP queue.
  137. * CELERY_AMQP_CONSUMER_QUEUES
  138. Dictionary defining multiple AMQP queues.
  139. * CELERY_AMQP_CONNECTION_TIMEOUT
  140. The timeout in seconds before we give up establishing a connection
  141. to the AMQP server. Default is 4 seconds.
  142. * CELERY_AMQP_CONNECTION_RETRY
  143. Automatically try to re-establish the connection to the AMQP broker if
  144. it's lost.
  145. The time between retries is increased for each retry, and is
  146. not exhausted before ``CELERY_AMQP_CONNECTION_MAX_RETRIES`` is exceeded.
  147. This behaviour is on by default.
  148. * CELERY_AMQP_CONNECTION_MAX_RETRIES
  149. Maximum number of retries before we give up re-establishing a connection
  150. to the AMQP broker.
  151. If this is set to ``0`` or ``None``, we will retry forever.
  152. Default is 100 retries.
  153. Task execution settings
  154. =======================
  155. * SEND_CELERY_TASK_ERROR_EMAILS
  156. If set to ``True``, errors in tasks will be sent to admins by e-mail.
  157. If unset, it will send the e-mails if ``settings.DEBUG`` is False.
  158. * CELERY_ALWAYS_EAGER
  159. If this is ``True``, all tasks will be executed locally by blocking
  160. until it is finished. ``apply_async`` and ``delay_task`` will return
  161. a :class:`celery.result.EagerResult` which emulates the behaviour of
  162. an :class:`celery.result.AsyncResult`.
  163. Tasks will never be sent to the queue, but executed locally
  164. instead.
  165. * CELERY_TASK_RESULT_EXPIRES
  166. Time (in seconds, or a :class:`datetime.timedelta` object) for when after
  167. stored task tombstones are deleted.
  168. **NOTE**: For the moment this only works for the database and MongoDB
  169. backends.
  170. * CELERY_TASK_SERIALIZER
  171. A string identifying the default serialization
  172. method to use. Can be ``pickle`` (default),
  173. ``json``, ``yaml``, or any custom serialization methods that have
  174. been registered with :mod:`carrot.serialization.registry`.
  175. Default is ``pickle``.