Tymczasowa kolejka wykonana w selerze

Question

Używam Selera z RabbitMQ. Ostatnio zauważyłem, że robi się wiele tymczasowych kolejek.

Więc eksperymentowali i okazało się, że gdy zadanie nie powiedzie (czyli zadania zgłasza wyjątek), następnie tymczasowy kolejka z losową nazwą (jak c76861943b0a4f3aaa6a99a6db06952c) jest utworzony i kolejka pozostaje.

Niektóre właściwości czasowego kolejce jak stwierdzono w rabbitmqadmin są następujące -

auto_delete: True konsumenci: 0 trwałe: Fałsz wiadomości: 1 messages_ready: 1

A jeden taki tymczasowy kolejka jest wykonywany za każdym razem, gdy zadanie nie powiedzie się (tzn. spowoduje wyjątek). Jak uniknąć tej sytuacji? Ponieważ w moim środowisku produkcyjnym powstaje duża liczba takich kolejek.

Answer 1

Cóż, Philip jest właśnie tutaj. Poniżej znajduje się opis tego, jak go rozwiązałem. Jest to konfiguracja w celeryconfig.py.

Nadal używam CELERY_BACKEND = "amqp", jak powiedział Philip. Ale dodatkowo używam CELERY_IGNORE_RESULT = True. Ta konfiguracja zapewni, że dodatkowe kolejki nie zostaną utworzone dla każdego zadania.

Już korzystałem z tej konfiguracji, ale nadal, gdy zadanie się nie powiedzie, utworzono dodatkową kolejkę. Następnie zauważyłem, że korzystam z innej konfiguracji, którą trzeba usunąć, czyli CELERY_STORE_ERRORS_EVEN_IF_IGNORED = True. Co to zrobiło, że nie przechowuje wyników dla wszystkich zadań, ale robiło to tylko dla błędów (zadań, które się nie powiodło), a więc jednej dodatkowej kolejki dla zadania, które się nie powiodło.

Answer 2

Wygląda na to, że używasz amqp jako zaplecza wyników. Z docs Oto pułapki za pomocą tej konkretnej konfiguracji:

• Każde nowe zadanie tworzy nową kolejkę na serwerze, z tysiącami zadań broker może być przeładowany kolejek i to wpłynie
  wydajność w negatywny sposób. Jeśli używasz RabbitMQ następnie każdy
  kolejka będzie oddzielny proces Erlang, więc jeśli planujesz
  zachować wiele wyników jednocześnie może trzeba zwiększyć Erlang
  limitu procesowego, a maksymalna liczba deskryptorów Twój OS
  pozwala
• Old wyniki nie będą automatycznie czyszczony, więc trzeba zrobić pewnością zużywają wyniki lub inny liczbę kolejek będzie ostatecznie spod kontroli. Jeśli używasz RabbitMQ 2.1.1 lub wyżej, możesz skorzystać z argumentu x-expires dla kolejek, , które wygasną w kolejkach po upływie określonego czasu po tym, jak zostaną nieużywane . Wygaśnięcie kolejki może być ustawione (w sekundach) na ustawienie CELERY_AMQP_TASK_RESULT_EXPIRES (domyślnie nie jest włączone).

Z tego co czytałem w changelog, to już nie jest domyślnym silnikiem w wersji> = 2.3.0, ponieważ użytkownicy dostawali trochę w tylnym końcu za to zachowanie. Sugerowałbym zmianę zaplecza wyników, gdyby nie ta funkcjonalność, której potrzebujesz.

Answer 3

CELERY_TASK_RESULT_EXPIRES określa czas życia kolejek tymczasowych. Wartość domyślna to 1 dzień. Możesz zmodyfikować tę wartość.

Answer 4

Powodem tego jest to, że jest włączone celery workers remote control (jest domyślnie włączone).

Można ją wyłączyć przez ustawienie ustawienie na false jednak CELERY_ENABLE_REMOTE_CONTROL pamiętać, że tracisz zdolność do robienia rzeczy jak add_consumer, cancel_consumer etc pomocą celery command

Answer 5

amqp backend tworzy nową kolejkę dla każdego zadania. Jeśli chcesz tego uniknąć, możesz użyć backendu rpc, który zachowuje wyniki w pojedynczej kolejce.

W config ustawić

CELERY_RESULT_BACKEND = 'rpc' 
CELERY_RESULT_PERSISTENT = True 

Możesz przeczytać więcej o this on celery docs.