Celery: لا يقوم الدردشة الجماعية بتنظيف القنوات المشتركة في redis

أي خبر عن هذا؟ نحن أيضًا نواجه هذه المشكلة وهي تسبب لنا بعض الصداع ...

لقد كتبت تطبيق الوتر الخاص بي ولم أحاول إصلاح ذلك

gugu هل تمانع في مشاركة عملك؟ إذا كان متوفرًا في مستودع عام بالطبع.

MikaelWahlberg لقد قمت بإعادة إنتاج الخطأ باستخدام تجمع بريفورك. لقد وجدت بعض الحالات في التعليمات البرمجية المصدر حيث يجب على الواجهة الخلفية إلغاء الاشتراك من القنوات ولكن لم يتم حلها بالكامل بعد. قد يكون أحد الحلول المؤقتة للعامل هو تعيين --max-tasks-per-child إلى رقم منخفض نسبيًا (على سبيل المثال 5-10).

georgepsarakis نعم ، كان من الممكن أن يعمل ذلك كحل بديل ، ولكن يبدو أن مشكلتنا الرئيسية مع ضربات الكرفس ، وليس لدينا هذا الخيار ...

سعيد لإيجاد هذه المشكلة. بلدي redis-cli pubsub channels | grep celery-task-meta | wc -l حاليًا عند 48 ألفًا ، وهو ما وجدته غريبًا .. لا يسبب مشكلة بعد ، ولكن قد يحدث قريبًا ...

MikaelWahlberg ماذا تقصد بالضبط؟ beat يعمل بشكل منفصل عن العامل. من خلال بحثي حتى الآن ، فإن المشكلة ناتجة عن عمليات العمال ويشير خياري المقترح إلى ذلك. أود أن أقترح أن يستخدم أي شخص يواجه هذه المشكلة --max-tasks-per-child ، مما سيسمح بإغلاق الاتصالات التي يبدو أنها مشتركة.

georgepsarakis آسف ، فاتني هذا التعليق. ما أعنيه هو أن عدد قنوات الحانة في تزايد مستمر ، حتى لو وضعنا - الحد الأقصى من المهام - لكل طفل على العاملين "المستقبلين". وبمجرد أن نعيد تشغيل عملية ضرب الكرفس ، تنخفض مرة أخرى.

بالتأكيد ، كحل بديل ، يمكننا إعادة تشغيل دقات الكرفس كل يوم أيضًا ، فمن المحتمل أن يساعد ذلك كثيرًا.

georgepsarakis نعم ، سأقوم يوم الاثنين بإنشاء وحدة منفصلة لهذا الغرض

يبدو لي أنه لا يوجد سبب يدفع ضرب الكرفس إلى الإزعاج بالاشتراك في المقام الأول - فهو لا يتعامل مع النتائج ، بل يضع المهام في طوابير فقط.

يمكن أن يؤدي أحد الآثار الجانبية لهذه المشكلة إلى استخدام موارد خارجة عن السيطرة - في نقطة معينة ، تم إرسال رسائل اشتراك مكررة من عامل الإيقاع إلى مثيل Redis الخاص بنا ، وقد نمت هذه الرسائل بشكل كبير. أفترض أن هذا كان بسبب استغراق Redis وقتًا طويلاً جدًا (أو رفضه فقط) للإقرار بالاشتراك ، لذلك تظل معرفات المهام في قائمة انتظار معرفات المهام للاشتراك فيها ، لكنني لم أتعمق بما يكفي في النهاية الخلفية للنتيجة رمز لتأكيد هذا كسبب.

بغض النظر ، يمكن معالجة ذلك من خلال التأكد من أن عامل الإيقاع لا ينشئ اتصالًا بالنتيجة الخلفية على الإطلاق.

georgepsarakis هنا هو أول إصدار لي من
https://github.com/gugu/ezy-chord

(غدًا سوف أنقله إلى صفحة الويب الخاصة بشركتي: https://github.com/EzyInsights/ezy-chord)

أهلا. هل أنت متأكد من أن هذا السلوك مرتبط بالأوتار فقط؟ لدي إعداد اختبار بسيط مع مهمة بسيطة من البرنامج التعليمي الأساسي وقمت بالتجربة ، أن شيئًا ما مثل الكود أدناه المنفذ من قشرة الثعبان يفتح 100 قناة ، والتي يتم إغلاقها فقط بمجرد إنهاء عملية بيثون.

for i in xrange(1,100):
    tasks.add.apply_async((2,2))

rdrongow نعم ، هذا صحيح أيضًا. إذا لم تكن بحاجة إلى نتيجة مهمة ما ، فيمكنك تجربة @celery.task(ignore_result=True) ، وهذا يمكن أن يساعدك

أعتقد أنني قد وجدت الحل لهذه المشكلة ، وسأتابع بالتفاصيل بمجرد الانتهاء.

أقترح التراجع عن كيفية عمل الكرفس مع Redis إلى الإصدار 3 ، حيث تم كسر الفكرة الجديدة. عمل V3 بشكل جيد ، ولم تكن لدينا مشاكل

لدي أيضًا نفس المشكلة في سير عمل سلسلة الكرفس. بعد أيام قليلة ، فتحت الملايين من قنوات الحانات بالمهمة الأولى في السلسلة.

أنا جديد على الكرفس. فقط المهمة التالية في السلسلة تحتاج إلى نتيجة المهمة الأولى. لست بحاجة إلى استعادة النتيجة في كود python الذي يقوم بتشغيل سير عمل الكرفس هذا. هل يجب علي تعيين celery.task(ignore_result=True) في هذه الحالة؟

chuanma لا ، لن يساعدك. يمكنك محاكاة السلسلة عن طريق تشغيل المهمة التالية من نهاية المهمة السابقة

شكرا على الرد ، gugu

يتضمن سير العمل الخاص بي كلاً من celery.chain و celery.group . هذا لم تتم ترقيته إلى celery.chord ، أليس كذلك؟
task1.s() | celery.group(task2.s(), task3.s())

قمت بتشغيل strace مقابل عامل كرفس task1 واكتشفت أنه subscribe لقنوات كل من المهام النهائية: task2 و task3 في نهاية كل شوط. هذا أمر غريب لأن task1 هي المهمة الأولى ، ويجب ألا تعتمد على أي مهام تكميلية. يعرف أي شخص لماذا الإجراءات subscribe مطلوبة من task1 ؟

أيضًا لا تُرجع كلتا المهمتين المتلقين للمعلومات أي نتائج (لدي celery.task(ignore_result=True) لكلا المهمتين). لذا فإن مهام المصب لن تنشر أي بيانات لتلك القنوات الوهمية. هذا يعني أن task1 يشترك في قناة ما لا تحتوي على أي بيانات منشورة. هذا الخلل؟

تضمين التغريدة
يمكنك تشغيل Task1 ، في نهاية المهمة 1 يمكنك تشغيل task2.delay(); task3.delay() بنفس التأثير

شكرا! سيكون هذا هو الملاذ الأخير. في الوقت الحالي ، أفضل أن يكون لديك مهمة 1 قابلة لإعادة الاستخدام في سير عمل الكرفس الآخر.

thedrowauvipyAlexHill لمعلوماتك أنا لا تزال تعمل على حل هذه.

التغيير إلى v5 إذا لم يكن من الممكن إصلاحه قبل الإصدار 4.2

لقد قمت بإعداد بعض المهام لتكرار المشكلة ، ومن ما اختبرته حتى الآن ، لا يبدو أن المشكلة موجودة في البرنامج الرئيسي الحالي. أعتقد أنه تم إصلاحه بواسطة # 4131 ، لأنه الآن يتم استدعاء on_fulfilled ، والذي يقوم

chuanmagugu إذا كنت يمكن ان تحقق في مرحلة ما يرجى تقديم أي ردود فعل هنا. auvipythedrowAlexHill كنت اختبار التكامل من # 3815 للتحقق، افتتح # 4468 لهذا الغرض.

إغلاق كما تم إصلاحه في الوقت الحالي

أعتقد أن القضية لا تزال موجودة. نحن نستخدم الكرفس مع وسيط Redis + الخلفية لإثراء مستندات علم البيانات. الإعداد هو التالي:

• هناك تطبيق flask يتلقى مجموعة من المستندات ويستدعي مهمة كرفس ( enrich.apply_async() )
• يستدعي إثراء مهمة الكرفس chord(child_tasks, enrich_result_callback.s(client_id, meta)).delay() حيث تكون المهام الفرعية عبارة عن عمليات إثراء مختلفة يتم تنفيذها عن طريق استدعاء خدمات مصغرة خارجية.

بعد إجراء عدة آلاف من عمليات إثراء المستندات ، يمكننا ملاحظة تباطؤ عمال الكرفس. ينخفض ​​إنتاجية العمال بشكل كبير. كنت أحاول تجربة خيارات تكوين مختلفة من الكرفس مثل: -إعداد عادل ، زيادة تكوين multiply_prefetch إلى قيم أكبر + {'fanout_patterns': True} و {'fanout_prefix': True} . أيضًا ، حاولنا التحديث إلى أحدث إصدار من Celery 4.2rc2. لا شيء ، من هؤلاء ساعد.

من خلال تشغيل ما يلي ، يمكنني رؤية كيف يتزايد عدد القنوات باستمرار: redis-cli pubsub channels | grep celery-task-meta | wc -l حاليًا حوالي 65 ألفًا

فيما يلي تكوين الكرفس:

البرنامج -> الكرفس: 4.1.0 (latentcall) kombu: 4.1.0 py: 3.5.5
البلياردو: 3.5.0.3 redis: 2.10.6
النظام الأساسي -> النظام: Linux arch: 64bit ، ELF imp: CPython
محمل -> celery.loaders.app.AppLoader
الإعدادات -> النقل: نتائج redis : redis: //redis-xxx.xxx.ng.0001.euc1.cache.amazonaws. كوم: 6379/2
REDIS_ENRICHMENTS_KEY: *
worker_max_tasks_per_child: 100
result_expires: 3600
REDIS_CLIENT_IDS_KEY: *
Task_queues:
(الوالد. #، opbeat>،
طفل. #، opbeat>)
REDIS_RESULTS_TARGETS_KEY: ' * * '
REQUEST_TIMEOUT: 60
broker_transport_options: {
"visibility_timeout": 43200}
statsd_workers_prefix: "سرب العمال"
STATSD: {
'host': 'statsd.collectd'، 'port': 8125، 'prefix': 'swarm-api'}
broker_url: " redis: //redis-xxx.xxx.ng.0001.euc1.cache.amazonaws.com : 6379/1"
الواردات:
('swarm.workers.tasks'،)
result_backend: ' redis: //redis-xxx.xxx.ng.0001.euc1.cache.amazonaws.com : 6379/2'
task_default_queue: "افتراضي"
خطأ: خطأ
worker_prefetch_multiplier: 2

نحتاج إلى العثور على حالة اختبار تُعيد إظهار المشكلة.
عندما كتب georgepsarakis واحدة ، مرت دون أي تعديل في الكود. انظر # 4468.

mleginus على البعض أن يحفر بعمق

mleginus سيساعدك أيضًا إذا كان لديك مخطط مع عدد القنوات بمرور الوقت ، منذ بدء العامل.

مرحباgeorgepsarakisthedrow،

آسف لتأخر الرد. حاولت تبسيط الكود وتقديم مثال عن كيفية ظهور المشكلة. أنا أدير عاملين مثل هذا:

celery -A swarm.workers.tasks worker -Q default -P solo
celery -A swarm.workers.tasks worker -Q children -P solo

أقوم بتنفيذ وظيفة اختبار المهمة التي تتحقق من عدد قنوات Redis قبل تنفيذ الوتر وبعده. كنت أقوم بتشغيل هذا مقابل Redis المثبت محليًا:

أتساءل ما الذي يمكن أن يكون سبب مثل هذا السلوك عندما يكون المقتطف مشابهًا تمامًا لحالة الاختبار التي كتبها georgepsarakis

إليك مقتطف الشفرة الخاص بالمهام .py الموجود ضمن حزمة swarm.workers :

"""Celery tasks module."""
from celery import Celery
from celery import chord
from kombu import Queue
from redis import StrictRedis
from time import sleep


class CeleryConfig(object):
    # celery configurations
    broker_url = 'redis://localhost:6379/1'
    task_default_queue = 'default'
    task_queues = (
        Queue('default', routing_key='parent.#,opbeat'),
        Queue('children', routing_key='child.#,opbeat'),
    )
    imports = ('swarm.workers.tasks',)
    result_backend = 'redis://localhost:6379/2'
    worker_prefetch_multiplier = 2
    worker_max_tasks_per_child = 100


def create_app(config):
    """Create a celery app instance."""
    celery_app = Celery(__name__)
    celery_app.config_from_object(config)
    return celery_app


app = create_app(CeleryConfig)


@app.task
def add(x, y):
    """Add two numbers."""
    return x + y


@app.task
def delayed_sum(numbers, pause_time=1):
    """Sum the iterable of numbers."""
    # Allow the task to be in STARTED state for
    # a limited period of time.
    sleep(pause_time)
    return sum(numbers)


def run_test_task():
    """Run test task."""
    child_tasks = []
    child_tasks.append(
        add.signature(
            (1, 2),
            options={
                'queue': 'children',
                'routing_key': 'child.enrich',
            }
        )
    )

    child_tasks.append(
        add.signature(
            (3, 3),
            options={
                'queue': 'children',
                'routing_key': 'child.enrich',
            }
        )
    )

    redis = StrictRedis()
    channels_before = len(redis.execute_command('PUBSUB CHANNELS'))
    print('Redis channels count before chord execution {}'.format(channels_before))
    async_result = chord(child_tasks)(delayed_sum.s())
    print('The final sum is {}'.format(async_result.get()))
    channels_after = len(redis.execute_command('PUBSUB CHANNELS'))
    print('Redis channels count after chord execution {}'.format(channels_after))

كنت أحاول أيضًا تشغيل هذا ضد AWS Elasticache وهناك يمكنني رؤية نفس السلوك. يوجد أدناه الرسم البياني لكيفية زيادة عدد القنوات بمرور الوقت. يرجى تجاهل شكل الدرج للوظيفة. سبب "وظيفة السلم" هو أن المهام يتم تشغيلها كل 5 دقائق. ومع ذلك ، فإن عدد القنوات يعتمد كليًا على عدد المهام الوترية + الفرعية المنفذة.

georgepsarakis @ thedrow هل يمكنك إعادة الإنتاج باستخدام المقتطف الموجود على

mleginus يعرض مخرجاتك pip freeze إصدار Celery 4.1.0 الذي لا يحتوي على الإصلاحات. هل يمكنك التحقق مرة أخرى من أنك تستخدم أحدث إصدار مرشح للإصدار ، 4.2.0rc2 ؟

georgepsarakis شكرا للإشارة إلى هذا. اختفت المشكلة مع 4.2.0rc2 . اسمحوا لي أن أحاول غدًا عندما أكون في المكتب بالرمز الأصلي و Celery 4.2.0rc2 -> لترى أن قنوات الحانة يتم تنظيفها في AWS Elasticache. إذا كان هذا هو الحال ، آسف للارتباك!

لا داعى للقلق! فقط دعنا نعرف من فضلك بمجرد التحقق.

يمكنني إعادة إظهار المشكلة مع

 """Celery tasks module."""
from celery import chord
from celery import Celery
from kombu import Queue
from redis import StrictRedis
from time import sleep


class CeleryConfig(object):
    # celery configurations
    broker_url = 'redis://localhost:6379/1'
    task_default_queue = 'default'
    task_queues = (
        Queue('default', routing_key='parent.#,opbeat'),
        Queue('children', routing_key='child.#,opbeat'),
    )
    imports = ('swarm.workers.tasks',)
    result_backend = 'redis://localhost:6379/2'
    worker_prefetch_multiplier = 2
    worker_max_tasks_per_child = 100


def create_app(config):
    """Create a celery app instance."""
    celery_app = Celery(__name__)
    celery_app.config_from_object(config)
    return celery_app


app = create_app(CeleryConfig)


@app.task
def enrich():
    """Main enrichment task."""
    child_tasks = []
    for _ in range(1, 10):
        child_tasks.append(
            enrich_single_call.signature(
                kwargs={
                    'data': 'data',
                },
                options={
                    'queue': 'children',
                    'routing_key': 'child.enrich',
                }
            )
        )
    chord(child_tasks)(enrich_result_callback.s())


@app.task
def enrich_single_call(data):
    """Single call to a single enrichment service."""
    result = {
        'data': data.upper() # faking invocation of enrichment service :) :)
    }
    return result


@app.task
def enrich_result_callback(results_list):
    """Enrichment results publisher."""
    results = {}
    for result in results_list:
        results['enrichment'] = result
    return results


def run_test_task():
    """Run test task."""
    redis = StrictRedis()
    channels_before = len(redis.execute_command('PUBSUB CHANNELS'))
    print('Redis channels count before chord execution {}'.format(channels_before))
    enrich.delay()
    sleep(5)
    channels_after = len(redis.execute_command('PUBSUB CHANNELS'))
    print('Redis channels count after chord execution {}'.format(channels_after))

تشغيل عمال الكرفس مثل هذا:

celery -A swarm.workers.tasks worker -Q children -P solo
celery -A swarm.workers.tasks worker -Q default -P solo

ثم يؤدي تشغيل run_test_task من ipython إلى إنتاج مثل هذا:

georgepsarakis ، هل يمكنك إعادة الإنتاج باستخدام المقتطف المحدث؟

mleginus هذا هو بالضبط سبب
هل ستكون قادرًا على المساهمة في حالة الاختبار هذه في مجموعة اختبارات التكامل الخاصة بنا؟

thedrow أود المساعدة في اختبار التكامل ولكن قد لا أتمكن من القيام بذلك حتى منتصف شهر مايو (سأختتم هذا الأسبوع في المكتب ثم أسافر لبعض الوقت).

mleginusthedrow فتحت # 4666 قد حل هذه المشكلة. يرجى اختبار هذا قبل النشر في الإنتاج ، فقد يكون له عواقب غير معروفة.

mleginus هل ربما لديك الوقت لاختبار الفرع على PR # 4666؟ ملاحظاتك ستكون ذات قيمة

mleginusgeorgepsarakisthedrow أي تحديث على ذلك؟ لا يزال يحظر 4.2 ...

johnarnold @ نود بعض التعليقات حول الحل الممكن. من المحتمل أن يتم دمج # 4666 في النظام الرئيسي قريبًا.

لقد أعدت تشغيل نموذج رمز

تجميد pip3 الخاص بي هو:
تجميد pip3 | الكرفس grep
الكرفس == 4.2.0rc3

مخرجات نصه هي:

تحسب قنوات Redis قبل تنفيذ الوتر 0
يتم احتساب قنوات Redis بعد تنفيذ الوتر 10
يتم احتساب قنوات Redis قبل تنفيذ الوتر 10
عدد قنوات Redis بعد تنفيذ الوتر 20
تحسب قنوات Redis قبل تنفيذ الوتر 20
عدد قنوات Redis بعد تنفيذ الوتر 30

بعد عدة دقائق من تشغيل البرنامج النصي ، لا يزال تشغيل "قنوات redis-cli pubsub" يُظهر عناصر الكرفس-مهمة- meta-xxx على أنها لا تزال مُشتركة.

لقد جربت هذا على جهازين ، أحدهما Ubuntu 16 والآخر Mac OS X. Redis 4.0.7.

لقد أكدت أن المهام ناجحة بالفعل: AsyncResult (task_id.id) .status == "SUCCESS".

لذلك ، أعتقد أن المشكلة لا تزال هي أن عميل pubsub لا يتلقى رسالة task_succeed من العمل. اليوم هو أول يوم لي في دراسة كود الكرفس ، لذا لا ينبغي الوثوق بمعتقداتي.

لقد وجدت حلاً في الوقت الحالي ، وهو ليس لطيفًا جدًا: بالنسبة للمهام التي ليس لها قيمة مردودة ، أتصل بها
task_id.backend.result_consumer.cancel_for (task_id.task_id) باستخدام معرف المهمة الذي تم إرجاعه من .delay ().

اسمحوا لي أن أعرف إذا كان بإمكاني تقديم أي معلومات أخرى.

@ bartloop شكرا على ردود الفعل. أظن أنك تشير إلى هذا النص ، أليس كذلك؟

تحتاج إلى الاتصال بـ AsyncResult.get() حتى يقوم المتصل بإلغاء الاشتراك من المحادثة الجماعية. مع الرمز كما هو الآن ، ستبقى القنوات نشطة ، طالما أن عملية ipython تظل نشطة.

جرب تشغيل هذا للاختبار:

def run_test_task():
    """Run test task."""
    redis = StrictRedis()
    channels_before = len(redis.execute_command('PUBSUB CHANNELS'))
    print('Redis channels count before chord execution {}'.format(channels_before))
    result = enrich.delay()
    sleep(5)
    channels_after = len(redis.execute_command('PUBSUB CHANNELS'))
    print('Redis channels count after chord execution {}'.format(channels_after))
    result.get()
    channels_after = len(redis.execute_command('PUBSUB CHANNELS'))
    print('Redis channels count after result retrieval {}'.format(channels_after))

georgepsarakis أشكرك على الوقت الذي

قلل الكود الذي قمت بتعديله العدد بمقدار 1 وليس 10:
تحسب قنوات Redis قبل تنفيذ الوتر 0
يتم احتساب قنوات Redis بعد تنفيذ الوتر 10
عدد قنوات Redis بعد استرجاع النتيجة 9
يتم احتساب قنوات Redis قبل تنفيذ الوتر 9
قنوات Redis تحسب بعد تنفيذ الوتر 19
عدد قنوات Redis بعد استرجاع النتائج 18

لكن مشكلتنا لا تتعلق حقًا بالآلات الموسيقية - فنحن نكافح من أجل القيام بالتأجيل () في مهام فردية بدون قيمة مردودة.

إذن ، هذا سؤالي المبتدئ: بالنسبة للمهام التي ليس لها نتيجة ، كيف أفعل ما يعادل .get () ولكن بطريقة غير محظورة؟ تُظهر وثائق AsyncResult وظيفة forget () ، والتي يبدو أنها ما أريده ، لكن ليس لها أي تأثير على عدد الاشتراكات. حاولت أيضًا إضافة ignore_result = صحيح لمصممي المهام ، لكن لم يكن لذلك أي تأثير. أفترض أن هناك طريقة ما للقيام بذلك.

شكرا!

bartloop تبدو هذه مشكلة مختلفة ولكنها ذات صلة.
يرجى فتح واحدة جديدة مع حالة الاختبار ذات الصلة.
إذا كنت ترغب في ذلك ، شارك في اختبار التكامل وحدده كـ xfail.

georgepsarakis ، آمل ألا تمانع في إغلاق هذا مرة أخرى.
أفضل الحفاظ على قائمة المشكلات نظيفة ويجب حل هذه المشكلة.
إذا كان هناك انحدار دقيق لهذه المشكلة ، فلنعد فتحه. إذا لم يكن الأمر كذلك ، فيرجى تشجيع مستخدمينا على فتح المشكلات في حالات الاختبار ذات الصلة.

thedrow لا على الإطلاق ، لقد

georgepsarakis و thedrow يمكنني إعادة إنتاج السلوك الذي أبلغ عنه bartloop -
https://github.com/celery/celery/issues/3812#issuecomment -386639135 أود معرفة ما إذا كنت سأتمكن من كتابة حالة اختبار تكامل يمكنها إعادة إنتاج مثل هذا السلوك. لهذا ، أحتاج إلى عاملين من الكرفس يعملان داخل الاختبار - أحدهما يستمع في قائمة انتظار children والآخر في قائمة انتظار default . هل يمكنك تقديم النصيحة حول كيفية إنشاء تركيبات عامل ثانية (بالإضافة إلى celery_session_worker https://github.com/celery/celery/blob/master/t/integration/conftest.py#L65) وتمريرها الإعدادات المناسبة للاستماع إلى قائمة انتظار محددة؟ شكرا مقدما.

mleginus ، هل يمكنك من فضلك فتح عدد جديد حتى نتمكن من تحليل هذا بشكل أكبر؟ شكرا!

خطأ ... هل أنا فقط أم يجب إعادة فتح هذه المشكلة؟ لقد جربت للتو كود gugu على تثبيت حديث 4.4.0 وما زلت أعاني من نفس الأعراض - لا تزال اشتراكات المهام الفرعية لرأس الوتر لم يتم مسحها.

ملحوظة: ما زلت أتصفح التذاكر (العديدة) ذات الصلة وما إلى ذلك ، لذا ربما أغفلت شيئًا ما - إذا كانت الإجابة بنعم ، يرجى تنوير ؛-)

الكرفس - تقرير التطبيق:

software -> celery:4.4.0 (cliffs) kombu:4.6.7 py:2.7.17
            billiard:3.6.1.0 py-amqp:2.5.2
platform -> system:Linux arch:64bit
            kernel version:5.3.0-26-generic imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:pyamqp results:redis://localhost/

worker_max_tasks_per_child: 10
result_extended: True
worker_prefetch_multiplier: 1
worker_send_sent_event: True
result_expires: 86400
worker_disable_rate_limits: True
worker_send_task_events: True
timezone: u'Europe/Paris'
track_started: True
broker_url: u'amqp://guest:********<strong i="8">@localhost</strong>:5672//'
result_backend: u'redis://localhost/'
worker_pool_restarts: True