<p>خطأ في رفع الكرفس: [Errno 104] تمت إعادة تعيين الاتصال بواسطة النظير بعد البدء</p>

أرى نفس المشكلة مع الكرفس 4.2.0. ليس لدي مع الكرفس 4.1.1. محليًا ، غالبًا ، ولكن ليس دائمًا ، أحصل على Errno 104. في بناء travis ، يبدو أنه يفشل بشكل أكثر ثباتًا عند 4.2.0 (وينجح في 4.1.1). لم ألاحظ تبعية الوقت التي يبلغ عنهاaxiaoxin .

هل يمكنك تقديم إخراج الأمر التالي من فضلك:

$ celery -A proj report

مرحبا georgepsarakis هذا تقريري

software -> celery:4.2.0 (windowlicker) kombu:4.2.1 py:2.7.5
            billiard:3.5.0.3 py-amqp:2.3.2
platform -> system:Linux arch:64bit, ELF imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:amqp
results:sentinel://:**@10.18.7.1:26379/1;sentinel://:[email protected]:26379/1;sentinel://:[email protected]:26379/1

JSON_AS_ASCII: False
CACHED_OVER_EXEC_MILLISECONDS: 800
LOG_PEEWEE_SQL: False
SESSION_REFRESH_EACH_REQUEST: True
APP_ROOT_PATH: '/data/srv/zns/app'
REDIS_URL: 'redis://:[email protected]:6379/2'
PROJECT_ROOT_PATH: '/data/srv/zns'
FLATPAGES_ROOT: '/data/srv/zns/app/docs'
SESSION_COOKIE_SAMESITE: None
PROPAGATE_EXCEPTIONS: None
CELERYD_SEND_EVENTS: True
REDIS_LOCK_TIMEOUT: 1800
FAKE_HANDLE_TASK: False
SECRET_KEY: u'********'
BROKER_URL: u'amqp://notifer:********@zns.com:5672/notifer_celery_broker'
ENTRY_RATE_LIMIT: 0
SENTRY_DSN: 'http://6a0ce3f93804422da7321f45353c69d7:[email protected]/10'
SWAGGER: {
    'description': '<a href="/docs" target="_blank">\xe5\x85\xb6\xe4\xbb\x96\xe6\x96\x87\xe6\xa1\xa3</a>',
    'doc_expansion': 'list',
    'footer_text': u'\u6709\u4efb\u4f55\u7591\u95ee\u8bf7\u54a8\u8be2 ashinchen',
    'hide_top_bar': True,
    'specs': [{   'endpoint': 'apispec', 'route': '/apispec.json'}],
    'termsOfService': None,
    'title': 'zns API',
    'uiversion': 3,
    'version': '0.0.1'}
LOG_LEVEL: 'info'
APPLICATION_ROOT: '/'
SERVER_NAME: None
LOG_PATH: '/data/srv/zns/logs'
SERVICE_NAME: 'zns'
CELERYD_MAX_TASKS_PER_CHILD: 10000
TESTING: False
MYSQL_URL: 'mysql+pool://user:[email protected]:3306/zns?max_connections=40&stale_timeout=300'
TEMPLATES_AUTO_RELOAD: None
CELERY_RESULT_PERSISTENT: True
JSONIFY_MIMETYPE: 'application/json'
TOF_APP_KEY: u'********'
TOF_SYS_ID: 1
JSON_KEYCASE: u'********'
TOF_URL: 'http://tof.com/api/v1'
FLATPAGES_EXTENSION: ['.md', '.html', '.htm', '.txt']
SESSION_COOKIE_HTTPONLY: True
USE_X_SENDFILE: False
REQUESTS_POOL_SIZE: 10
API_BIND: u'********'
SESSION_COOKIE_SECURE: False
CACHED_EXPIRE_SECONDS: 60
REDIS_SENTINEL: {
    'db': 0,
    'master_name': 'redis-master',
    'nodes': [   ('10.18.7.1', 26379),
                 ('10.16.19.22', 26379),
                 ('10.16.19.21', 26379)],
    'password': u'********'}
SESSION_COOKIE_DOMAIN: None
SESSION_COOKIE_NAME: 'session'
EXCEPTION_RETRY_COUNT: 2
CELERY_TASK_RESULT_EXPIRES: 604800
MAX_COOKIE_SIZE: 4093
ENTRY_RATE_PER: 0
TOF_WEIXIN_SENDER: 'x-ashin'
ENV: 'production'
CELERYD_TASK_SOFT_TIME_LIMIT: 30
DEBUG: False
PREFERRED_URL_SCHEME: 'http'
EXPLAIN_TEMPLATE_LOADING: False
CELERY_RESULT_BACKEND:u'sentinel://:********@10.18.7.1:26379/1;sentinel://:pwd@'10.16.19.22:26379/1;sentinel://:[email protected]:26379/1'
CACHED_CALL: False
FLATPAGES_AUTO_RELOAD: False
MAX_CONTENT_LENGTH: None
REQUEST_ID_KEY: u'********'
NOTIFY_MODULE: 'tof'
JSONIFY_PRETTYPRINT_REGULAR: False
LOG_FUNC_CALL: True
PERMANENT_SESSION_LIFETIME: datetime.timedelta(31)
TOF_EMAIL_SENDER: '[email protected]'
REDIS_CLUSTER: {
    }
TRAP_BAD_REQUEST_ERRORS: None
JSON_SORT_KEYS: u'********'
TRAP_HTTP_EXCEPTIONS: False
SESSION_COOKIE_PATH: None
SEND_FILE_MAX_AGE_DEFAULT: datetime.timedelta(0, 43200)
SPLIT_LOGFILE_BY_LEVEL: False
PRESERVE_CONTEXT_ON_EXCEPTION: None
CELERY_RESULT_BACKEND_TRANSPORT_OPTIONS: {
    'master_name': 'redis-master'}
LOG_IN_FILE: False

وفقًا لهذا التقرير ، لا يتم استبدال بعض جرعة كلمة المرور بـ *

لما يستحق ، أرى هذا أيضًا مع مشروع نظيف باستخدام gevent with rabbitmq. بعد بدء تشغيل عمال الكرفس لبضع دقائق ، سنتلقى إعادة تعيين الاتصال ولن يتم استهلاك أي مهام بعد ذلك.

https://github.com/sihrc/celery-connection-reset

لا تزال لديك نفس المشكلة حتى الآن (الكرفس 4.2) تم حلها عن طريق تخفيض إصدار الكرفس إلى 4.1 ، لكن لا تعرف سبب حدوث هذا الخطأ.

هل يمكنك محاولة تثبيت الكرفس من الفرع الرئيسي بكل تبعياته من السيد ومعرفة ما يحدث؟

لا يزال يظهر هذا الخطأ مع Celery 4.2.2.

auvipy شكرا ، إنه يعمل!

@ yuda110 هل تعرف ما هي التغييرات التي طرأت على

نحصل على مشكلة ConnectionReset هذه ، ونستخدم Celery 4.2.1 مع الإصدارات التالية المثبتة والمتوافقة مع متطلبات الكرفس:

billiard==3.5.0.4 # Celery needs billiard. There's a bug in 3.5.0.5
kombu==4.2.2-post1 # Celery needs kombu >= 4.2.0, < 5.0
redis==2.10.6

تضمين التغريدة
أوه ، لقد نسيت محو هذه الإجابة يبدو أن المشكلة قد تم حلها بعد ترقية الإصدار (إلى 4.2.1) ، ولكن واجهت مشكلة غير معروفة مرة أخرى. في النهاية اضطررت إلى الرجوع إلى الإصدار 4.0.

لقد خفضت التصنيف إلى 4.1 وقد أصلحت الخطأ. لم تجرب 4.3 حتى الآن رغم ذلك.

نادرًا ما يحدث هذا الخطأ بالنسبة لنا ، وقد اتضح أنه استثناء متسلسل يبدأ بخطأ ConnectionReset من عميل redis. سأقوم فقط بتمكين عمليات إعادة المحاولة عند إلقاء kombu.exceptions.OperationalError ، لأن Celery ChangeLog يشير إلى أن هذا خطأ يمكن إعادة المحاولة.

أردت فقط أن أقول إن المشكلة لا تزال قائمة في 4.3.0 عند استخدام RabbitMQ. بطريقة ما الانتقال إلى Redis حل المشكلة.

لقد حللنا هذا عن طريق إجراء عمليات إعادة المحاولات مع تراجع أسي كلما تم طرح kombu.exceptions.OperationalError . من المفترض أن تتم إعادة محاكمتهم ، وفقًا للمستندات. نادرًا ما تحدث هذه المشكلة بالنسبة إلينا ، لذا تعد عمليات إعادة المحاولة حلاً جيدًا. نحن على 4.2.1.

أهلا،

أنا أستخدم rabbitmq كوسيط وخلفية ولدي نفس المشكلة.

أي شخص لديه حل؟

شكرا مقدما.

نفس المشكلة هنا. هذا 100٪ قابل للتكرار بالنسبة لي. لسبب ما ، يموت المقبس الخاص بالسمسار بعد ما يبدو أنه فترة ضربات القلب.

أبلغ عن:

software -> celery:4.3.0 (rhubarb) kombu:4.5.0 py:3.6.7
            billiard:3.6.0.0 py-amqp:2.4.2
platform -> system:Linux arch:64bit, ELF
            kernel version:4.18.0-20-generic imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:amqp results:rpc:///

broker_url: 'amqp://guest:********<strong i="7">@localhost</strong>:5672//'
result_backend: 'rpc:///'
result_persistent: False
task_default_queue: 'something something'
result_expires: 3600
task_ignore_result: False
task_serializer: 'json'
result_serializer: 'json'
accept_content: ['json']
timezone: 'Europe/Berlin'
enable_utc: True

يجب أن أقول إن مشاكلي بدأت عندما قمت بالترقية إلى Erlang 22.0. لكن هذا قد يكون سريًا أيضًا.

هل يمكنك اقتراح أي حل؟ إذا استطعت ، فسيتم تضمين ذلك في 4.4.0rc2

يمكنني تأكيد هذا السلوك على 4.3.0 مع gevent worker أيضًا. يبدو أن التحول من gevent إلى prefork يحلها. لقد حاولت الرجوع إلى الإصدار 4.1.1 ولكن يبدو أن هذا لا يعمل على Python 3.7 لأنه يتطلب إصدارًا أقدم من gevent (1.2.2) والذي لن يتم تجميعه حتى على Python 3.7. لقد لاحظت عند بدء المشكلة ، تعرض سجلات rabbitmq هذه الرسالة:

missed heartbeats from client, timeout: 60s

ومن المثير للاهتمام ، أنه على الرغم من فشل نبضات القلب ، لا يزال العامل يتولى المهام ويعالجها بشكل جيد. إنها مجرد أوامر celery inspect طوال الوقت حتى يتم إعادة تشغيل العامل. لا يزال flower يعرض معلومات على لوحة معلومات العامل ، ولكن النقر فوق العامل نفسه يؤدي إلى ظهور خطأ 404 Not Found ، وإخفاقات سجلات الزهور المتعلقة بأوامر فحص الكرفس:

monitor_1    | 2019-08-27 17:39:05.483286 [warning  ] 404 GET /worker/celery<strong i="11">@38245f8fef62</strong> (172.20.0.1): Unknown worker 'celery<strong i="12">@38245f8fef62</strong>' [tornado.general] 
monitor_1    | 2019-08-27 17:39:24.608962 [warning  ] 'stats' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.609429 [warning  ] 'active_queues' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.609847 [warning  ] 'registered' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.610221 [warning  ] 'scheduled' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.610905 [warning  ] 'active' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.611369 [warning  ] 'reserved' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.611890 [warning  ] 'revoked' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.612512 [warning  ] 'conf' inspect method failed [flower.api.control] 

بحاجة إلى شخص للتحقق من هذا على الكرفس 4.4.0rc3 + kombu 4.6.3؟

سوف تفعل. لمعلوماتك ، يتطلب الكرفس 4.4.0rc3 kombu 4.6.4:

celery 4.4.0rc3 has requirement kombu<5.0,>=4.6.4, but you'll have kombu 4.6.3 which is incompatible.

حسنًا ، يبدو أن 4.4.0rc3 لحل هذه المشكلة. لقد تركتها تعمل لأكثر من 5 دقائق دون أي أخطاء في ضربات القلب باستخدام العامل الجاد.

kombu 4.6.3 متوافق أيضًا

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

لكن ماذا غيرنا؟

أود أيضًا الحصول على نظرة ثاقبة حول ما تم تغييره والذي تسبب في إغلاق هذا ، أو رابط إلى PR / code / إلخ. نحن نتأثر ، ونخفف من حدته (بريفورك ، رابيتمق ، كرفس 4.3) عن طريق تعطيل ضربات القلب التي هي دون المستوى الأمثل.

auvipy بينغ؟

حسنًا ، يبدو أن 4.4.0rc3 لحل هذه المشكلة. لقد تركتها تعمل لأكثر من 5 دقائق دون أي أخطاء في ضربات القلب باستخدام العامل الجاد.

تم إغلاق المشكلة بناءً على هذه التعليقات

auvipy يبدو أن هناك العديد من المشكلات التي تؤدي إلى أخطاء مماثلة. سيكون من الرائع أن تحاول إعادة إنتاج الخطأ محليًا ، ربما باستخدام بعض إصدارات الكرفس القديمة ، قبل حل المشكلة.

يُقترح عليك تجربة الفرع الرئيسي.

أقترح إعادة إنتاج الخطأ بأحد الإصدارات السابقة (مثل 4.1 و 4.2 و 4.3) والتأكد من أن الترقية إلى 4.4 وحدها تعمل على إصلاح المشكلة. يبدو إغلاق الخطأ دون التحقق الخاص بك - بناءً على تعليقات شخص واحد - متسرعًا بعض الشيء.

نظرًا لأنك تواجه المشكلة ، يجب أن تكون أول من يقوم بالتحقق كما اقترحت. تضمين التغريدة

يجب أن تكون أول من يقوم بالتحقق كما اقترحت

_ "should"؟ _؛) إذا كان هناك أي شخص _يجب_ أن يهتم بجودة المشروع ، فهو المسؤول عن الصيانة الرسميين. أنا ممتن لأنك تقدم برنامجك مجانًا ، لكن لا يمكنك أن تتوقع واقعياً أن يساهم جميع المستخدمين في المشروع.

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

يبدو أيضًا أن 4.4.0rc4 يحل هذه المشكلة ،

أي شخص آخر يمكنه التحقق من أنه تم إصلاحه عن طريق الكرفس == 4.4.0rc4

auvipy كنت في 4.3.0 مع عرضي Connection reset . لا مزيد من المشاكل مع 4.4.0rc4 بالنسبة لي.

أي شخص آخر يمكنه التحقق من أنه تم إصلاحه عن طريق الكرفس == 4.4.0rc4

لقد حصلت على المشكلة في 4.3.0 في كثير من الأحيان - مع 4.4.0rc4 تحدث المشكلة بشكل أقل كثيرًا - ولكن تحدث اللقطات من وقت لآخر.
أنا أستخدم خادم redis 5.0.6 و python redis Client 3.3.11 مع 14 مهمة دورية تقريبًا (كل 30 ثانية).
لذا أطلب منك إعادة فتح القضية.
شكرا!

لقد حصلت على المشكلة في 4.3.0 في كثير من الأحيان - مع 4.4.0rc4 تحدث المشكلة بشكل أقل كثيرًا - ولكن تحدث اللقطات من وقت لآخر.
أنا أستخدم خادم redis 5.0.6 و python redis Client 3.3.11 مع 14 مهمة دورية تقريبًا (كل 30 ثانية).
لذا أطلب منك إعادة فتح القضية.
شكرا

في الواقع ، لا تزال المشكلة تحدث مع الإعدادات الافتراضية. ومع ذلك ، كما هو مذكور في سلاسل المحادثات الأخرى ، يبدو أن تعيين broker_heartbeat = 0 في celeryconfig.py يساعد.

حتى بعد الترقية إلى الكرفس 4.4.0rc4 وإضافة CELERY_BROKER_HEARTBEAT = 0 في الكرفس ، لا يبدو أن شيئًا يتغير كثيرًا بالنسبة لي ، وما زلت أتلقى الخطأ.

لم يتم حل المشكلة بعد خفض التصنيف من 4.2.0 إلى 4.10

الإصدارات التالية هي usinf في مشروعنا:
بلياردو == 3.5.0.2 ، كومبو == 4.1.0 ، كرفس = 4.1.0 ، amqp == 2.4.2

الرجاء الاقتراح

بدأنا في رؤية هذا ، أو شيء يشبه إلى حد كبير هذه المشكلة.

البرنامج -> الكرفس: 4.3.0 (راوند) كومبو: 4.5.0 py: 2.7.12
بلياردو: 3.6.0.0 redis: 3.2.1

بدأ يحدث عدة مرات في اليوم ، دون أي تغييرات حقيقية.
بالنسبة لإصدارنا التالي ، سنحاول الترقية إلى أحدث الإصدارات ، وهي الكرفس 4.4.0 و redis وما إلى ذلك ، والإبلاغ مرة أخرى.

يحدث لي مع (التزامن = 1000 (gevent) و redis كوسيط):
الكرفس = = 4.4.0 (المنحدرات)
كومبو == 4.6.7
البلياردو == 3.6.2.0
(py-) redis == 3.4.1

إصدار خادم Redis = 5.0.7
بايثون 3.7.3

https://sentry.io/share/issue/85f87e60a7c441198c082b9ebf051693/

• يتم تعيين 7 مهام للتشغيل كل 10 ثوانٍ.
• يحدث الخطأ فقط في خفق الكرفس ، ونادرًا ما يحدث خطأ في أقل من 3 حالات كل ساعة.

العلامات

• المسجل: الكرفس
• وقت التشغيل: CPython 3.7.5

بيئة

• Linux-4.15.0-1060-aws-x86_64-with-Ubuntu-18.04-bionic
• Python 3.7.5 (افتراضي ، 7 نوفمبر 2019 ، 10:50:52) [GCC 8.3.0]
• خادم Redis v = 4.0.9 sha = 00000000: 0 malloc = jemalloc-3.6.0 بت = 64 بناء = 9435c3c2879311f3
• الكرفس == 4.4.0
• البلياردو == 3.6.1.0
• كومبو == 4.6.7
• redis == 3.3.11

يحدث هذا لي عندما أقوم بالاتصال بخادم TCP باستخدام اتصال open_connection الخاص بـ asyncio. بعد 15 دقيقة من الاتصال بالخادم البعيد داخل vpn الخاص بنا ، يقوم بفصل الاتصال بي. أظن أن هذا لأن الاتصال خامل. لا يحدث نفس الشيء عندما أقوم بالاتصال من داخل الخادم البعيد. يبدو أن هذا متعلق بالشبكة.

لقد حللت قضيتي! يوف.

لم تكن مشكلة الكرفس. لقد جربت إصدارات قليلة منه ، بما في ذلك 4. [234] .0 ، وقد جربت عددًا قليلاً من إصدارات واجهات Python على redis. ولدي دائمًا نسبة فشل أقل (حوالي 2 about مقابل 0.5 مليون طلب)

كان الحل في إعادة تكوين خادم redis ، أي تعطيل حد المخزن المؤقت للعميل لجميع الفئات. وفقًا لوثائق redis :

يتم قطع اتصال العميل على الفور بمجرد الوصول إلى الحد الثابت ، أو إذا تم الوصول إلى الحد المرن ويظل الوصول إليه لعدد الثواني المحدد (بشكل مستمر).
...
يمكن تعطيل كل من الحد الثابت أو الناعم عن طريق تعيينهما على صفر.

آمل أن يساعدك ذلك جميعًا أيضًا. أو ربما تقوم بتحسين الحل الخاص بي.

لقد حللت قضيتي! يوف.

لم تكن مشكلة الكرفس. لقد جربت إصدارات قليلة منه ، بما في ذلك 4. [234] .0 ، وقد جربت عددًا قليلاً من إصدارات واجهات Python على redis. ولدي دائمًا نسبة فشل أقل (حوالي 2 about مقابل 0.5 مليون طلب)

كان الحل في إعادة تكوين خادم redis ، أي تعطيل حد المخزن المؤقت للعميل لجميع الفئات. وفقًا لوثائق redis :

يتم قطع اتصال العميل على الفور بمجرد الوصول إلى الحد الثابت ، أو إذا تم الوصول إلى الحد المرن ويظل الوصول إليه لعدد الثواني المحدد (بشكل مستمر).
...
يمكن تعطيل كل من الحد الثابت أو الناعم عن طريق تعيينهما على صفر.

آمل أن يساعدك ذلك جميعًا أيضًا. أو ربما تقوم بتحسين الحل الخاص بي.

لقد نجح هذا أيضًا بالنسبة لي ، حيث لم تنجح أي من الاقتراحات الأخرى. شكرا لك!

يمكنني أيضًا أن أؤكد أنه حل مشكلة الإعداد الخاص بي! شكرا لتخصيص الوقت لهذاrganowski!

رائع إذا أدى هذا إلى حل المشكلة ، ولكن قبل أن أبدأ في إزالة الإعدادات الافتراضية من ملف التكوين ، أشعر أنه سيكون من الرائع معرفة ما يفعله هذا الإعداد ، ولماذا هو جزء من التكوين الافتراضي؟

Moulde لست متأكدًا تمامًا مما

أود أيضًا أن أعرف سبب وجود مثل هذه الافتراضات؟ هل كان ذلك واعيا؟ إذا كان الأمر كذلك ، فما هو خطر التخلي عنها؟ لكن بصراحة لن أتحقق من ذلك. كان لدي مهمة 10MD ، كان علي إضافة 3MD مجانًا.

لم يقل أحد أن هذا يصلح المشكلة. قلت ، لقد وجدت حلاً لقضيتي. قال اثنان آخران من رفاقه إنه يعمل معهم أيضًا. قرأت ذلك بسرور. لكن كلماتك قرأتها بهذه الطريقة: "أثبتها". هل انا مخطئ

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

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

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

عند البحث في Google عن "حد التخزين المؤقت للعميل" ، يمكننا العثور على العديد من المقالات الشيقة. واحد ، الآن يبلغ من العمر 6 سنوات ، لديه - في النتائج - عنوان جميل حقًا The Replication Buffer - How to Avoid Devops Headache . هناك يمكننا أن نقرأ:

قبل زيادة حجم المخازن المؤقتة للنسخ المتماثل ، يجب التأكد من وجود ذاكرة كافية على جهازك.

في بعض المقالات الأخرى ، مخازن العميل - قبل استخدام Redis في الإنتاج ، تحقق من هذا! يقول المؤلف:

بشكل افتراضي ، لا يتم تقييد العملاء العاديين (أوامر التنفيذ العادية) لأنهم لا يتلقون البيانات دون طلب (بطريقة الدفع) ، ولكن بعد الطلب مباشرة ، لذلك يمكن للعملاء غير المتزامنين فقط إنشاء سيناريو يتم فيه طلب البيانات بشكل أسرع مما يمكن اقرأ.

أليس هذا هو حالتنا؟

بالنسبة لي ، على الأقل حتى الآن ، تبين أن إعادة التكوين هي الخلاص. لا توجد أخطاء "104" جديدة ، مع حمل ثقيل وفوري حقًا.

rganowskiMoulde @ CM2Walki

مرحبًا ، قد أبدو ساذجًا جدًا ولكن هل يمكنك أن تخبرني من فضلك أين يمكنني إجراء التعديل اللازم لتعطيل حد المخزن المؤقت للعميل لجميع الفئات. كما أنني أتلقى نفس الخطأ ولكن بطريقة ما لا أستطيع تفسير إجابتك. لذا ، هل يمكنك توضيح إجابتك بالتفصيل حتى أتمكن من إجراء التغييرات اللازمة. شكرا لك!

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

عند البحث في Google عن "حد التخزين المؤقت للعميل" ، يمكننا العثور على العديد من المقالات الشيقة. واحد ، الآن يبلغ من العمر 6 سنوات ، لديه - في النتائج - عنوان جميل حقًا The Replication Buffer - How to Avoid Devops Headache . هناك يمكننا أن نقرأ:

قبل زيادة حجم المخازن المؤقتة للنسخ المتماثل ، يجب التأكد من وجود ذاكرة كافية على جهازك.

في بعض المقالات الأخرى ، مخازن العميل - قبل استخدام Redis في الإنتاج ، تحقق من هذا! يقول المؤلف:

بشكل افتراضي ، لا يتم تقييد العملاء العاديين (أوامر التنفيذ العادية) لأنهم لا يتلقون البيانات دون طلب (بطريقة الدفع) ، ولكن بعد الطلب مباشرة ، لذلك يمكن للعملاء غير المتزامنين فقط إنشاء سيناريو يتم فيه طلب البيانات بشكل أسرع مما يمكن اقرأ.

أليس هذا هو حالتنا؟

بالنسبة لي ، على الأقل حتى الآن ، تبين أن إعادة التكوين هي الخلاص. لا توجد أخطاء "104" جديدة ، مع حمل ثقيل وفوري حقًا.

نقدر حقًا تحسين مستند العلاقات العامة

تضمين التغريدة

في redis.conf

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 0 0 0
client-output-buffer-limit pubsub 0 0 0

rganowski سيدي مرة أخرى قد أبدو ساذجًا جدًا ولكن لدي تطبيق Django الذي أستخدم فيه الكرفس (الإصدار 4.4.2) وأواجه مشكلة خطأ الاتصال. هل يمكنك المساعدة في تحديد موقع ملف redis.conf هذا أو إنشائه. هل أحتاج إلى إنشاء هذا الملف في تطبيقي أم أنه متوفر في بعض الحزم؟

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

auvipy هل هناك إصلاح لـ RabbitMQ كوسيط وخلفية للنتيجة لنفس المشكلة. رؤية هذا في 4.4 وكذلك في مهام التشغيل الطويل. الإصلاح أعلاه مخصص للخلفية redis فقط.

أيضا رؤية هذه المشكلة تحدث بشكل متقطع مع RabbitMQ والكرفس 4.2.0. حتى لو تم تضمينه في معالجة إعادة المحاولة بدلاً من فرض ذلك على مستخدمي الحزمة.

أنا أيضًا أواجهها. أنا على Celery 4.3.0 و RabbitMQ 3.3.5.