Celery: एक ही कार्य एक साथ कई बार चलता है?

को निर्मित 20 नव॰ 2017 · 43टिप्पणियाँ · स्रोत: celery/celery

समस्या एक अनअटेंडेड Google समूह पोस्ट की एक रीपोस्ट है _एक ही कार्य कई बार चलता है?_

> ./bin/celery -A celery_app report

software -> celery:4.1.0 (latentcall) kombu:4.1.0 py:3.6.1
            billiard:3.5.0.3 redis:2.10.6
platform -> system:Linux arch:64bit, ELF imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:redis results:redis://localhost:6379/2

broker_url: 'redis://localhost:6379/2'
result_backend: 'redis://localhost:6379/2'
task_serializer: 'json'
result_serializer: 'json'
accept_content: ['json']
timezone: 'Europe/Berlin'
enable_utc: True
imports: 'tasks'
task_routes: {
 'tasks': {'queue': 'celery-test-queue'}}

मेरा आवेदन दो, कभी-कभी तीन कार्यों का एक समूह निर्धारित करता है, जिनमें से प्रत्येक एक घंटे के भीतर अपने स्वयं के ईटीए के साथ। जब ईटीए आता है, तो मैं अपने सेलेरी लॉग में निम्नलिखित देखता हूं:

[2017-11-20 09:55:34,470: INFO/ForkPoolWorker-2] Task tasks._test_exec[bd08ab85-28a8-488f-ba03-c2befde10054] succeeded in 33.81780316866934s: None
[2017-11-20 09:55:34,481: INFO/ForkPoolWorker-2] Task tasks._test_exec[bd08ab85-28a8-488f-ba03-c2befde10054] succeeded in 0.009824380278587341s: None
[2017-11-20 09:55:34,622: INFO/ForkPoolWorker-2] Task tasks._test_exec[bd08ab85-28a8-488f-ba03-c2befde10054] succeeded in 0.14010038413107395s: None
…
[2017-11-20 09:55:37,890: INFO/ForkPoolWorker-8] Task tasks._test_exec[bd08ab85-28a8-488f-ba03-c2befde10054] succeeded in 0.012678759172558784s: None
[2017-11-20 09:55:37,891: INFO/ForkPoolWorker-2] Task tasks._test_exec[bd08ab85-28a8-488f-ba03-c2befde10054] succeeded in 0.01177949644625187s: None
[2017-11-20 09:55:37,899: INFO/ForkPoolWorker-8] Task tasks._test_exec[bd08ab85-28a8-488f-ba03-c2befde10054] succeeded in 0.008250340819358826s: None
…

यह दर्जनों बार दोहरा सकता है। पहले कार्य के 33 सेकंड के निष्पादन समय और विभिन्न श्रमिकों के उपयोग पर ध्यान दें !

मेरे पास इस व्यवहार के लिए कोई स्पष्टीकरण नहीं है, और मैं समझना चाहता हूं कि यहां क्या हो रहा है।

Redis Broker Redis Results Backend Feedback Needed ✘ Needs Testcase ✘

स्रोत

jenstroeger

👍26

सबसे उपयोगी टिप्पणी

@georgepsarakis तो यदि कार्य भविष्य में बहुत आगे निर्धारित है, तो मैं ऊपर देख सकता हूँ? "दृश्यता टाइमआउट" इसे संबोधित करता है? आपके द्वारा लिंक किए गए दस्तावेज़ से:

रेडिस के लिए डिफ़ॉल्ट दृश्यता समयबाह्य 1 घंटा है।

इसका अर्थ यह है कि यदि एक घंटे के भीतर कार्यकर्ता कार्य को स्वीकार नहीं करता है ( अर्थात इसे चलाता है?) दस्तावेज़ीकरण; यह संबंधित समस्या https://github.com/celery/kombu/issues/337; या इस ब्लॉग से उद्धरण:

लेकिन जब डेवलपर्स इसका उपयोग करना शुरू करते हैं, तो वे नियमित रूप से श्रमिकों के असामान्य व्यवहार का सामना करते हैं, विशेष रूप से कई श्रमिकों द्वारा एक ही कार्य के कई निष्पादन। इसका कारण दृश्यता टाइमआउट सेटिंग है।

ऐसा लगता है कि visibility_timeout को 31,540,000 सेकंड (एक वर्ष) पर सेट करना एक त्वरित समाधान हो सकता है।

jenstroeger 24 नव॰ 2017

👍7 😄2

सभी 43 टिप्पणियाँ

शायद यह दृश्यता टाइमआउट से संबंधित है?

georgepsarakis 22 नव॰ 2017

👍2

@georgepsarakis क्या आप कृपया अपने संदेह के बारे में विस्तार से बता सकते हैं?

jenstroeger 23 नव॰ 2017

जहां तक मुझे पता है, यह ब्रोकर ट्रांसपोर्ट के लिए एक ज्ञात मुद्दा है जिसमें एएमक्यूपी की अंतर्निहित पावती विशेषता नहीं है। यदि कार्य पूरा होने का समय दृश्यता समयबाह्य से अधिक हो जाता है, तो कार्य एक नए कार्यकर्ता को सौंपा जाएगा, इस प्रकार आप कार्यों को समानांतर में निष्पादित होते हुए देख सकते हैं।

georgepsarakis 24 नव॰ 2017

रेडिस के लिए डिफ़ॉल्ट दृश्यता समयबाह्य 1 घंटा है।

लेकिन जब डेवलपर्स इसका उपयोग करना शुरू करते हैं, तो वे नियमित रूप से श्रमिकों के असामान्य व्यवहार का सामना करते हैं, विशेष रूप से कई श्रमिकों द्वारा एक ही कार्य के कई निष्पादन। इसका कारण दृश्यता टाइमआउट सेटिंग है।

jenstroeger 24 नव॰ 2017

👍7 😄2

मैं कहूंगा कि यदि आप दृश्यता टाइमआउट को 2 घंटे तक बढ़ा देते हैं, तो आपके कार्य केवल एक बार निष्पादित होंगे।

तो यदि आप गठबंधन करते हैं:

रेडिस ब्रोकर
देर से पावती
ईटीए बराबर/दृश्यता समयबाह्य से ऊपर
आपको कार्य पर कई निष्पादन मिलते हैं।

मुझे लगता है कि क्या होता है:

एक घंटे बीत जाने के बाद एक कार्यकर्ता प्रक्रिया कार्य को संसाधित करना शुरू कर देती है।
दूसरा कार्यकर्ता यह देखेगा कि यह संदेश दृश्यता समयबाह्य से अधिक समय से कतार में है और किसी अन्य कार्यकर्ता द्वारा संसाधित किया जा रहा है।
संदेश कतार में पुनर्स्थापित किया गया है।
एक अन्य कार्यकर्ता उसी संदेश को संसाधित करना शुरू कर देता है।
उपरोक्त सभी कार्यकर्ता प्रक्रियाओं के लिए होता है।

रेडिस परिवहन कार्यान्वयन को देखते हुए, आप देखेंगे कि यह सॉर्ट किए गए सेट का उपयोग करता है, कतारबद्ध समय को zadd के स्कोर के रूप में पास करता है। संदेश उस टाइमस्टैम्प के आधार पर और दृश्यता टाइमआउट के बराबर अंतराल की तुलना में पुनर्स्थापित किया जाता है।

आशा है कि यह रेडिस परिवहन के आंतरिक भाग को थोड़ा सा समझाता है।

georgepsarakis 25 नव॰ 2017

👍1

@georgepsarakis , अब मैं पूरी तरह उलझन में हूं। यदि किसी कार्य का ईटीए अब से दो महीने के लिए निर्धारित किया गया है, तो कार्य निर्धारित होने के एक घंटे बाद एक कार्यकर्ता इसे क्यों उठाएगा? क्या मुझे कुछ याद नहीं आ रहा है?

मेरी (गलत?) धारणा यह है कि:

मैं भविष्य में किसी भी समय किसी ईटीए के साथ कार्य शेड्यूल करता/करती हूं; फिर
कार्य (यानी इसके मार्शल तर्क) और ईटीए ईटीए आने तक कतार में बैठे रहेंगे; फिर
एक कार्यकर्ता ईटीए में कार्य को संसाधित करना शुरू करता है।

आपका "_मुझे लगता है कि क्या होता है:_" ऊपर मेरी धारणा से काफी अलग है।

jenstroeger 27 नव॰ 2017

मुझे भी इसी समस्या का सामना करना पड़ा, क्या आपने इसे हल किया है? @ जेनस्ट्रोएगर

धन्यवाद!

zivsu 17 दिस॰ 2017

@jenstroeger जो एक व्यवहार्य प्रवाह की तरह नहीं लगता है, मुझे लगता है कि कार्यकर्ता केवल ईटीए की शर्त पूरी होने तक निष्पादन को स्थगित करने के लिए लगातार संदेश की आवश्यकता होती है। कतार की अवधारणा संदेशों को उनके आते ही वितरित करना है, इसलिए कार्यकर्ता संदेश की जांच करता है और केवल अनुरोध करता है।

कृपया ध्यान दें कि यह मेरा अनुमान है, मैं वास्तव में ईटीए कार्यान्वयन के आंतरिक पहलुओं से अवगत नहीं हूं।

georgepsarakis 17 दिस॰ 2017

@zivsu , जैसा कि ऊपर बताया गया है , मैंने visibility_timeout को _very_ बड़ी संख्या में सेट किया है और ऐसा लगता है कि लक्षणों का समाधान हो गया है। हालाँकि, जैसा कि @georgepsarakis बताते हैं, यह एक खराब दृष्टिकोण प्रतीत होता है।

मुझे मूल समस्या का कारण नहीं पता है और न ही इसे ठीक से कैसे संबोधित किया जाए।

jenstroeger 21 दिस॰ 2017

@jenstroeger मैंने कुछ ब्लॉग पढ़ा, visibility_timeout बदलें समस्या को पूरी तरह से हल नहीं कर सकता है, इसलिए मैं अपने बोर्कर को rabbitmq में बदल देता हूं।

zivsu 21 दिस॰ 2017

@zivsu , क्या आप कृपया ब्लॉग का लिंक साझा कर सकते हैं? क्या आपने पहले रेडिस का इस्तेमाल किया था?

jenstroeger 22 दिस॰ 2017

@jenstroeger मुझे ब्लॉग नहीं मिल रहा है, मैंने पहले रेडिस को ब्रोकर के रूप में इस्तेमाल किया था। शेड्यूल टास्क के लिए, मैं फिर से होने वाली त्रुटि से बचने के लिए rebbitmq चुनता हूं।

zivsu 22 दिस॰ 2017

👍2

मेरे पास बिल्कुल वही समस्या है, मेरी कॉन्फ़िगरेशन है:
django==1.11.6
अजवाइन == 4.2rc2
django-अजवाइन-बीट==1.0.1

समायोजन:

CELERY_ENABLE_UTC = True
# CELERY_TIMEZONE = 'America/Los_Angeles'

और वह इस सेटिंग का एकमात्र कार्य संयोजन है। इसके अलावा मुझे अपने आवधिक कार्यों को यूटीसी टाइमज़ोन में शेड्यूल करना होगा।
यदि आप CELERY_TIMEZONE को सक्षम करते हैं या CELERY_ENABLE_UTC को अक्षम करते हैं तो यह आवधिक कार्यों को कई बार चलाना शुरू कर देता है।

Anton-Shutik 10 अप्रैल 2018

मुझे बचाने की समस्या है। ब्रोकर के रूप में रेडिस का उपयोग करते समय ईटा टास्क एक्साइट कई गुना बढ़ जाता है।
इसे हल करने का कोई तरीका ..
इस समस्या को हल करने के लिए रेडिस से रैबिटमैक में परिवर्तन दलाल की तरह दिखें ..

ghost 27 अप्रैल 2018

😕4 👍4

जब आप UTC के अलावा कोई समय क्षेत्र निर्दिष्ट करते हैं, तो redis का उपयोग करते हुए, एक प्रसिद्ध समस्या होती है। समस्या को हल करने के लिए, डिफ़ॉल्ट ऐप को उपवर्गित करें, और अपना खुद का टाइमज़ोन हैंडलिंग फ़ंक्शन जोड़ें:

from celery import Celery


class MyAppCelery(Celery):
    def now(self):
        """Return the current time and date as a datetime."""
        from datetime import datetime
        return datetime.now(self.timezone)

उम्मीद है कि इस समस्या में चल रहे किसी और की मदद करता है।

2ps 31 मई 2018

👍3 👀1

मुझे यह समस्या कभी-कभी होती है जब मल्टीकोर मशीनों पर बीट के साथ सेलेरी जॉब को बार-बार फिर से शुरू किया जाता है। मुझे इसे हल करने के लिए ps aux | grep celery फिर kill <each_pid> चलाने की आदत हो गई है।

मेरे पास सबसे अच्छी सलाह यह है कि मशीन से डिस्कनेक्ट करने से पहले आप हमेशा यह सुनिश्चित करें कि आप "पुनरारंभ करें" संदेश देखें।

chrisconlan 26 सित॰ 2018

{"log":"INFO 2018-10-09 17:41:08,468 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T17:41:08.468912644Z"}
{"log":"INFO 2018-10-09 17:41:08,468 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T17:41:08.468955918Z"}
{"log":"INFO 2018-10-09 19:46:04,293 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T19:46:04.293780045Z"}
{"log":"INFO 2018-10-09 19:46:04,293 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T19:46:04.293953621Z"}
{"log":"INFO 2018-10-09 20:46:04,802 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T20:46:04.802819711Z"}
{"log":"INFO 2018-10-09 20:46:04,802 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T20:46:04.802974829Z"}
{"log":"INFO 2018-10-09 21:46:05,335 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T21:46:05.336081133Z"}
{"log":"INFO 2018-10-09 21:46:05,335 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T21:46:05.336107517Z"}
{"log":"INFO 2018-10-09 22:46:05,900 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T22:46:05.901078395Z"}
{"log":"INFO 2018-10-09 22:46:05,900 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T22:46:05.901173663Z"}
{"log":"INFO 2018-10-09 23:46:06,484 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T23:46:06.485276904Z"}
{"log":"INFO 2018-10-09 23:46:06,484 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T23:46:06.485415253Z"}
{"log":"INFO 2018-10-10 00:46:07,072 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T00:46:07.072529828Z"}
{"log":"INFO 2018-10-10 00:46:07,072 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T00:46:07.072587887Z"}
{"log":"INFO 2018-10-10 01:46:07,602 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T01:46:07.60325321Z"}
{"log":"INFO 2018-10-10 01:46:07,602 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T01:46:07.603327426Z"}
{"log":"INFO 2018-10-10 02:46:08,155 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T02:46:08.155868992Z"}
{"log":"INFO 2018-10-10 02:46:08,155 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T02:46:08.155921893Z"}
{"log":"INFO 2018-10-10 03:46:08,753 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T03:46:08.75401387Z"}
{"log":"INFO 2018-10-10 03:46:08,753 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T03:46:08.754056891Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.013548928Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.013592318Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:71\n","stream":"stderr","time":"2018-10-10T04:00:00.014000106Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:71\n","stream":"stderr","time":"2018-10-10T04:00:00.014167558Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:64\n","stream":"stderr","time":"2018-10-10T04:00:00.014661348Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:64\n","stream":"stderr","time":"2018-10-10T04:00:00.014684354Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.01514884Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.015249646Z"}
{"log":"DEBUG 2018-10-10 04:00:00,015 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:66\n","stream":"stderr","time":"2018-10-10T04:00:00.01571124Z"}
{"log":"DEBUG 2018-10-10 04:00:00,015 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:66\n","stream":"stderr","time":"2018-10-10T04:00:00.01580249Z"}
{"log":"DEBUG 2018-10-10 04:00:00,019 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:68\n","stream":"stderr","time":"2018-10-10T04:00:00.019260948Z"}
{"log":"DEBUG 2018-10-10 04:00:00,019 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:68\n","stream":"stderr","time":"2018-10-10T04:00:00.019322151Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.245159563Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.245177267Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:67\n","stream":"stderr","time":"2018-10-10T04:00:00.245338722Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:67\n","stream":"stderr","time":"2018-10-10T04:00:00.245351289Z"}
{"log":"DEBUG 2018-10-10 04:00:00,256 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.256770035Z"}
{"log":"DEBUG 2018-10-10 04:00:00,256 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.256788689Z"}
{"log":"INFO 2018-10-10 04:00:00,371 trace celery.app.trace 68 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.35710329699213617s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.371967002Z"}
{"log":"INFO 2018-10-10 04:00:00,371 trace celery.app.trace 68 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.35710329699213617s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.371983293Z"}
{"log":"INFO 2018-10-10 04:00:00,387 trace celery.app.trace 69 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.10637873200175818s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.388119538Z"}
{"log":"INFO 2018-10-10 04:00:00,387 trace celery.app.trace 69 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.10637873200175818s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.388166317Z"}
{"log":"INFO 2018-10-10 04:00:00,404 trace celery.app.trace 70 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.16254851799749304s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.404834545Z"}
{"log":"INFO 2018-10-10 04:00:00,404 trace celery.app.trace 70 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.16254851799749304s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.404862208Z"}
{"log":"INFO 2018-10-10 04:00:00,421 trace celery.app.trace 65 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.1654666289978195s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.421607856Z"}
{"log":"INFO 2018-10-10 04:00:00,421 trace celery.app.trace 65 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.1654666289978195s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.421674687Z"}
{"log":"INFO 2018-10-10 04:00:00,438 trace celery.app.trace 67 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.19588526099687442s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.438295459Z"}
{"log":"INFO 2018-10-10 04:00:00,438 trace celery.app.trace 67 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.19588526099687442s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.438311386Z"}
...

अगर हम प्राप्त कार्य टाइमस्टैम्प की जांच करते हैं, तो हर घंटे इसे उसी आईडी के साथ नया कार्य मिलेगा। नतीजा यह है कि सभी ईटीए संदेश 10 से अधिक बार भेजे जाते हैं। ऐसा लगता है कि यदि हम ETA का उपयोग करना चाहते हैं तो Rabbitmq ही एकमात्र विकल्प है

zetaab 10 अक्तू॰ 2018

हाल ही में इसी तरह के बग से मिलें। साथ ही ps aux | grep celery ने श्रमिकों की तुलना में दो बार अधिक प्रक्रियाएं शुरू कीं। लॉन्चिंग सेलेरी वर्कर्स को कमांड देने के लिए पैरामीटर --pool gevent को जोड़ने से प्रक्रियाओं की संख्या कम हो गई है और सटीक संख्या में शुरू हो चुके वर्कर्स और सेलेरी बीट। और अब मैं अपने कार्यों के निष्पादन को देख रहा हूँ।

Dedal-O 2 जन॰ 2019

हो सकता है कि एक और समाधान पूरी तरह से एके इम्यूलेशन को अक्षम कर रहा हो? यानी "broker_transport_options": {"ack_emulation": False} । शॉर्ट-रनिंग कार्यों/उलटी गिनती के लिए कोई कमी?

killthekitten 25 मई 2019

क्या किसी को फिक्स मिला?

auvipy 26 जून 2019

👀11

एक ही समस्या का सामना कर रहे हैं, इसका कोई समाधान?

arbazkiraak 20 सित॰ 2019

😕2

टक्कर, वही समस्या।

dghy 14 अक्तू॰ 2019

रेडिस को ब्रोकर के रूप में इस्तेमाल करते हुए यहां एक ही समस्या है।

$ pipenv graph --bare | grep -i "redis\|celery"                                                                                                                                                                                                                              
---
channels-redis==2.4.0
  - aioredis [required: ~=1.0, installed: 1.3.0]
    - hiredis [required: Any, installed: 1.0.0]
django-celery-beat==1.5.0
django-celery-results==1.1.2
  - celery [required: >=4.3,<5.0, installed: 4.3.0]
  - celery [required: >=3.1.0, installed: 4.3.0]
  - pylint-celery [required: ==0.3, installed: 0.3]
redis==3.2.1

xolan 14 अक्तू॰ 2019

वही समस्या है। अजवाइन संस्करण 4.3.0
अजवाइन = अजवाइन ('कार्य', दलाल = 'pyamqp://nosd:sdsd@rabbit//', config_from_object={"broker_transport_options":{'visibility_timeout': 18000}})

मैं अपने कार्यकर्ता को चलाने के लिए जिस आदेश का उपयोग करता हूं
अजवाइन -एक कार्य कार्यकर्ता --pidfile=/tmp/celery_worker.pid -f=/tmp/celery_worker.log -Q Celery_queue --loglevel=info --pool=solo --concurrency=1 -nworker_celery --detach -- बिना गपशप के --बिना घुलमिले -- बिना दिल की धड़कन के

alkattan 13 नव॰ 2019

क्या आप अजवाइन == 4.4.0rc4 एक कोशिश दे सकते हैं?

auvipy 13 नव॰ 2019

अजवाइन एक ही समय में एक ही कार्य आईडी के साथ दो बार एक ही कार्य प्राप्त कर रहा है ।
यहाँ लॉग हैं

[2019-11-29 08:07:35,464: INFO/MainProcess] Received task: app.jobs.booking.bookFlightTask[657985d5-c3a3-438d-a524-dbb129529443]  
[2019-11-29 08:07:35,465: INFO/MainProcess] Received task: app.jobs.booking.bookFlightTask[657985d5-c3a3-438d-a524-dbb129529443]  
[2019-11-29 08:07:35,471: WARNING/ForkPoolWorker-4] in booking funtion1
[2019-11-29 08:07:35,473: WARNING/ForkPoolWorker-3] in booking funtion1
[2019-11-29 08:07:35,537: WARNING/ForkPoolWorker-3] book_request_pp
[2019-11-29 08:07:35,543: WARNING/ForkPoolWorker-4] book_request_pp

दोनों एक साथ चल रहे हैं,

सेलेरी==4.4.0rc4, boto3==1.9.232, kombu==4.6.6 का उपयोग करते हुए अजगर फ्लास्क में SQS के साथ।
एसक्यूएस में, डिफ़ॉल्ट दृश्यता टाइमआउट 30 मिनट है, और मेरे कार्य में ईटीए नहीं है और न ही एके है।

चल रहे कार्यकर्ता की तरह,
अजवाइन कार्यकर्ता -ए app.jobs.run -l जानकारी --pidfile=/var/run/celery/celery.pid --logfile=/var/log/celery/celery.log --time-limit=7200 --concurrency =8

@auvipy , कोई मदद बहुत अच्छी होगी।

nitish-itilite 1 दिस॰ 2019

आप किस ब्रोकर और रिजल्ट बैक एंड का उपयोग कर रहे हैं? क्या आप दूसरे बैक एंड पर स्विच करने का प्रयास कर सकते हैं?

auvipy 1 दिस॰ 2019

आप किस ब्रोकर और रिजल्ट बैक एंड का उपयोग कर रहे हैं? क्या आप दूसरे बैक एंड पर स्विच करने का प्रयास कर सकते हैं?

SQS का उपयोग करते हुए, परिणाम बैकएंड MYSQL है, sqlalchemy के साथ।
विवरण यहाँ SO पर हैं,
@auvipy क्या आप कृपया देख सकते हैं।

nitish-itilite 1 दिस॰ 2019

@thedrow क्या आप ब्लूमबर्ग में इस मुद्दे का सामना करते हैं?

auvipy 1 दिस॰ 2019

@ नीतीश-इटलाइट: अजवाइन के लिए आप किस समय क्षेत्र का उपयोग कर रहे हैं?

2ps 2 दिस॰ 2019

@ नीतीश-इटलाइट: अजवाइन के लिए आप किस समय क्षेत्र का उपयोग कर रहे हैं?

यह डिफ़ॉल्ट यूटीसी है। sqs में, यह क्षेत्र US East (N. वर्जीनिया) है।

nitish-itilite 2 दिस॰ 2019

मेरे पास एसक्यूएस के साथ अजवाइन चलाने का एक समान मामला था। मैंने countdown=60 के साथ एक डमी कार्य चलाया, जबकि एसक्यूएस में दृश्यता टाइमआउट 30 सेकंड है। यहाँ मुझे क्या मिलता है:

नोट: मैंने सेलेरी को --concurrency=1 के साथ शुरू किया है, इसलिए दो धागे हैं, है ना?

[2020-02-18 14:46:32 +0000] [INFO] Received task: notification[b483a22f-31cc-4335-9709-86041baa8f05]  ETA:[2020-02-18 14:47:31.898563+00:00] 
[2020-02-18 14:47:02 +0000] [INFO] Received task: notification[b483a22f-31cc-4335-9709-86041baa8f05]  ETA:[2020-02-18 14:47:31.898563+00:00] 
[2020-02-18 14:47:32 +0000] [INFO] Task notification[b483a22f-31cc-4335-9709-86041baa8f05] succeeded in 0.012232275999849662s: None
[2020-02-18 14:47:32 +0000] [INFO] Task notification[b483a22f-31cc-4335-9709-86041baa8f05] succeeded in 0.012890915997559205s: None

कालानुक्रमिक क्रम में क्या हुआ:

14:46:32 कार्य प्राप्त हुआ, और SQS ने इसे inflight मोड में 30 सेकंड के लिए रखा
14:47:02 वही कार्य प्राप्त हुआ, क्योंकि दृश्यता समय समाप्त हो गया
14:47:32 दोनों कार्यों को एक ही समय में निष्पादित किया जाता है

मेरा अनुमान है कि यह सेलेरी (?) में एक बग है, मुझे लगता है कि इसे जांचना चाहिए था कि क्या संदेश आईडी ( b483a22f-31cc-4335-9709-86041baa8f05 ) पहले ही उस कार्यकर्ता द्वारा ले लिया गया है।

हो सकता है कि सभी संदेश आईडी के साथ हैश सूची हो, ताकि सेलेरी यह तय कर सके कि प्राप्त कार्य प्रसंस्करण के लिए मान्य है या नहीं। क्या अजवाइन ऐसा कर सकती है?

नोट 2:
हम बहुत लंबे समय के लिए दृश्यता समयबाह्य सेट नहीं कर सकते, क्योंकि यदि कार्यकर्ता वास्तव में मर जाता है, तो संदेश को दूसरे कार्यकर्ता द्वारा उठाए जाने में बहुत अधिक समय लगेगा। इसे बहुत कम सेट करना इस स्थिति को उजागर करेगा।

chaws 18 फ़र॰ 2020

ऐसा लगता है कि मेरे साथ भी ऐसा हो रहा है।

[2020-05-11 15:31:23,673: सूचना/मुख्य प्रक्रिया] प्राप्त कार्य: ee_external_attributes.tasks। रीक्रिएट_स्पेसिफिक_वैल्यू[53046bd7-2a19-4f72-808f-d712eaecb0e8]
[2020-05-11 15:31:28,673: सूचना/मुख्य प्रक्रिया] प्राप्त कार्य: ee_external_attributes.tasks.recreate_specific_values[53046bd7-2a19-4f72-808f-d712eaecb0e8]

(मैंने सार्वजनिक पोस्टिंग के लिए लॉग में कार्य का नाम बदल दिया है।)

विशिष्टता बाधाओं के कारण, मेरा एक कार्यकर्ता कार्य के माध्यम से एक त्रुटि फेंकता है, और दूसरा सफल होता है।

मैंने सेटिंग करने की कोशिश की
CELERY_WORKER_PREFETCH_MULTIPLIER = 1
यह मदद नहीं करने के लिए निकला।

मैं उपयोग कर रहा हूं
अजवाइन == 4.4.1
django-अजवाइन-परिणाम == 1.2.1

और मैं कतार के लिए एडब्ल्यूएस SQS का उपयोग कर रहा हूँ।

JulieGoldberg 12 मई 2020

मेरे पास एक सिद्धांत है। जाहिरा तौर पर मेरी कतार पर मेरी "डिफ़ॉल्ट दृश्यता समयबाह्य" सेटिंग केवल 5 सेकंड के लिए निर्धारित की गई थी। यह हो सकता है कि दूसरे कर्मचारी ने उस समय काम किया जब पहला उस पर काम कर रहा था, क्योंकि यह मान लिया गया था कि पहले कार्यकर्ता की मृत्यु हो गई थी। मैंने दृश्यता टाइमआउट को 2 मिनट तक बढ़ा दिया है, और ऐसा लगता है कि यह बेहतर कर रहा है। मेरे पास बहुत सारे कार्य थे जिनमें 8-12 सेकंड लगते थे, इसलिए 2 मिनट अधिक हो सकते हैं। लेकिन उम्मीद है कि यह इसे हल करेगा।

JulieGoldberg 12 मई 2020

यह हो सकता है कि दूसरे कर्मचारी ने उस समय काम किया जब पहला उस पर काम कर रहा था, क्योंकि यह मान लिया गया था कि पहले कार्यकर्ता की मृत्यु हो गई थी।

@ जूलीगोल्डबर्ग , सेलेरी के लिए नौकरियों को संभालने का यह एक कठिन तरीका होगा। एक अजवाइन कार्यकर्ता को कभी भी ऐसा काम शुरू नहीं करना चाहिए जिसे दूसरे कार्यकर्ता ने कतार से हटा दिया हो और सक्रिय रूप से प्रसंस्करण कर रहा हो; सोचो कि गंभीर रूप से टूट जाएगा। (लेकिन यह अजवाइन है, मैं अब और कुछ नहीं से हैरान हूँ )

jenstroeger 12 मई 2020

👎5 😕1

मुझे कुबेरनेट्स में चल रहे एप्लिकेशन के साथ एक ही समस्या है। कुबेरनेट्स उदाहरण में, हमारे पास 10 कर्मचारी (अजवाइन ऐप इंस्टेंस) हैं जो रेडिस से कार्यों का उपभोग करते हैं।

लक्षण:
अजवाइन कार्यकर्ता एक ईटीए कार्य निर्धारित करता है जिसे 30 मिनट के बाद योजनाबद्ध किया जाएगा। यदि कुबेरनेट्स पॉड को घुमाया जाता है (कुबेरनेट्स द्वारा कार्यकर्ता को मार दिया जाता है) या एप्लिकेशन का एक नया संस्करण तैनात किया जाता है (सभी कार्यकर्ता मारे जाते हैं और नए कर्मचारी बनाए जाते हैं), तो सभी कार्यकर्ता निर्धारित कार्य करेंगे और निर्धारित समय में निष्पादित करना शुरू कर देंगे।
कार्यकर्ता के लिए, मैंने एक वर्ष तक के कई घंटों के लिए visibility_timeout के विभिन्न मान सेट करने का प्रयास किया, लेकिन परिणाम अभी भी वही था। सेटिंग enable_utc = True , या worker_prefetch_multiplier = 1 की कमी के साथ भी ऐसा ही व्यवहार किया गया था।

elMateso 17 जुल॰ 2020

मुझे नहीं पता कि यह किसी की मदद करेगा लेकिन यह मेरा मुद्दा था:

मेरे पास कार्य (रिपोर्ट पीढ़ी) थे जो जीईटी के माध्यम से एक पृष्ठ लोड होने पर चलाए जा रहे थे। किसी कारण से (फेविकॉन के साथ कुछ करने के लिए) क्रोम प्रत्येक पृष्ठ लोड पर 2 जीईटी अनुरोध भेजेगा, जिससे कार्य दो बार ट्रिगर होगा।
GET अनुरोधों को साइड इफेक्ट मुक्त माना जाता है, इसलिए मैंने उन सभी को आपके द्वारा सबमिट किए गए फ़ॉर्म में बदल दिया और समस्या हल हो गई।

adnathanail 18 जुल॰ 2020

👍1

यह हो सकता है कि दूसरे कर्मचारी ने उस समय काम किया जब पहला उस पर काम कर रहा था, क्योंकि यह मान लिया गया था कि पहले कार्यकर्ता की मृत्यु हो गई थी।
@ जूलीगोल्डबर्ग , सेलेरी के लिए नौकरियों को संभालने का यह एक कठिन तरीका होगा। एक अजवाइन कार्यकर्ता को कभी भी ऐसा काम शुरू नहीं करना चाहिए जिसे दूसरे कार्यकर्ता ने कतार से हटा दिया हो और सक्रिय रूप से प्रसंस्करण कर रहा हो; सोचो कि गंभीर रूप से टूट जाएगा। (लेकिन यह अजवाइन है, मैं अब और कुछ नहीं से हैरान हूँ )

शिकायत करने के बजाय, आप समाधान और पीआर लेकर समस्या को ठीक करने में हमारी मदद कर सकते हैं।

thedrow 27 जुल॰ 2020

👍2

मुझे कुबेरनेट्स में चल रहे एप्लिकेशन के साथ एक ही समस्या है। कुबेरनेट्स उदाहरण में, हमारे पास 10 कर्मचारी (अजवाइन ऐप इंस्टेंस) हैं जो रेडिस से कार्यों का उपभोग करते हैं।
लक्षण:
अजवाइन कार्यकर्ता एक ईटीए कार्य निर्धारित करता है जिसे 30 मिनट के बाद योजनाबद्ध किया जाएगा। यदि कुबेरनेट्स पॉड को घुमाया जाता है (कुबेरनेट्स द्वारा कार्यकर्ता को मार दिया जाता है) या एप्लिकेशन का एक नया संस्करण तैनात किया जाता है (सभी कार्यकर्ता मारे जाते हैं और नए कर्मचारी बनाए जाते हैं), तो सभी कार्यकर्ता निर्धारित कार्य करेंगे और निर्धारित समय में निष्पादित करना शुरू कर देंगे।

@elMateso मुझे k8s पर एयरफ्लो परिनियोजन के साथ समान मुद्दों का सामना करना पड़ा (पॉड्स पर उपभोक्ता और कतार के रूप में रेडिस)। लेकिन मैं तैनाती को स्थिर और अपेक्षित रूप से काम करने में सक्षम था, शायद वे टिप्स आपकी मदद करेंगे:
https://www.polidea.com/blog/application-scalability-kubernetes/#tips -for-hpa

turbaszek 27 जुल॰ 2020

👍1

यहां वही सामना करना पड़ रहा है।

कम से कम मेरे लिए किसी भी समय विन्यास (दृश्यता टाइमआउट, ईटीए, आदि ..) के साथ कोई समस्या नहीं लगती है। मेरे मामले में यह निष्पादन के बीच माइक्रोसेकंड होता है। पता नहीं कैसे अजवाइन वास्तव में एक संदेश एसीके करता है, लेकिन, अगर, खरगोश एमक्यू में यह पूरी तरह से काम कर रहा है तो यह रेडिस में समेकन और एसीके के साथ एक समस्या प्रतीत होता है।

jgbmattos 29 जुल॰ 2020

👍4

मैं एक ही मुद्दा देख रहा हूं और हम रेडिस को ब्रोकर के रूप में भी इस्तेमाल कर रहे हैं। RabbitMQ में बदलना हमारे लिए कोई विकल्प नहीं है।

क्या किसी ने यह सुनिश्चित करने के लिए लॉक का उपयोग करने का प्रयास किया है कि कार्य केवल एक बार ही निष्पादित किया जाता है। क्या यह काम कर सकता है?

उदाहरण के लिए https://docs.celeryproject.org/en/latest/tutorials/task-cookbook.html#ensuring -a-task-is-only-executed-one-at-a-time

ErikKalkoken 19 अग॰ 2020

@ErikKalkoken हम अंत में ठीक यही कर रहे हैं।

def semaphore(fn):
    @wraps(fn)
    def wrapper(self_origin, *args, **kwargs):
        cache_name = f"{UID}-{args[0].request.id}-semaphore"
        agreement_redis = AgreementsRedis()
        if not agreement_redis.redis.set(cache_name, "", ex=30, nx=True):
          Raise Exception("...")
        try:
            return fn(self_origin, *args, **kwargs)
        finally:
            agreement_redis.redis.delete(cache_name)

    return wrapper

उपरोक्त कोड अजवाइन के लिए उपयोग नहीं किया जाता है, लेकिन सेलेरी एकाधिक निष्पादन एक ही तर्क है, आपको केवल task_id प्राप्त करने और कैश सेट करने की आवश्यकता है। अब तक ठीक काम कर रहा है।

jgbmattos 19 अग॰ 2020

👍4

क्या कोई इस जनसंपर्क की जांच कर सकता है https://github.com/vinayinvicible/kombu/commit/a755ba14def558f2983b3ff3358086ba55521dcc

auvipy 14 अक्तू॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Celery: एक ही कार्य एक साथ कई बार चलता है?

सबसे उपयोगी टिप्पणी

सभी 43 टिप्पणियाँ

संबंधित मुद्दों