<p>ошибка подъема сельдерея: [Errno 104] Соединение сброшено одноранговым узлом после запуска</p>

Я вижу ту же проблему с Celery 4.2.0. У меня с Celery 4.1.1 его нет. Локально я часто, но не всегда, получаю Errno 104. На сборке travis кажется, что она более стабильно терпит неудачу на 4.2.0 (и успешна на 4.1.1). Я не заметил зависимости от времени, о которой сообщает

Не могли бы вы представить вывод следующей команды:

$ 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 с 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

@charlescapps
О, я забыл стереть этот ответ ☹️☹️ Казалось, проблема была решена после обновления версии (до 4.2.1), но снова столкнулся с неизвестной проблемой. В конце концов мне пришлось перейти на версию 4.0.

Я понизился до 4.1, и ошибка исправлена. Хотя еще не пробовал 4.3.

Эта ошибка возникает у нас довольно редко, и оказывается, что это цепное исключение, которое начинается с ошибки ConnectionReset от клиента redis. Я собираюсь просто включить повторные попытки, когда выдается kombu.exceptions.OperationalError , потому что журнал изменений Celery указывает, что это ошибка с возможностью повторной попытки.

Просто хотел сказать, что проблема все еще сохраняется в 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 требует комбу 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 минут без ошибок пульса, используя gevent worker.

Комбу 4.6.3 также совместим

В этом случае вы можете обновить файл требований в проекте celery.

Но что мы изменили?

Я также хотел бы получить представление о том, что было изменено, что привело к его закрытию, или ссылку на PR / код / ​​и т. Д. На нас это влияет, и мы смягчаем его (prefork, rabbitmq, celery 4.3), отключая сердцебиение, что неоптимально.

@auvipy Ping?

Хорошо, 4.4.0rc3, похоже, решает эту проблему. Я оставил его работать более 5 минут без ошибок пульса, используя gevent worker.

вопрос был закрыт на основании этого отзыва

@auvipy Кажется, есть несколько проблем, которые приводят к аналогичным ошибкам. Было бы здорово, если бы вы попытались воспроизвести ошибку локально, возможно, с некоторыми более старыми версиями Celery, прежде чем решать проблему.

Вам предлагается попробовать основную ветку.

Я предлагаю воспроизвести ошибку в одной из более ранних версий (например, 4.1, 4.2, 4.3) и убедиться, что только обновление до 4.4 устранило проблему. Закрывать ошибку без вашей собственной проверки - на основе отзывов одного человека - кажется немного поспешным.

поскольку вы столкнулись с проблемой, вы должны быть первым, кто подтвердит, как вы предложили. @czyzby

вы должны быть первым, кто подтвердит, как вы предложили

_ "Должен"? _;) Если и есть кто-то, кто _должен_ заботиться о качестве проекта, так это официальные сопровождающие. Я благодарен за то, что вы предлагаете свое программное обеспечение бесплатно, но вы не можете реально ожидать, что все ваши пользователи внесут свой вклад в проект.

В любом случае, у меня больше нет конфигурации, которая вызвала проблему, но я думаю, что проблема сохраняется даже в случае пустых очередей без определенных задач, поэтому ее можно легко воспроизвести. С тех пор я решил проблему с помощью обходного пути, перейдя на Redis, поскольку наша команда могла легко изменить технологии в то время. И, честно говоря, мы рассматриваем возможность перехода на RQ из-за других проблем с Celery.

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-server 5.0.6 и python redis Client 3.3.11 с ~ 14 периодическими задачами (каждые 30 секунд).
Поэтому я прошу вас снова открыть вопрос.
Спасибо!

Проблема возникает в 4.3.0 довольно часто - с 4.4.0rc4 проблема возникает гораздо реже - но время от времени все еще возникает.
Я использую redis-server 5.0.6 и python redis Client 3.3.11 с ~ 14 периодическими задачами (каждые 30 секунд).
Поэтому я прошу вас снова открыть вопрос.
Спасибо

Действительно, проблема все еще возникает с настройками по умолчанию. Однако, как упоминалось в других потоках, установка broker_heartbeat = 0 в celeryconfig.py похоже, помогает.

Даже после обновления до сельдерея 4.4.0rc4 и добавления CELERY_BROKER_HEARTBEAT = 0 в celery.py для меня ничего особенного не изменилось, я все еще получаю ошибку.

проблема не была решена после перехода с сельдерея 4.2.0 на 4.10

В нашем проекте используются следующие версии:
бильярд == 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

Это стало происходить несколько раз в день без каких-либо реальных изменений.
В нашем следующем выпуске мы постараемся обновить до самых последних версий, celery 4.4.0, redis и т. Д. И сообщить об этом.

У меня случается с (concurrency = 1000 (gevent) и redis в качестве брокера):
сельдерей == 4.4.0 (скалы)
комбу == 4.6.7
бильярд == 3.6.2.0
(py-) redis == 3.4.1

Версия сервера Redis = 5.0.7
Python 3.7.3

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

• 7 задач настроены на запуск каждые 10 секунд.
• Ошибка возникает только в доле сельдерея, и очень редко ошибка возникает менее чем в 3 случаях каждый час.

Теги

• регистратор: celery.beat
• время выполнения: CPython 3.7.5

Среда

• Linux-4.15.0-1060-aws-x86_64-с-Ubuntu-18.04-бионический
• 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 build = 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 ‰ на 0,5 миллиона запросов).

Решение заключалось в перенастройке сервера Redis, то есть в отключении ограничения буфера вывода клиента для всех классов. Согласно документации Redis :

Клиент немедленно отключается при достижении жесткого предела или при достижении мягкого предела и остается достигнутым в течение указанного количества секунд (постоянно).
…
Как жесткий, так и мягкий предел можно отключить, установив их на ноль.

Я надеюсь, что это поможет и вам всем. Или, может быть, вы улучшите мое решение.

Я раскрыл свое дело! Уфф.

Это была не проблема с сельдереем. Я пробовал несколько его версий, включая 4. [234] .0, и я пробовал несколько версий интерфейсов Python для redis. И у меня всегда было, более того, такое же соотношение отказов (около 2 ‰ на 0,5 миллиона запросов).

Решение заключалось в перенастройке сервера Redis, то есть в отключении ограничения буфера вывода клиента для всех классов. Согласно документации Redis :

Клиент немедленно отключается при достижении жесткого предела или при достижении мягкого предела и остается достигнутым в течение указанного количества секунд (постоянно).
…
Как жесткий, так и мягкий предел можно отключить, установив их на ноль.

Я надеюсь, что это поможет и вам всем. Или, может быть, вы улучшите мое решение.

Это также сработало для меня, хотя ни одно из других предложений не помогло. Спасибо!

Я также могу подтвердить, что проблема с моей настройкой решена! Спасибо, что уделили время этому @rganowski!

Отлично, если это решит проблему, но прежде чем я начну удалять значения по умолчанию из файла конфигурации, я чувствую, что было бы здорово узнать, что делает этот параметр и почему он является частью конфигурации по умолчанию?

@Moulde Я не совсем понимаю, что вы имеете в виду, говоря об удалении значений по умолчанию из файла конфигурации. Какой файл конфигурации? Вы имеете в виду изменение настроек сервера Redis по умолчанию, на которые я указал?

Я также хотел бы знать, почему существуют такие значения по умолчанию? Это было сознательно? Если да, то каков риск отказаться от них? Но, честно говоря, я не собираюсь это проверять. У меня была задача 10MD, пришлось добавить 3MD бесплатно.

Никто не сказал, что это решает проблему. Я сказал, что нашел решение для своего случая. Двое других корешей сказали, что им это тоже подходит. Я с удовольствием это прочитал. Но ваши слова я прочитал так: «докажите». Я ошибся?

Пожалуйста, протестируйте его в своем приложении и сообщите нам, работает ли он для вас. Если вы разрешите другие сомнения, не забудьте поделиться ими с другими.

@rganowski Похоже, что мы согласны, и да, я понимаю, что вы имеете в виду с моей формулировкой, это не имелось в виду, но больше, чтобы добавить немного здорового скептицизма перед изменением настроек системы по умолчанию и, возможно, немного критики документации - так как небольшая информация о том, зачем нужна эта настройка, было бы здорово, помимо части "что он делает" в файле :)
И спасибо за время, которое вы вложили в это, я бы не понял этого самостоятельно.

Проблема закрыта, потому что в коде Celery не было ошибки, но проблема, лежащая в основе проблемы, не решена. Думаю, нужно добавить соответствующее предупреждение в документацию по настройкам бэкэнда Redis.

Погуглив по запросу client-output-buffer-limit, можно найти много интересных статей. Один, которому сейчас уже 6 лет, в результате получил действительно красивое название

Перед увеличением размера буферов репликации вы должны убедиться, что на вашем компьютере достаточно памяти.

В другой статье Client Buffers - Прежде чем запускать Redis в производство, проверьте это! автор говорит:

По умолчанию обычные клиенты (обычные команды выполнения) не ограничены, потому что они не получают данные без запроса (путем push), а сразу после запроса, поэтому только асинхронные клиенты могут создать сценарий, в котором данные запрашиваются быстрее, чем они могут читать.

Разве это не наш случай?

Для меня, по крайней мере, до сих пор, реконфигурация оказалась спасением. Никаких новых ошибок «104» при действительно большой и мгновенной загрузке.

@rganowski @Moulde @ CM2Walki

Привет, я могу показаться очень наивным, но не могли бы вы сказать мне, где я могу внести необходимые изменения, чтобы отключить client-output-buffer-limit для всех классов. Поскольку я также получаю ту же ошибку, но почему-то не могу интерпретировать ваш ответ. Не могли бы вы уточнить свой ответ, чтобы я мог внести необходимые изменения. Спасибо!

Проблема закрыта, потому что в коде Celery не было ошибки, но проблема, лежащая в основе проблемы, не решена. Думаю, нужно добавить соответствующее предупреждение в документацию по настройкам бэкэнда Redis.

Погуглив по запросу client-output-buffer-limit, можно найти много интересных статей. Один, которому сейчас уже 6 лет, в результате получил действительно красивое название

Перед увеличением размера буферов репликации вы должны убедиться, что на вашем компьютере достаточно памяти.

В другой статье Client Buffers - Прежде чем запускать Redis в производство, проверьте это! автор говорит:

По умолчанию обычные клиенты (обычные команды выполнения) не ограничены, потому что они не получают данные без запроса (путем push), а сразу после запроса, поэтому только асинхронные клиенты могут создать сценарий, в котором данные запрашиваются быстрее, чем они могут читать.

Разве это не наш случай?

Для меня, по крайней мере, до сих пор, реконфигурация оказалась спасением. Никаких новых ошибок «104» при действительно большой и мгновенной загрузке.

действительно ценю PR улучшения документа

@ girijesh97 @auvipy

В 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 в качестве брокера и

Также эта проблема периодически возникает с RabbitMQ и сельдереем 4.2.0. Даже если он встроен в обработку повторных попыток, а не на принудительную обработку пользователей пакета.

Я тоже это переживаю. Я использую Celery 4.3.0 и RabbitMQ 3.3.5.