<p>kesalahan kenaikan seledri: [Errno 104] Sambungan reset oleh rekan setelah dimulai</p>

Saya melihat masalah yang sama dengan Celery 4.2.0. Saya tidak memilikinya dengan Celery 4.1.1. Secara lokal, saya sering, tetapi tidak selalu, mendapatkan Errno 104. Pada travis build tampaknya gagal lebih konsisten pada 4.2.0 (dan berhasil pada 4.1.1). Saya belum memperhatikan ketergantungan waktu yang dilaporkan @axiaoxin .

Bisakah Anda memberikan output dari perintah berikut:

$ celery -A proj report

hai @georgepsarakis ini laporan saya

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

sebagai laporan ini, beberapa dosis kata sandi tidak diganti dengan *

Untuk apa nilainya, saya melihat ini juga dengan proyek bersih menggunakan gevent dengan rabbitmq. Setelah memulai pengolah seledri selama beberapa menit, kami akan menerima koneksi ulang dan tidak ada tugas yang akan dikonsumsi setelahnya.

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

Masih mengalami masalah yang sama sejauh ini. (Seledri 4.2) Ini diatasi dengan menurunkan versi seledri ke 4.1, tetapi tidak tahu mengapa kesalahan ini terjadi.

Bisakah Anda mencoba menginstal seledri dari cabang master dengan semua ketergantungannya dari master dan melihat apa yang terjadi?

Masih mendapatkan kesalahan ini dengan Celery 4.2.2.

@auvipy Terima kasih, berhasil!

@ yuda110 tahukah Anda perubahan apa pada dependensi Anda yang menyelesaikan masalah?

Kami mendapatkan masalah ConnectionReset ini, dan kami menggunakan Celery 4.2.1 dengan versi berikut yang disematkan yang kompatibel dengan persyaratan seledri:

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

@tokopedia
Oh, saya lupa menghapus jawaban itu ☹️☹️ Tampaknya masalah telah terpecahkan setelah meningkatkan versi (ke 4.2.1), tetapi menghadapi masalah yang tidak diketahui lagi. Akhirnya saya harus downgrade ke versi 4.0.

Saya menurunkan versi ke 4.1 dan itu memperbaiki kesalahan. Belum mencoba 4.3.

Kesalahan ini jarang terjadi pada kami, dan ternyata itu adalah pengecualian berantai yang dimulai dengan kesalahan ConnectionReset dari klien redis. Saya hanya akan mengaktifkan percobaan ulang ketika kombu.exceptions.OperationalError dilemparkan, karena Celery ChangeLog menunjukkan ini adalah kesalahan yang dapat dicoba lagi.

Hanya ingin mengatakan bahwa masalah masih berlanjut di 4.3.0 saat menggunakan RabbitMQ. Entah bagaimana pindah ke Redis memperbaiki masalah tersebut.

Kami menyelesaikan ini dengan melakukan percobaan ulang dengan kemunduran eksponensial setiap kali kombu.exceptions.OperationalError dilemparkan. Itu dimaksudkan untuk dicoba lagi, menurut dokumen. Masalah ini sangat jarang terjadi pada kami, jadi percobaan ulang adalah solusi yang baik. Kami berada di 4.2.1.

Hai,

Saya menggunakan rabbitmq sebagai broker dan backend dan saya mengalami masalah yang sama.

Ada yang punya solusi?

Terima kasih sebelumnya.

Masalah yang sama di sini. Ini 100% dapat direproduksi untuk saya. Untuk beberapa alasan soket ke broker mati setelah apa yang tampaknya menjadi interval detak jantung.

melaporkan:

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

Saya harus mengatakan bahwa masalah saya dimulai ketika saya meningkatkan ke Erlang 22.0. Tapi itu mungkin juga bersifat rahasia.

dapatkah anda menyarankan perbaikan apapun? Jika Anda bisa maka itu akan dimasukkan dalam 4.4.0rc2

Saya dapat mengonfirmasi perilaku ini di 4.3.0 dengan pekerja gevent juga. Beralih dari gevent ke prefork tampaknya menyelesaikannya. Saya mencoba menurunkan ke 4.1.1 tetapi tampaknya itu tidak berfungsi pada Python 3.7 karena memerlukan versi gevent yang lebih lama (1.2.2) yang bahkan tidak dapat dikompilasi pada Python 3.7. Saya perhatikan ketika masalah dimulai, log rabbitmq menampilkan pesan ini:

missed heartbeats from client, timeout: 60s

Menariknya, meski detak jantungnya gagal, pekerja tersebut masih mengambil tugas dan memprosesnya dengan baik. Hanya saja celery inspect perintah sepanjang waktu sampai pekerja di-restart. flower masih menampilkan informasi di dasbor untuk pekerja, tetapi mengklik pekerja itu sendiri mendapat kesalahan 404 Not Found, dan kegagalan log bunga terkait dengan perintah pemeriksaan seledri:

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] 

butuh seseorang untuk memverifikasi ini di seledri 4.4.0rc3 + kombu 4.6.3?

Akan melakukan. FYI, seledri 4.4.0rc3 membutuhkan 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.

Oke, 4.4.0rc3 tampaknya menyelesaikan masalah ini. Saya telah membiarkannya berlangsung selama lebih dari 5 menit tanpa kesalahan detak jantung menggunakan pekerja gevent.

kombu 4.6.3 juga kompatibel

Jika demikian, Anda mungkin ingin memperbarui file persyaratan pada proyek seledri.

Tapi apa yang kita ubah?

Saya juga akan menyukai beberapa wawasan tentang apa yang berubah yang menyebabkan ini ditutup, atau tautan ke PR / kode / dll. Kami terpengaruh, dan menguranginya (prefork, rabbitmq, seledri 4.3) dengan menonaktifkan detak jantung yang tidak optimal.

@auvipy Ping?

Oke, 4.4.0rc3 tampaknya menyelesaikan masalah ini. Saya telah membiarkannya berlangsung selama lebih dari 5 menit tanpa kesalahan detak jantung menggunakan pekerja gevent.

masalah ditutup berdasarkan umpan balik ini

@auvipy Sepertinya ada beberapa masalah yang menyebabkan kesalahan serupa. Akan lebih bagus jika Anda mencoba mereproduksi bug secara lokal, mungkin dengan beberapa versi Celery yang lebih lama, sebelum menyelesaikan masalah.

Anda disarankan untuk mencoba cabang master.

Saya menyarankan untuk mereproduksi bug dengan salah satu versi sebelumnya (mis. 4.1, 4.2, 4.3) dan untuk memastikan bahwa peningkatan ke 4.4 saja telah memperbaiki masalah. Menutup bug tanpa verifikasi Anda sendiri - berdasarkan masukan dari satu orang - tampaknya agak terburu-buru.

karena Anda menghadapi masalah tersebut, Anda harus menjadi orang pertama yang memverifikasi seperti yang Anda sarankan. @tokopedia

Anda harus menjadi orang pertama yang memverifikasi seperti yang Anda sarankan

_ "Haruskah"? _;) Jika ada orang yang _harus_ peduli dengan kualitas proyek, itu adalah pengelola resminya. Saya bersyukur Anda menawarkan perangkat lunak Anda secara gratis, tetapi Anda tidak dapat mengharapkan secara realistis semua pengguna Anda untuk berkontribusi pada proyek tersebut.

Bagaimanapun, saya tidak memiliki konfigurasi yang menyebabkan masalah lagi, tetapi saya pikir masalah tetap ada bahkan jika antrian kosong tanpa tugas yang ditentukan, jadi mungkin mudah untuk mereproduksi. Saya telah menyelesaikan masalah ini dengan solusi dengan bermigrasi ke Redis, karena tim kami dapat dengan mudah mengubah teknologi pada saat itu. Dan, sejujurnya, kami sedang mempertimbangkan untuk pindah ke RQ karena masalah lain dengan Celery.

4.4.0rc4 juga tampaknya menyelesaikan masalah ini,

ada orang lain yang bisa memeriksanya dengan seledri == 4.4.0rc4

@auvipy Saya menggunakan 4.3.0 dengan sesekali Connection reset . Tidak ada lagi masalah dengan 4.4.0rc4 bagi saya.

ada orang lain yang bisa memeriksanya dengan seledri == 4.4.0rc4

Itu mendapat masalah di 4.3.0 cukup sering - dengan 4.4.0rc4 masalah terjadi jauh lebih jarang - tetapi masih terjadi dari waktu ke waktu.
Saya menggunakan redis-server 5.0.6 dan python redis Client 3.3.11 dengan ~ 14 Tugas periodik (setiap 30 detik).
Jadi saya akan meminta Anda untuk membuka kembali masalah tersebut.
Terima kasih!

Itu mendapat masalah di 4.3.0 cukup sering - dengan 4.4.0rc4 masalah terjadi jauh lebih jarang - tetapi masih terjadi dari waktu ke waktu.
Saya menggunakan redis-server 5.0.6 dan python redis Client 3.3.11 dengan ~ 14 Tugas periodik (setiap 30 detik).
Jadi saya akan meminta Anda untuk membuka kembali masalah tersebut.
Terima kasih

Memang, masalah masih terjadi dengan pengaturan default. Namun seperti yang disebutkan di utas lain, menyetel broker_heartbeat = 0 di celeryconfig.py tampaknya membantu.

Bahkan setelah meningkatkan ke seledri 4.4.0rc4 dan menambahkan CELERY_BROKER_HEARTBEAT = 0 di celery.py tidak banyak yang berubah untuk saya, masih mendapatkan kesalahan.

Masalah tidak terselesaikan setelah penurunan kualitas dari seledri 4.2.0 menjadi 4.10

Versi berikutnya adalah usinf dalam proyek kami:
biliar == 3.5.0.2, kombu == 4.1.0, seledri == 4.1.0, amqp == 2.4.2

tolong sarankan

Kami mulai melihat ini, atau sesuatu yang sangat mirip dengan masalah ini.

software -> seledri: 4.3.0 (rhubarb) kombu: 4.5.0 py: 2.7.12
billiard: 3.6.0.0 redis: 3.2.1

Itu mulai terjadi beberapa kali sehari, tanpa perubahan nyata.
Untuk rilis kami berikutnya, kami akan mencoba meningkatkan ke versi terbaru, celery 4.4.0, redis dll dan melaporkan kembali.

Terjadi untuk saya dengan (concurrency = 1000 (gevent) & redis sebagai broker):
seledri == 4.4.0 (tebing)
kombu == 4.6.7
biliar == 3.6.2.0
(py-) redis == 3.4.1

Versi server Redis = 5.0.7
Python 3.7.3

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

• 7 tugas diatur untuk dijalankan setiap 10 detik.
• Kesalahan hanya terjadi pada denyut seledri, dan sangat jarang terjadi kesalahan kurang dari 3 kasus setiap jam.

Tag

• penebang: seledri.beat
• runtime: CPython 3.7.5

Lingkungan Hidup

• Linux-4.15.0-1060-aws-x86_64-dengan-Ubuntu-18.04-bionic
• Python 3.7.5 (default, 7 Nov 2019, 10:50:52) [GCC 8.3.0]
• Redis server v = 4.0.9 sha = 00000000: 0 malloc = jemalloc-3.6.0 bits = 64 build = 9435c3c2879311f3
• seledri == 4.4.0
• biliar == 3.6.1.0
• kombu == 4.6.7
• redis == 3.3.11

Ini terjadi pada saya ketika saya terhubung ke server TCP menggunakan open_connection asyncio. 15 menit setelah saya terhubung ke server jarak jauh dalam vpn kami, itu memutuskan saya. Saya menduga ini karena koneksi tidak aktif. Hal yang sama tidak terjadi ketika saya menghubungkan dari dalam server jarak jauh. Ini tampaknya terkait jaringan.

Saya menyelesaikan kasus saya! Uff.

Itu bukan masalah seledri. Saya sudah mencoba beberapa versi, termasuk 4. [234] .0, dan saya sudah mencoba beberapa versi antarmuka python untuk redis. Dan saya selalu memiliki, lebih sedikit, rasio kegagalan yang sama (sekitar 2 ‰ untuk 0,5 juta permintaan)

Solusinya adalah dalam konfigurasi ulang server redis, yaitu menonaktifkan client-output-buffer-limit untuk semua kelas. Menurut dokumentasi redis :

Klien segera terputus setelah batas keras tercapai, atau jika batas lunak tercapai dan tetap tercapai selama jumlah detik yang ditentukan (terus-menerus).
…
Baik batas keras atau lunak dapat dinonaktifkan dengan menyetelnya ke nol.

Saya harap ini juga akan membantu Anda semua. Atau mungkin Anda akan meningkatkan solusi saya.

Saya menyelesaikan kasus saya! Uff.

Itu bukan masalah seledri. Saya sudah mencoba beberapa versi, termasuk 4. [234] .0, dan saya sudah mencoba beberapa versi antarmuka python untuk redis. Dan saya selalu memiliki, lebih sedikit, rasio kegagalan yang sama (sekitar 2 ‰ untuk 0,5 juta permintaan)

Solusinya adalah dalam konfigurasi ulang server redis, yaitu menonaktifkan client-output-buffer-limit untuk semua kelas. Menurut dokumentasi redis :

Klien segera terputus setelah batas keras tercapai, atau jika batas lunak tercapai dan tetap tercapai selama jumlah detik yang ditentukan (terus-menerus).
…
Baik batas keras atau lunak dapat dinonaktifkan dengan menyetelnya ke nol.

Saya harap ini juga akan membantu Anda semua. Atau mungkin Anda akan meningkatkan solusi saya.

Ini juga berhasil untuk saya, di mana tidak ada saran lain yang berhasil. Terima kasih!

Saya juga dapat mengonfirmasi bahwa itu menyelesaikan masalah untuk penyiapan saya! Terima kasih telah meluangkan waktu untuk @rganowski ini!

Bagus jika ini memperbaiki masalah, tetapi sebelum saya mulai menghapus default dari file konfigurasi, saya merasa senang mengetahui apa yang dilakukan pengaturan itu, dan mengapa itu bagian dari konfigurasi default?

@ Moulde Saya tidak begitu yakin apa yang Anda maksud dengan menghapus default dari file konfigurasi. File konfigurasi yang mana? Apakah maksud Anda mengubah pengaturan server Redis default yang saya tunjukkan?

Saya juga ingin tahu mengapa default seperti itu ada? Apakah itu sadar? Jika ya, apa risikonya untuk melepaskannya? Tapi, sejujurnya saya tidak akan memeriksanya. Saya memiliki tugas 10MD, saya harus menambahkan 3MD gratis.

Tidak ada yang mengatakan itu memperbaiki masalah. Saya berkata, bahwa saya menemukan solusi untuk kasus saya. Dua homies lain mengatakan itu juga berfungsi untuk mereka. Saya membacanya dengan senang hati. Tapi kata-katamu aku baca sedemikian rupa: "buktikan". Apakah aku salah?

Silakan, uji pada aplikasi Anda dan beri tahu kami jika itu berhasil untuk Anda. Jika Anda menyelesaikan keraguan lainnya, jangan lupa untuk membagikannya kepada orang lain.

@rganowski Kedengarannya seperti kami setuju, dan ya, saya mengerti apa yang Anda maksud dengan kata-kata saya, Itu tidak dimaksudkan seperti itu, tetapi lebih untuk menambahkan sedikit skeptisisme yang sehat sebelum mengubah default sistem, dan mungkin sedikit kritik terhadap dokumentasinya - sebagai sedikit info tentang mengapa pengaturan itu dibutuhkan akan sangat bagus, di samping bagian "apa yang dilakukannya" yang ada di file :)
Dan terima kasih atas waktu yang Anda berikan untuk ini, saya tidak akan mengetahuinya sendiri.

Masalah ditutup, karena tidak ada kesalahan dalam kode Celery, tetapi masalah di balik masalah tersebut tidak terpecahkan. Saya pikir peringatan yang memadai dalam dokumentasi pengaturan backend redis harus ditambahkan.

Googling untuk 'client-output-buffer-limit' kita dapat menemukan banyak artikel menarik. Satu, sekarang sudah 6 tahun, memiliki hasil - judul yang sangat indah Buffer Replikasi - Cara Menghindari Sakit Kepala Devops . Di sana kita bisa membaca:

Sebelum meningkatkan ukuran buffer replikasi, Anda harus memastikan Anda memiliki cukup memori di mesin Anda.

Di beberapa artikel lain Buffer Klien-Sebelum menggunakan Redis dalam produksi, periksa ini! penulis mengatakan:

Secara default, klien normal (perintah eksekusi normal) tidak dibatasi karena mereka tidak menerima data tanpa meminta (secara push), tetapi hanya setelah permintaan, jadi hanya klien asinkron yang dapat membuat skenario di mana data diminta lebih cepat daripada yang dapat dilakukan. Baca.

Bukankah itu kasus kita?

Bagi saya, setidaknya hingga saat ini, konfigurasi ulang ternyata adalah penyelamatan. Tidak ada kesalahan '104' baru, pada beban yang sangat berat dan instan.

@rganowski @moulde @ CM2Walki

Hai, Saya mungkin terdengar sangat naif tetapi dapatkah Anda memberi tahu saya di mana saya dapat membuat modifikasi yang diperlukan untuk menonaktifkan client-output-buffer-limit untuk semua kelas. Karena saya juga mendapatkan kesalahan yang sama tetapi entah mengapa saya tidak dapat menafsirkan jawaban Anda. Jadi bisakah Anda menguraikan jawaban Anda sehingga saya dapat membuat perubahan yang diperlukan. Terima kasih!

Masalah ditutup, karena tidak ada kesalahan dalam kode Celery, tetapi masalah di balik masalah tersebut tidak terpecahkan. Saya pikir peringatan yang memadai dalam dokumentasi pengaturan backend redis harus ditambahkan.

Googling untuk 'client-output-buffer-limit' kita dapat menemukan banyak artikel menarik. Satu, sekarang sudah 6 tahun, memiliki hasil - judul yang sangat indah Buffer Replikasi - Cara Menghindari Sakit Kepala Devops . Di sana kita bisa membaca:

Sebelum meningkatkan ukuran buffer replikasi, Anda harus memastikan Anda memiliki cukup memori di mesin Anda.

Di beberapa artikel lain Buffer Klien-Sebelum menggunakan Redis dalam produksi, periksa ini! penulis mengatakan:

Secara default, klien normal (perintah eksekusi normal) tidak dibatasi karena mereka tidak menerima data tanpa meminta (secara push), tetapi hanya setelah permintaan, jadi hanya klien asinkron yang dapat membuat skenario di mana data diminta lebih cepat daripada yang dapat dilakukan. Baca.

Bukankah itu kasus kita?

Bagi saya, setidaknya hingga saat ini, konfigurasi ulang ternyata adalah penyelamatan. Tidak ada kesalahan '104' baru, pada beban yang sangat berat dan instan.

sangat menghargai PR perbaikan dokumen

@ Girijesh97 @auvipy

Di 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 Pak Sekali lagi saya mungkin terdengar sangat naif tetapi saya memiliki aplikasi Django di mana saya menggunakan seledri (versi 4.4.2) dan menghadapi masalah kesalahan koneksi. Bisakah Anda membantu menemukan atau membuat file redis.conf ini. Apakah saya perlu membuat file ini di aplikasi saya atau tersedia dalam beberapa paket?

Jika case Anda sama, yang tadi kita bicarakan, seledri Anda menggunakan backend hasil server redis. File yang saya sebutkan adalah file konfigurasi server redis standar. Itu sebabnya ini sebenarnya bukan masalah seledri tapi efek samping.

@auvipy Apakah ada perbaikan untuk RabbitMQ sebagai broker dan hasil backend untuk masalah yang sama. Melihat ini di 4.4 juga pada tugas yang berjalan lama. Perbaikan di atas hanya untuk backend redis.

Juga melihat masalah ini terjadi sesekali dengan RabbitMQ dan seledri 4.2.0. Bahkan jika itu dibangun dalam penanganan coba lagi daripada memaksakannya pada pengguna paket.

Saya juga mengalaminya. Saya menggunakan Celery 4.3.0 dan RabbitMQ 3.3.5.