Canvas 워크 플로를 사용하고 있습니까? # 4839가 관련이있을 수도 있습니다.

또한 작업자 동시성을 위해 prefork 풀을 사용하고 있다고 가정합니까?

감사합니다 georgepsarakis.

워크 플로를 사용하지 않습니다.
단일 서버에서 prefork 동시성 1을 사용합니다.

증가율은 매우 선형적이고 이상하게 보입니다. 이 기간 동안 작업자가 작업을 처리합니까? 또한 작업자를 시작하는 데 사용하는 완전한 명령으로 메모를 추가 할 수 있습니까?

예. 작업자는 계속해서 정상적으로 작업을 처리합니다.

작업자는 다음 명령으로 시작됩니다.

/xxxxxxxx/bin/celery worker --app=xxxxxxxx --loglevel=INFO --pidfile=/var/run/xxxxxxxx.pid

이 문제는 프로덕션 환경과 테스트 환경 모두에서 발생합니다.
테스트 환경에 메모리 프로필과 테스트 출력을 추가 할 수 있습니다.
제가 할 수있는 일이 있으면 말씀해주세요.

메모리 증가가 관찰되는 동안 작업자가 실행중인 작업을 이해해야합니다. 당신이 제공 할 수있는 모든 정보와 세부 사항은 확실히 될 것입니다. 이것을 재현 할 수있는 것도 좋습니다.

그래프와 다른 타이밍에 발생한 경우 였지만 다음 로그는 메모리 누수가 시작된 시점에 출력되었습니다.

[2018-02-24 07:50:52,953: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
File "/xxxxxxxx/lib/python3.5/site-packages/celery/worker/consumer/consumer.py", line 320, in start
blueprint.start(self)
File "/xxxxxxxx/lib/python3.5/site-packages/celery/bootsteps.py", line 119, in start
step.start(parent)
File "/xxxxxxxx/lib/python3.5/site-packages/celery/worker/consumer/consumer.py", line 596, in start
c.loop(*c.loop_args())
File "/xxxxxxxx/lib/python3.5/site-packages/celery/worker/loops.py", line 88, in asynloop
next(loop)
File "/xxxxxxxx/lib/python3.5/site-packages/kombu/async/hub.py", line 293, in create_loop
poll_timeout = fire_timers(propagate=propagate) if scheduled else 1
File "/xxxxxxxx/lib/python3.5/site-packages/kombu/async/hub.py", line 136, in fire_timers
entry()
File "/xxxxxxxx/lib/python3.5/site-packages/kombu/async/timer.py", line 68, in __call__
return self.fun(*self.args, **self.kwargs)
File "/xxxxxxxx/lib/python3.5/site-packages/kombu/async/timer.py", line 127, in _reschedules
return fun(*args, **kwargs)
File "/xxxxxxxx/lib/python3.5/site-packages/kombu/connection.py", line 290, in heartbeat_check
return self.transport.heartbeat_check(self.connection, rate=rate)
File "/xxxxxxxx/lib/python3.5/site-packages/kombu/transport/pyamqp.py", line 149, in heartbeat_check
return connection.heartbeat_tick(rate=rate)
File "/xxxxxxxx/lib/python3.5/site-packages/amqp/connection.py", line 696, in heartbeat_tick
self.send_heartbeat()
File "/xxxxxxxx/lib/python3.5/site-packages/amqp/connection.py", line 647, in send_heartbeat
self.frame_writer(8, 0, None, None, None)
File "/xxxxxxxx/lib/python3.5/site-packages/amqp/method_framing.py", line 166, in write_frame
write(view[:offset])
File "/xxxxxxxx/lib/python3.5/site-packages/amqp/transport.py", line 258, in write
self._write(s)
ConnectionResetError: [Errno 104] Connection reset by peer
[2018-02-24 08:49:12,016: INFO/MainProcess] Connected to amqp://xxxxxxxx:**@xxx.xxx.xxx.xxx:5672/xxxxxxxx

RabbitMQ와의 연결이 일시적으로 끊겼을 때 발생한 것 같습니다.

@marvelph 그래서 RabbitMQ 재 연결 중에 발생합니까? 다음과 같은 문제가있을 수 있습니다.

• https://github.com/celery/kombu/issues/843
• https://github.com/celery/celery/pull/4839#issuecomment -399633253

예.
재 연결이 트리거하는 것 같습니다.

똑같은 문제가있는 것 같습니다 ... 무엇이 원인인지, 왜 기억력 유출이 있는지 알아 내기가 너무 어렵습니다. 그것은 적어도 한 달 동안 나를 괴롭힌다. 나는 셀러리 3을 사용하고 모든 것이 괜찮습니다.

메모리 누수 문제의 경우 rabbitmq와 함께 ubuntu 16, celery 4.1.0을 사용하고 있습니다. 도커를 통해 배포했습니다.

메모리 누수는 ForkPoolWorker가 아닌 MainProcess에서 발생합니다. ForkPoolWorker의 메모리 사용량은 정상이지만 MainProcess의 메모리 사용량은 항상 증가하고 있습니다. 5 초 동안 약 0.1MB의 메모리가 유출됩니다. 메모리 누수는 작업이 즉시 시작된 후 시작되지 않고 1 ~ 2 일 후에 시작됩니다.

gdb와 pyrasite를 사용하여 실행중인 프로세스를 주입하고 gc.collect() 시도했지만 아무것도 수집되지 않았습니다.

로그를 확인했는데 consumer: Connection to broker lost. Trying to re-establish the connection... 가 발생했지만 지금은 메모리 누수가 발생하는 시점인지 확실하지 않습니다.

이 문제를 디버깅하고 실제로 어떤 일이 발생하는지 알아 내기위한 힌트가 있습니까? 감사.

@marvelph가 rabbitmq 재연 결과 관련이있을 수 rabbitmq 서버를 중지하려고합니다. 다시 연결될 때마다 메모리 사용량이 증가했습니다. 다음은 로그입니다. 그래서이 https://github.com/celery/kombu/issues/843 문제를 확인할 수 있습니다.

그러나 연결이 다시 연결되면 메모리 사용량이 점차 증가하여 중지됩니다. 그래서 이것이 메모리 누수의 원인인지 잘 모르겠습니다.

이 메모리 누수 문제가 rabbitmq와 관련이 있는지 여부를 알아 내기 위해 redis를 사용하려고합니다.

[2018-06-25 02:43:33,456: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/worker/consumer/consumer.py", line 316, in start
    blueprint.start(self)
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/worker/consumer/consumer.py", line 592, in start
    c.loop(*c.loop_args())
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/worker/loops.py", line 91, in asynloop
    next(loop)
  File "/app/.heroku/python/lib/python3.6/site-packages/kombu/asynchronous/hub.py", line 354, in create_loop
    cb(*cbargs)
  File "/app/.heroku/python/lib/python3.6/site-packages/kombu/transport/base.py", line 236, in on_readable
    reader(loop)
  File "/app/.heroku/python/lib/python3.6/site-packages/kombu/transport/base.py", line 218, in _read
    drain_events(timeout=0)
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/connection.py", line 491, in drain_events
    while not self.blocking_read(timeout):
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/connection.py", line 496, in blocking_read
    frame = self.transport.read_frame()
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/transport.py", line 243, in read_frame
    frame_header = read(7, True)
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/transport.py", line 418, in _read
    s = recv(n - len(rbuf))
ConnectionResetError: [Errno 104] Connection reset by peer
[2018-06-25 02:43:33,497: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 2.00 seconds...

[2018-06-25 02:43:35,526: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 4.00 seconds...

[2018-06-25 02:43:39,560: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 6.00 seconds...

[2018-06-25 02:43:45,599: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 8.00 seconds...

[2018-06-25 02:43:53,639: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 10.00 seconds...

[2018-06-25 02:44:03,680: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 12.00 seconds...

[2018-06-25 02:44:15,743: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 14.00 seconds...

[2018-06-25 02:44:29,790: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 16.00 seconds...

[2018-06-25 02:44:45,839: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 18.00 seconds...

[2018-06-25 02:45:03,890: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 20.00 seconds...

[2018-06-25 02:45:23,943: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 22.00 seconds...

[2018-06-25 02:45:46,002: ERROR/MainProcess] consumer: Cannot connect to amqp://***:**@***:***/***: [Errno 111] Connection refused.
Trying again in 24.00 seconds...

[2018-06-25 02:46:10,109: INFO/MainProcess] Connected to amqp://***:**@***:***/***
[2018-06-25 02:46:10,212: INFO/MainProcess] mingle: searching for neighbors
[2018-06-25 02:46:10,291: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/worker/consumer/consumer.py", line 316, in start
    blueprint.start(self)
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/worker/consumer/mingle.py", line 40, in start
    self.sync(c)
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/worker/consumer/mingle.py", line 44, in sync
    replies = self.send_hello(c)
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/worker/consumer/mingle.py", line 57, in send_hello
    replies = inspect.hello(c.hostname, our_revoked._data) or {}
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/app/control.py", line 132, in hello
    return self._request('hello', from_node=from_node, revoked=revoked)
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/app/control.py", line 84, in _request
    timeout=self.timeout, reply=True,
  File "/app/.heroku/python/lib/python3.6/site-packages/celery/app/control.py", line 439, in broadcast
    limit, callback, channel=channel,
  File "/app/.heroku/python/lib/python3.6/site-packages/kombu/pidbox.py", line 315, in _broadcast
    serializer=serializer)
  File "/app/.heroku/python/lib/python3.6/site-packages/kombu/pidbox.py", line 290, in _publish
    serializer=serializer,
  File "/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py", line 181, in publish
    exchange_name, declare,
  File "/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py", line 203, in _publish
    mandatory=mandatory, immediate=immediate,
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/channel.py", line 1732, in _basic_publish
    (0, exchange, routing_key, mandatory, immediate), msg
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/abstract_channel.py", line 50, in send_method
    conn.frame_writer(1, self.channel_id, sig, args, content)
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/method_framing.py", line 166, in write_frame
    write(view[:offset])
  File "/app/.heroku/python/lib/python3.6/site-packages/amqp/transport.py", line 275, in write
    self._write(s)
ConnectionResetError: [Errno 104] Connection reset by peer
[2018-06-25 02:46:10,375: INFO/MainProcess] Connected to amqp://***:**@***:***/***
[2018-06-25 02:46:10,526: INFO/MainProcess] mingle: searching for neighbors
[2018-06-25 02:46:11,764: INFO/MainProcess] mingle: all alone

로그를 확인했지만 메모리 누수 시점에 재 연결 로그를 발견했지만, 재 연결이 발생하지 않은 시점에서 메모리 누수가 시작되는 경우도있었습니다.
나는 jxlton의 아이디어에 동의합니다.

또한 Celery 3.x를 사용할 때 그런 문제가 발생하지 않았습니다.

여기에 같은 문제

이 문제로 인해 며칠마다 작업자를 다시 시작해야합니다.
로그에는 중요한 단서가 없지만 재 연결이 영향을 미칠 수 있다는 의심이 있습니다. 메모리가 지속적으로 증가하기 시작할 때 어딘가에 로그 항목을 다시 연결했기 때문에
내 conf는 우분투 17, 1 서버-3 동시성을 가진 1 작업자입니다. 백엔드의 rabbit 및 redis; 모든 패키지는 최신 버전입니다.

@marvelph @ dmitry-kostin 정확한 구성 (물론 민감한 정보 생략)과 문제를 재현하는 작업 또는 샘플을 제공해 주시겠습니까? 또한 작업자 메모리 증가가 나타나기 시작하는 평균 가동 시간 간격에 대한 추정치가 있습니까?

구성이 기본값에 가깝습니다.

수입 = ( 'app.tasks',)
result_persistent = True
task_ignore_result = 거짓
task_acks_late = 참
worker_concurrency = 3
worker_prefetch_multiplier = 4
enable_utc = True
시간대 = '유럽 / 모스크바'
broker_transport_options = { 'visibility_timeout': 3600, 'confirm_publish': True, 'fanout_prefix': True, 'fanout_patterns': True}

기본적으로 이것은 새로 배치 된 노드입니다. 그것은 06/21 18-50에 배치되었습니다; 05-00 경에 6/23 성장을 쳐다보고 마침내 23-00 경에 6/23에 추락했습니다.

작업은 매우 간단하고 거기에는 수퍼 로직이 없습니다. 명확한 임시 프로젝트에서 전체 상황을 재현 할 수 있지만 지금은 자유 시간이 없다고 생각합니다. 운이 좋으면 주말에 전체 예제를 시도해 보겠습니다.

UPD
작업 자체가 약간의 메모리를 소비하는 것을 볼 수 있듯이 그래프에서 급증으로 볼 수 있지만 메모리 누수를봤을 때 생성 된 작업이나 다른 활동이 없었습니다.

@marvelph @ dmitry-kostin @jxltom 나는 당신이 Python3을 사용하는 것을 발견했습니다. 프로세스에 대해 tracemalloc 을 활성화 하시겠습니까? 메모리 할당 추적을 기록하기 위해 작업자 프로세스를 패치해야 할 수도 있습니다. 도움이 필요하면 알려주세요.

@georgepsarakis 작업자 및 로그 통계 (예 : 상위 10 개 메모리 사용량 파일)에서 5 분과 같은 특정 간격으로 tracemalloc을 활성화한다는 의미입니까?

@jxltom 나는 그와 같은 것이 책임있는 코드 부분을 찾는 데 도움이 될 것이라고 생각합니다. 어떻게 생각해?

@georgepsarakis 나는 gdb와 https://github.com/lmacken/pyrasite 를 사용하여 메모리 누수 프로세스를 주입하고 tracemalloc을 통해 디버그를 시작하려고했습니다. 다음은 메모리 사용량이 가장 많은 상위 10 개 파일입니다.

나는 resource.getrusage(resource.RUSAGE_SELF).ru_maxrss / 1024 를 사용하고 실제로 메모리 사용량이 점차 증가하고 있습니다.

>>> import tracemalloc
>>> 
>>> tracemalloc.start()
>>> snapshot = tracemalloc.take_snapshot()
>>> top_stats = snapshot.statistics('lineno')
>>> for stat in top_stats[:10]:
...     print(stat)
... 
/app/.heroku/python/lib/python3.6/site-packages/kombu/utils/eventio.py:84: size=12.0 KiB, count=1, average=12.0 KiB
/app/.heroku/python/lib/python3.6/site-packages/celery/worker/heartbeat.py:47: size=3520 B, count=8, average=440 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/method_framing.py:166: size=3264 B, count=12, average=272 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:142: size=3060 B, count=10, average=306 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:157: size=2912 B, count=8, average=364 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/abstract_channel.py:50: size=2912 B, count=8, average=364 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py:181: size=2816 B, count=12, average=235 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py:203: size=2816 B, count=8, average=352 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:199: size=2672 B, count=6, average=445 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/channel.py:1734: size=2592 B, count=8, average=324 B

약 5 분 후 두 스냅 샷의 차이는 다음과 같습니다.

>>> snapshot2 = tracemalloc.take_snapshot()
>>> top_stats = snapshot2.compare_to(snapshot, 'lineno')
>>> print("[ Top 10 differences ]")
[ Top 10 differences ]

>>> for stat in top_stats[:10]:
...     print(stat)
... 
/app/.heroku/python/lib/python3.6/site-packages/celery/worker/heartbeat.py:47: size=220 KiB (+216 KiB), count=513 (+505), average=439 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:142: size=211 KiB (+208 KiB), count=758 (+748), average=285 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/method_framing.py:166: size=210 KiB (+206 KiB), count=789 (+777), average=272 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:157: size=190 KiB (+187 KiB), count=530 (+522), average=366 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/abstract_channel.py:50: size=186 KiB (+183 KiB), count=524 (+516), average=363 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:199: size=185 KiB (+182 KiB), count=490 (+484), average=386 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py:203: size=182 KiB (+179 KiB), count=528 (+520), average=353 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py:181: size=179 KiB (+176 KiB), count=786 (+774), average=233 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/channel.py:1734: size=165 KiB (+163 KiB), count=525 (+517), average=323 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/async/hub.py:293: size=157 KiB (+155 KiB), count=255 (+251), average=632 B

이것을 계속해서 디버깅하는 방법에 대한 제안이 있습니까? 진행 방법에 대한 단서가 없습니다. 감사.

안녕하세요.

재생산을 위해 프로젝트를 잘라낼 시간이 좀 필요합니다.

셀러리의 설정입니다.

BROKER_URL = [
    'amqp://xxxxxxxx:[email protected]:5672/zzzzzzzz'
]
BROKER_TRANSPORT_OPTIONS = {}

스케줄러에는 다음과 같은 설정이 있습니다.

CELERYBEAT_SCHEDULE = {
    'aaaaaaaa_bbbbbbbb': {
        'task': 'aaaa.bbbbbbbb_cccccccc',
        'schedule': celery.schedules.crontab(minute=0),
    },
    'dddddddd_eeeeeeee': {
        'task': 'dddd.eeeeeeee_ffffffff',
        'schedule': celery.schedules.crontab(minute=0),
    },
}

EC 2에서는 supervisord를 사용하여 작동합니다.

안녕하세요.
내 테스트 환경은 성능 저하를 허용 할 수 있으므로 tracemalloc을 사용할 수 있습니다.
메모리 사용량을 덤프하기 위해 패치 된 셀러리를 만들 수 있습니까?

@jxltom 5 분 동안 tracemalloc이 문제를 찾는 데 도움이되지 않을 것이라고 확신합니다.
예를 들어 5 개의 노드가 있고 그중 3 개만이 지난 4 일 동안이 문제를 겪었고 이번에는 2 개가 정상적으로 작동했기 때문에 문제를 찾는 것이 매우 까다로울 것입니다 ..
이 스위치 메모리 소비가 아주 잘 보일 때까지 스위치를 켜고 메모리가 커지기 시작하는 토글이있는 것 같습니다.

다른 실행 시스템에서도 비슷한 문제가 발생했는지 알아 보려고했습니다.
발생 빈도는 다양하지만 Celery 4.x를 사용하는 세 시스템에서 메모리 누수가 발생했으며 한 시스템에서는 발생하지 않았습니다.
메모리 누수가있는 시스템은 Python 3.5.x이고 메모리 누수가없는 시스템은 Python 2.7.x입니다.

@ dmitry-kostin 다른 두 일반 노드와의 차이점은 무엇입니까? 둘 다 브로커와 동일한 rabbitmq를 사용하고 있습니까?

토론에서 rabbitmq와 관련이있을 수 있다고 언급 했으므로 대신 redis를 사용하는 것을 제외하고는 동일한 구성으로 다른 새 노드를 시작했습니다. 지금까지이 노드는 24 시간 실행 한 후에도 메모리 누수가 없습니다. 나중에 메모리 누수가 있으면 여기에 게시하겠습니다.

@marvelph 그렇다면 메모리 누수가있는 세 시스템은 python3을 사용하고 있고 괜찮은 시스템은 python2를 사용하고 있다는 뜻입니까?

@jxltom 전혀 차이가 없으며 예 그들은 파이썬 3 및 rabit에 브로커 및 redis에 백엔드에 있습니다.
나는 이것을 재현하기 위해 테스트 예제를 만들었습니다. 며칠 안에 성공한다면이 버그를 찾는 방법을 알고있는 누군가를 위해이 서버에 자격 증명을 줄 것입니다.

뿡뿡
예.
내 환경에 관한 한 Python 2에서는 문제가 발생하지 않습니다.

오랜 기간 동안 tracemalloc을 통해 메모리 누수를 추적했습니다.

resource 모듈에서보고 한 시작 메모리 사용량은 146.58MB 이며 3.5 시간 후에 메모리 사용량이 224.21MB 라고보고합니다.

다음은 tracemalloc 보고 한 스냅 샷 차이입니다.

>>> snapshot2 = tracemalloc.take_snapshot(); top_stats = snapshot2.compare_to(snapshot, 'lineno')
>>> for stat in top_stats[:10]:
...     print(stat)
... 
/app/.heroku/python/lib/python3.6/site-packages/celery/worker/heartbeat.py:47: size=3619 KiB (+3614 KiB), count=8436 (+8426), average=439 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:142: size=3470 KiB (+3466 KiB), count=12529 (+12514), average=284 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/method_framing.py:166: size=3418 KiB (+3414 KiB), count=12920 (+12905), average=271 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:157: size=3149 KiB (+3145 KiB), count=8762 (+8752), average=368 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/abstract_channel.py:50: size=3099 KiB (+3096 KiB), count=8685 (+8676), average=365 B
/app/.heroku/python/lib/python3.6/site-packages/celery/events/dispatcher.py:199: size=3077 KiB (+3074 KiB), count=8354 (+8345), average=377 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py:203: size=3020 KiB (+3017 KiB), count=8723 (+8713), average=355 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/messaging.py:181: size=2962 KiB (+2959 KiB), count=12952 (+12937), average=234 B
/app/.heroku/python/lib/python3.6/site-packages/amqp/channel.py:1734: size=2722 KiB (+2718 KiB), count=8623 (+8613), average=323 B
/app/.heroku/python/lib/python3.6/site-packages/kombu/async/hub.py:293: size=2588 KiB (+2585 KiB), count=4193 (+4188), average=632 B

어떤 아이디어? 단일 파일이 유출되지 않는 것 같습니다.

또한 gc 가져 왔고 gc.collect() 는 0 반환합니다.

@georgepsarakis 나는 이것을 재현 할 수 있었고 액세스

업데이트 : 브로커 URL을 환경 변수로 업데이트하고 도커 / 코드를 완전히 동일하게 유지하여 rabbitmq에서 redis로 브로커를 업데이트했습니다. 그리고 4 일 동안 실행되며 메모리 누수가 없습니다 .

그래서 나는이 문제가 rabbitmq 브로커와 관련이 있다고 생각합니다.

가능하면 여기에 언급 된 벤치 마크 명령을 실행 해보십시오. https://github.com/celery/celery/issues/2927#issuecomment -171455414

이 시스템은 20 대의 서버로 작업자를 실행하고 있습니다.
어제 메모리 누수가 발생했지만 거의 모든 서버에서 동시에 발생하고 있습니다.

관련이 있는지 모르고 도움이 될 수 있도록 여기에 두십시오.

셀러리와 rabbitmq에 다른 문제가 있습니다 (셀러리가 연결이 끊어지고 초당로드를 다시 연결하기 시작하고 CPU가 1 코어에서 100 %가되고 비트가 새 작업을 보낼 수 없으며 셀러리를 다시 시작해야 함).

내가 여기에 이것을보고하는 이유는 방아쇠 때문입니다. 모니터링 후 며칠 후에 문제의 시작을 찾은 것 같고 메모리에서 디스크로 일부 메시지를 이동하는 rabbitmq 인 것 같습니다. 이때 셀러리는 최대한 빨리 재 연결을 시도하기 시작하고 rabbitmq 로그는 한 번에 ~ 10 개 정도의 일괄 처리로 초당 수십 건의 연결 / 연결 해제 작업을 보여줍니다. rabbitmq를 다시 시작해도 문제가 해결되지 않고 셀러리를 다시 시작하면 즉시 문제가 해결됩니다. 적절한 수정 사항은 없지만 예를 들어 메시지가 항상 메모리에 남아 있도록 허용하는 만료 정책을 설정하면 문제를 해결할 수 있으며 그 이후로는 보지 못했습니다.

이 문제에 대한 세부 정보가 내가 본 것과 일치한다는 점을 감안할 때 (rabbitmq를 redis로 교체하면 문제가 해결되고 명확한 시작점이 없으며 동시에 두 개 이상의 작업자 / 서버에서 발생 함) 공통 트리거가있을 수 있으며 내가 본 것과 똑같아.

테스트 스위트는 https://github.com/celery/celery/tree/master/funtests/stress 에서 https://github.com/celery/cyanide 로 변경되었으며 Python2 만 지원합니다.

그래서 Rabbitmq를 브로커로 사용하여 Python2에서 실행합니다. !join: connection lost: error(104, 'Connection reset by peer') 모금했습니다. 메모리 누수 문제와 관련이 있습니까?

다음은 테스트 스위트에 대한 로그입니다.

➜  cyanide git:(master) pipenv run python -m cyanide.bin.cyanide
Loading .env environment variables…
Cyanide v1.3.0 [celery 4.2.0 (windowlicker)]

Linux-4.13.0-45-generic-x86_64-with-debian-stretch-sid

[config]
.> app:    cyanide:0x7fb097f31710
.> broker: amqp://**:**@**:**/cyanide
.> suite: cyanide.suites.default:Default

[toc: 12 tests total]
.> 1) manyshort,
.> 2) always_timeout,
.> 3) termbysig,
.> 4) timelimits,
.> 5) timelimits_soft,
.> 6) alwayskilled,
.> 7) alwaysexits,
.> 8) bigtasksbigvalue,
.> 9) bigtasks,
.> 10) smalltasks,
.> 11) revoketermfast,
.> 12) revoketermslow

+enable worker task events...
+suite start (repetition 1)
[[[manyshort(50)]]]
 1: manyshort                            OK (1/50) rep#1 runtime: 15.00 seconds/15.01 seconds
 1: manyshort                            OK (2/50) rep#1 runtime: 13.16 seconds/28.17 seconds
 1: manyshort                            OK (3/50) rep#1 runtime: 13.29 seconds/41.46 seconds
 1: manyshort                            OK (4/50) rep#1 runtime: 13.70 seconds/55.16 seconds
 1: manyshort                            OK (5/50) rep#1 runtime: 13.77 seconds/1.15 minutes
 1: manyshort                            OK (6/50) rep#1 runtime: 13.91 seconds/1.38 minutes
!join: connection lost: error(104, 'Connection reset by peer')
!Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!Still waiting for 475/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!Still waiting for 475/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',)
!join: connection lost: error(104, 'Connection reset by peer')
failed after 7 iterations in 3.12 minutes
Traceback (most recent call last):
  File "/home/***/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/***/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/***/Documents/Python-Dev/cyanide/cyanide/bin/cyanide.py", line 62, in <module>
    main()
  File "/home/***/Documents/Python-Dev/cyanide/cyanide/bin/cyanide.py", line 58, in main
    return cyanide().execute_from_commandline(argv=argv)
  File "/home/***/.local/share/virtualenvs/cyanide-Vy3PQPTU/lib/python2.7/site-packages/celery/bin/base.py", line 275, in execute_from_commandline
    return self.handle_argv(self.prog_name, argv[1:])
  File "/home/***/.local/share/virtualenvs/cyanide-Vy3PQPTU/lib/python2.7/site-packages/celery/bin/base.py", line 363, in handle_argv
    return self(*args, **options)
  File "/home/***/.local/share/virtualenvs/cyanide-Vy3PQPTU/lib/python2.7/site-packages/celery/bin/base.py", line 238, in __call__
    ret = self.run(*args, **kwargs)
  File "/home/***/Documents/Python-Dev/cyanide/cyanide/bin/cyanide.py", line 20, in run
    return self.run_suite(names, **options)
  File "/home/***/Documents/Python-Dev/cyanide/cyanide/bin/cyanide.py", line 30, in run_suite
    ).run(names, **options)
  File "cyanide/suite.py", line 366, in run
    self.runtest(test, iterations, j + 1, i + 1)
  File "cyanide/suite.py", line 426, in runtest
    self.execute_test(fun)
  File "cyanide/suite.py", line 447, in execute_test
    fun()
  File "cyanide/suites/default.py", line 22, in manyshort
    timeout=10, propagate=True)
  File "cyanide/suite.py", line 246, in join
    raise self.TaskPredicate('Test failed: Missing task results')
cyanide.suite.StopSuite: Test failed: Missing task results

다음은 작업자 로그입니다.

➜  cyanide git:(master) pipenv run celery -A cyanide worker -c 1
Loading .env environment variables…

 -------------- celery@** v4.2.0 (windowlicker)
---- **** ----- 
--- * ***  * -- Linux-4.13.0-45-generic-x86_64-with-debian-stretch-sid 2018-07-03 12:59:28
-- * - **** --- 
- ** ---------- [config]
- ** ---------- .> app:         cyanide:0x7fdc988b4e90
- ** ---------- .> transport:   amqp://**:**@**:**/cyanide
- ** ---------- .> results:     rpc://
- *** --- * --- .> concurrency: 1 (prefork)
-- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
--- ***** ----- 
 -------------- [queues]
                .> c.stress         exchange=c.stress(direct) key=c.stress


[2018-07-03 12:59:29,883: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [e6e71bed-8e58-4e7e-96c5-f56b583a37af, 42fd4f97-4ff5-4e0e-b874-89e7b3f0ff22, 3de45eeb-9b89-41bc-8284-95a4c07aa34a,...]: TimeoutError('The operation timed out.',) !
[2018-07-03 12:59:29,886: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [e6e71bed-8e58-4e7e-96c5-f56b583a37af, 42fd4f97-4ff5-4e0e-b874-89e7b3f0ff22, 3de45eeb-9b89-41bc-8284-95a4c07aa34a,...]: TimeoutError('The operation timed out.',) !
[2018-07-03 12:59:30,964: WARNING/ForkPoolWorker-1] + suite start (repetition 1) +
[2018-07-03 12:59:30,975: WARNING/ForkPoolWorker-1] ---  1: manyshort                             (0/50) rep#1 runtime: 0.0000/0.0000 ---
[2018-07-03 13:01:07,835: WARNING/ForkPoolWorker-1] ! join: connection lost: error(104, 'Connection reset by peer') !
[2018-07-03 13:01:17,918: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:01:27,951: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:01:38,902: WARNING/ForkPoolWorker-1] ! Still waiting for 475/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:01:48,934: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:01:58,961: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:02:09,906: WARNING/ForkPoolWorker-1] ! Still waiting for 475/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:02:19,934: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:02:29,964: WARNING/ForkPoolWorker-1] ! Still waiting for 1000/1000: [1624cd7a-3cc0-474a-b957-b0484f6b4937, 2b436525-73de-4062-bd6b-924cbd11ba74, ce04cb5e-a99e-41e2-95dc-e9bc351e606d,...]: TimeoutError(u'The operation timed out.',) !
[2018-07-03 13:02:37,900: WARNING/ForkPoolWorker-1] ! join: connection lost: error(104, 'Connection reset by peer') !

동일한 스트레스 테스트 스위트와 함께 셀러리 3.1.25를 사용하도록 업데이트했습니다. 모든 것이 정상입니다.

BTW 빠른 수정을 찾고있는 모든 사람을 위해- @jxltom이 제안한대로 rabbit을 redis로 교체하면 문제가 해결됩니다.
그래서 문제는 확실히 토끼 셀러리 테두리 근처에 있습니다.

@dieeasy 우리는 같은 문제를 경험했습니다. RPC 결과 백엔드를 사용하고 있다고 가정합니다. 그렇다면 DB 결과 백엔드로 전환하고 도움이되는지 확인하십시오. 이 문제를 일으키는 문제는 https://github.com/celery/kombu/pull/779 이며 여기에 설명되어 있습니다 : https://github.com/celery/kombu/pull/779#discussion_r134961611

동일한 문제 메모리 누수가 있습니다.
기억

버전
python 3.6.5 셀러리 4.2.1 백엔드 redis 브로커 rabbitmq

구성

[celery]
broker_url=amqp://taunt:[email protected]:5672/%2ftaunt
celery_result_backend=redis://xx.xx.xx.xx:6379
# 7days
celery_task_result_expires=604800
celery_task_serializer=msgpack
celery_result_serializer=json
celery_accept_content=json,msgpack
celery_timezone=Asia/Shanghai
celery_enable_utc=True

[cmd]
worker=True
proj=app.worker.celery
log_level=INFO
name=send_im%%h
queue=im
autoscale=10,3
concurrency=10

```파이썬

-- 코딩 : utf-8--

다시마 수입 대기열, 교환에서
oslo_log에서 로그를 로깅으로 가져 오기

app.conf에서 CONF 가져 오기

로그 = logging.getLogger (__ name__)

celery_queues = (
큐 ( 'im', exchange = Exchange ( 'sender'), routing_key = 'im'),
큐 ( 'sms', exchange = Exchange ( 'sender'), routing_key = 'sms'),
Queue ( 'mail', exchange = Exchange ( 'sender'), routing_key = 'mail'),
큐 ( 'ivr', exchange = Exchange ( 'sender'), routing_key = 'ivr')
)

celery_routes = {
'sender.im': { 'queue': 'im', 'routing_key': 'im'},
'sender.sms': { 'queue': 'sms', 'routing_key': 'sms'},
'sender.mail': { 'queue': 'mail', 'routing_key': 'mail'},
'sender.ivr': { 'queue': 'ivr', 'routing_key': 'ivr'}
}

구성 = {
'BROKER_URL': CONF.celery.broker_url,
'CELERY_RESULT_BACKEND': CONF.celery.celery_result_backend,
'CELERY_TASK_RESULT_EXPIRES': CONF.celery.celery_task_result_expires,
'CELERY_TASK_SERIALIZER': CONF.celery.celery_task_serializer,
'CELERY_RESULT_SERIALIZER': CONF.celery.celery_result_serializer,
'CELERY_ACCEPT_CONTENT': CONF.celery.celery_accept_content.split ( ','),
'CELERY_TIMEZONE': CONF.celery.celery_timezone,
'CELERY_ENABLE_UTC': CONF.celery.celery_enable_utc,
'CELERY_QUEUES': celery_queues,
'CELERY_ROUTES': celery_routes
}

**Startup**
```python

def make_command() -> list:
    log_path = f'{CONF.log_dir}{os.sep}{CONF.log_file}'
    command_name = f'{sys.path[0]}{os.sep}celery'
    command = [command_name, 'worker', '-A', CONF.cmd.proj, '-E']
    if CONF.cmd.log_level:
        command.extend(['-l', CONF.cmd.log_level])
    if CONF.cmd.queue:
        command.extend(['-Q', CONF.cmd.queue])
    if CONF.cmd.name:
        command.extend(['-n', CONF.cmd.name])
    # if CONF.cmd.autoscale:
    #     command.extend(['--autoscale', CONF.cmd.autoscale])
    if CONF.cmd.concurrency:
        command.extend(['--concurrency', CONF.cmd.concurrency])
    command.extend(['-f', log_path]) 
    return command


if CONF.cmd.worker:
    LOG.info(make_command())
    entrypoint = celery.start(argv=make_command())

필요한 경우 더 많은 정보를 제공 할 수 있습니다.

그만한 가치는이 문제가 있으며 rabbitmq 관리 콘솔을 열고 연결로 이동하고 셀러리에서 rabbitmq 로의 트래픽 연결을 닫음으로써 일관되게 재현 할 수 있습니다.

셀러리 4.1 및 4.2 및 rabbitmq 3.7.7-1로 테스트했습니다.
편집 : 또한 Python 버전 3.6.5 및 우분투 16.04 (AWS EC2 이미지)

셀러리 4.2.1 및 redis 브로커에서 메모리 누수가 발생합니다. 메모리는 3 시간 만에 100MiB에서 500MiB (제한)로 증가하고 작업자는 꽃에서 오프라인으로 표시됩니다. prefork pool과 gevent는 모두 동일한 문제를 보여줍니다.

@yifeikong 이것은 동일한 문제가 아닐 수 있지만 귀하의 경우 https://github.com/celery/celery/pull/4839#issuecomment -447739820 제안 된 솔루션을 시도해 주시겠습니까?

@georgepsarakis 저는 Python 3.6.5를 사용하고

# 5047 과 동일한 원인 일 수 있습니다.이 버그는 다른 현상으로 이어질 수 있습니다.

우리는 RabbitMQ를 브로커로 사용하여 Celery 4.2.1, Kombu 4.2.2 및 python3.6을 실행하는 동일한 메모리 누수에 직면하고 있습니다.

$ celery --app=eventr.celery_app report

software -> celery:4.2.1 (windowlicker) kombu:4.2.2-post1 py:3.6.8
            billiard:3.5.0.5 py-amqp:2.4.0
platform -> system:Linux arch:64bit imp:CPython

다른 사람들이 가능한 해결 방법 (브로커로서 redis, jemalloc, libamqp 사용, __del__ 에서 monkey path AsyncResult 말할 수 있습니다.

로그를 분석하여 가십에서 놓친 하트 비트와 관련된 많은 메시지가 있음을 발견했습니다.

{"asctime": "2019-01-25 13:40:06,486", "levelname": "INFO", "name": "celery.worker.consumer.gossip", "funcName": "on_node_lost", "lineno": 147, "message": "missed heartbeat from celery@******"}

마지막으로 시도한 것은 --without-gossip 작업자를 실행하여 가십을 비활성화하는 것이 었습니다. 놀랍게도 가십을 비활성화하면 즉각적인 효과가있었습니다.

여기에서 볼 수 있습니다.

셀러리 작업자를 실행하는 두 프로젝트에서 가십을 비활성화했기 때문에 메모리 소비가 개선되었습니다.

주의를 기울이면 여기에 설명 된 것과 유사한 메모리 스파이크가 발생하기 전에 https://github.com/celery/celery/issues/4843#issuecomment -399833781

내가 완전히 이해하려고 노력한 한 가지는 가십을 완전히 비활성화하는 것의 의미가 무엇인지입니다. 험담은 작업자 <-> 작업자 의사 소통으로 만 설명되기 때문입니다. 누군가 이에 대해 밝힐 수 있다면 매우 감사 할 것입니다.

이것이 도움이되기를 바라며 노력에 감사드립니다.

이 문제가 종결 된 이유는 무엇입니까?

이 문제에 대한 적극적인 피드백과 관심이 있으므로 다시 시작하겠습니다.

글쎄, @georgepsarakis 는 내 유출이 # 4839가 아니라고 진단했고 당신은 그것이 # 4843이라고 의심 했기 때문에 적어도 지금은이 유출 스레드로 넘어갈 것입니다. # 4843도 내 유출인지 잘 모르겠습니다. 이 스레드의 초기 문제에 따르면 :

이 문제는 적어도 Celery 4.1에서 발생하며 Celery 4.2에서도 발생합니다.
Celery는 Ubuntu 16에서 실행되고 브로커는 RabbitMQ를 사용합니다.

나는 현재 :

파이썬 2.7.12
Ubuntu 16.04.1 amd64
RabbitMQ 3.7.5

사용 :

셀러리 4.1.1
librabbitmq 2.0.0
amqp 2.4.0
포도 나무 1.1.4
당구 3.5.0.5
다시마 4.2.2.post1
gevent 1.2.2

그러나 Celery 4.1.1 + gevent 1.2.2는 나에게 누출되지 않습니다 (Celery 3.1.25 + gevent 1.2.2 AFAICT도 마찬가지입니다). Celery 4.2.1 + gevent 1.3.7은 그렇습니다. 안타깝게도 gevent 1.3.7과 gevent 1.2.2는 문제의 가능한 원인으로 gevent 라이브러리를 설명 (또는 제외)하기 위해 상호 교환 할 수 없습니다.

편집 : 흠 ... 제가 발생한 오류를 수정할 수있는 것처럼 보이는 gevent 패치 (022f447dd)가있는 것 같습니다. 나는 그것을 작동 시키려고 노력할 것이다.

Celery 4.1.1에 022f447을 적용하고 gevent 1.3.7을 설치했습니다. 그 Celery + gevent 조합이 실행되고 ... 내가 경험 한 누수와 일치하는 메모리 사용 패턴을 생성했습니다. Celery 4.2.1 + gevent 1.2.2 (역 패치 포함)를 설치하고 일반적인 메모리 사용 패턴이 나타나는지 확인합니다.

gevent 1.4.0이 나왔습니다. 그게 어떻게 작동하는지보기 위해 소용돌이를 줘야 할 것 같습니다.

Celery 4.2.1 + gevent 1.2.2 + gevent 1.2.2의 리버스 패치는 Celery 4.2.1 + gevent 1.3.7처럼 누출을 일으키지 않는 것 같습니다.

Celery 4.2.1 + gevent 1.4.0은 gevent 1.3.7 AFAICT와 거의 같은 비율로 누출되는 것 같습니다.

https://github.com/celery/celery/blob/9f0a554dc2d28c630caf9d192873d040043b7346/celery/events/dispatcher.py

    def _publish(self, event, producer, routing_key, retry=False,
                 retry_policy=None, utcoffset=utcoffset):
        exchange = self.exchange
        try:
            producer.publish(...)
        except Exception as exc:  # pylint: disable=broad-except
            if not self.buffer_while_offline:  # <-- False by default
                raise
            self._outbound_buffer.append((event, routing_key, exc))  # <---- Always buffered

    def send(self, type, blind=False, utcoffset=utcoffset, retry=False,
            ...
            if group in self.buffer_group:   # <--- Never true for eventlet & gevent
                ...
                if len(buf) >= self.buffer_limit:
                    self.flush()     #  <---- Never flushed even when grows above limit
                ...
            else:
                return self.publish(type, fields, self.producer, blind=blind,
                                    Event=Event, retry=retry,

https://github.com/celery/celery/blob/b2668607c909c61becd151905b4525190c19ff4a/celery/worker/consumer/events.py

    def start(self, c):
        # flush events sent while connection was down.
        prev = self._close(c)
        dis = c.event_dispatcher = c.app.events.Dispatcher(
            ...
            # we currently only buffer events when the event loop is enabled
            # XXX This excludes eventlet/gevent, which should actually buffer.
            buffer_group=['task'] if c.hub else None,
            on_send_buffered=c.on_send_event_buffered if c.hub else None,
        )
        if prev:
            dis.extend_buffer(prev)
            dis.flush()    # <---- The only (!) chance to flush on [g]event[let] is on reconnect.

이제 AMQP가 내부에서 수행하는 작업을 올바르게 이해하면 자체 심장 박동이 있고 끊어진 연결을 감지하면 내부에서 다시 연결됩니다. 활성화 된 이벤트 유형 (가십, 하트 비트)에 따라 매우 빠르게 누출 될 수 있습니다.
이것은 eventlet 및 gevent의 모든 버전에 해당되지만 일부는 상황을 악화 / 더 눈에 띄게 만드는 연결 문제를 나타낼 수 있습니다.

안녕하세요,

나는 우리가 같은 문제를 겪고 있다고 생각합니다.
우리의 구성은 다음과 같습니다. 여기에서 논의한 것과 동일한 문제임을 부정하거나 확인할 수 있습니까?

파이썬 : 2.7
셀러리 : 4.2.1
OS : CentOS 릴리스 6.10
브로커로서의 Redis

첨부 된 이미지에서 다음을 볼 수 있습니다.

1. 메모리 소비는 지속적으로 증가하고 재시작시 감소합니다.
2. 1 월 13 일-셀러리 3.1.25에서 4.2.1로 업그레이드했습니다. 메모리 소비 증가 속도가 증가합니다.

최신 정보

이 문제에 관계없이 우리는 파이썬 3.6으로 업그레이드했고 그 이후로 누수가 더 이상 발생하지 않는 것처럼 보입니다.

(업그레이드는 2 월 19 일에있었습니다)

안녕하세요.

이것이 얼마나 관련이 있는지 확실하지 않지만 생산 과정에서 셀러리로 인해 2GB의 SWAP 공간이 소모됩니다. 꽃을 막는 것은 기억을 지우지 않았지만 셀러리는 그만 두었다.

누구나 셀러리 4.3rc1을 사용해 볼 수 있습니까?

@auvipy Celery 4.3.0rc1 + gevent 1.4.0을 설치했습니다. pip는 당구를 3.6.0.0 및 kombu 4.3.0으로 업그레이드했습니다.

그 업그레이드로 # 4839가 수정 되었기 때문에 rc1 패키지에서도 vine 1.2.0이 필요하지 않다는 사실에 의아해합니다.

어쨌든 Celery 4.3.0 rc1은 정상적으로 실행되는 것 같습니다.

@ ldav1s 피드백에 감사드립니다. 따라서 vine은 실제로 py-amqp 에서 종속성으로 선언됩니다. 새 설치에서는 최신 vine 버전이 설치되지만 기존 버전에서는 발생하지 않을 수 있습니다.

@thedrow 아마도 우리는 Celery 요구 사항에서도 종속성을 선언해야할까요?

그것에 대한 문제를 열고 거기에서 논의합시다.

Celery 4.3.0rc1 + gevent 1.4.0이 며칠간 실행되었습니다. Celery 4.2.1 + gevent 1.4.0과 같은 방식으로 유출되는 것 같습니다.

celery 4.2.1, python 3.6에서 동일한 누출이 있음

이것에 대한 업데이트가 있습니까?

여기에 같은 문제가

인사말,

비슷한 문제가 발생하지만 동일한 지 잘 모르겠습니다.

다른 환경 / 네트워크에서 셀러리 앱을 마이그레이션 한 후 셀러리 작업자가 유출되기 시작했습니다. 이전에는 셀러리 애플리케이션과 rabbitmq 인스턴스가 동일한 환경 / 네트워크에있었습니다.

내 구성은 Python 3.6.5에 있습니다.

amqp (2.4.2)
billiard (3.5.0.5)
celery (4.1.1)
eventlet (0.22.0)
greenlet (0.4.15)
kombu (4.2.1)
vine (1.3.0)

셀러리

broker_url = rabbitmq
result_backend = mongodb
task_acks_late = True
result_expires = 0
task_default_rate_limit = 2000
task_soft_time_limit = 120
task_reject_on_worker_lost = True
loglevel = 'INFO'
worker_pool_restarts = True
broker_heartbeat = 0
broker_pool_limit = None

애플리케이션은 supervisord의 명령을 통해 시작되는 eventlet 풀이있는 여러 작업자로 구성됩니다.

[program:worker1]
command={{ celery_path }} worker -A celery_app --workdir {{ env_path }} -l info -E -P eventlet -c 250 -n worker1@{{ hostname }} -Q queue1,queue2

메모리 누수 동작은 대략 10 시간마다 일반적으로 작업자 1 명, 최대 2 명이 누수를 시작합니다.

그래서 각 작업자에서 실행되는 브로드 캐스트 메시지를 만들었습니다. tracemalloc을 사용하기 위해 이것은 컴퓨터의 top 명령의 결과입니다. 1 명의 작업자가 1464m로만 누출됩니다.

217m   1%   2   0% /usr/bin/python3 -m celery worker -A celery_app --workdir   379
189m   1%   0   0% /usr/bin/python3 -m celery worker -A celery_app --workdir   377     
1464m   9%   1   0% /usr/bin/python3 -m celery worker -A celery_app --workdir   378
218m   1%   0   0% /usr/bin/python3 -m celery worker -A celery_app --workdir   376 
217m   1%   2   0% /usr/bin/python3 -m celery worker -A celery_app --workdir   375
217m   1%   3   0% /usr/bin/python3 -m celery worker -A celery_app --workdir   394
163m   1%   0   0% /usr/bin/python3 -m celery beat -A celery_app --workdir /app

누수 작업자에 대한 tracemalloc TOP 10 결과

[2019-03-29 07:18:03,809: WARNING/MainProcess] [ Top 10: worker5<strong i="6">@hostname</strong> ]

[2019-03-29 07:18:03,809: WARNING/MainProcess] /usr/lib/python3.6/site-packages/eventlet/greenio/base.py:207: size=17.7 MiB, count=26389, average=702 B

[2019-03-29 07:18:03,810: WARNING/MainProcess] /usr/lib/python3.6/site-packages/kombu/messaging.py:203: size=16.3 MiB, count=44422, average=385 B

[2019-03-29 07:18:03,811: WARNING/MainProcess] /usr/lib/python3.6/site-packages/celery/worker/heartbeat.py:49: size=15.7 MiB, count=39431, average=418 B

[2019-03-29 07:18:03,812: WARNING/MainProcess] /usr/lib/python3.6/site-packages/celery/events/dispatcher.py:156: size=13.0 MiB, count=40760, average=334 B

[2019-03-29 07:18:03,812: WARNING/MainProcess] /usr/lib/python3.6/site-packages/eventlet/greenio/base.py:363: size=12.9 MiB, count=19507, average=695 B

[2019-03-29 07:18:03,813: WARNING/MainProcess] /usr/lib/python3.6/site-packages/amqp/transport.py:256: size=12.7 MiB, count=40443, average=328 B

[2019-03-29 07:18:03,814: WARNING/MainProcess] /usr/lib/python3.6/site-packages/celery/events/dispatcher.py:138: size=12.4 MiB, count=24189, average=539 B

[2019-03-29 07:18:03,814: WARNING/MainProcess] /usr/lib/python3.6/site-packages/amqp/transport.py:256: size=12.3 MiB, count=19771, average=655 B

[2019-03-29 07:18:03,815: WARNING/MainProcess] /usr/lib/python3.6/site-packages/amqp/connection.py:505: size=11.9 MiB, count=39514, average=317 B

[2019-03-29 07:18:03,816: WARNING/MainProcess] /usr/lib/python3.6/site-packages/kombu/messaging.py:181: size=11.8 MiB, count=61362, average=201 B

25 프레임의 TOP 1

TOP 1

[2019-03-29 07:33:05,787: WARNING/MainProcess] [ TOP 1: worker5<strong i="10">@hostname</strong> ]

[2019-03-29 07:33:05,787: WARNING/MainProcess] 26938 memory blocks: 18457.2 KiB

[2019-03-29 07:33:05,788: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/eventlet/greenio/base.py", line 207

[2019-03-29 07:33:05,788: WARNING/MainProcess] mark_as_closed=self._mark_as_closed)

[2019-03-29 07:33:05,789: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/eventlet/greenio/base.py", line 328

[2019-03-29 07:33:05,789: WARNING/MainProcess] timeout_exc=socket_timeout('timed out'))

[2019-03-29 07:33:05,790: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/eventlet/greenio/base.py", line 357

[2019-03-29 07:33:05,790: WARNING/MainProcess] self._read_trampoline()

[2019-03-29 07:33:05,790: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/eventlet/greenio/base.py", line 363

[2019-03-29 07:33:05,791: WARNING/MainProcess] return self._recv_loop(self.fd.recv, b'', bufsize, flags)

[2019-03-29 07:33:05,791: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/amqp/transport.py", line 440

[2019-03-29 07:33:05,791: WARNING/MainProcess] s = recv(n - len(rbuf))

[2019-03-29 07:33:05,792: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/amqp/transport.py", line 256

[2019-03-29 07:33:05,792: WARNING/MainProcess] frame_header = read(7, True)

[2019-03-29 07:33:05,792: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/amqp/connection.py", line 505

[2019-03-29 07:33:05,793: WARNING/MainProcess] frame = self.transport.read_frame()

[2019-03-29 07:33:05,793: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/amqp/connection.py", line 500

[2019-03-29 07:33:05,793: WARNING/MainProcess] while not self.blocking_read(timeout):

[2019-03-29 07:33:05,793: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/kombu/transport/pyamqp.py", line 103

[2019-03-29 07:33:05,794: WARNING/MainProcess] return connection.drain_events(**kwargs)

[2019-03-29 07:33:05,794: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/kombu/connection.py", line 301

[2019-03-29 07:33:05,794: WARNING/MainProcess] return self.transport.drain_events(self.connection, **kwargs)

[2019-03-29 07:33:05,795: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/worker/pidbox.py", line 120

[2019-03-29 07:33:05,795: WARNING/MainProcess] connection.drain_events(timeout=1.0)

도움이 되었으면 좋겠습니다. 로그에 작업자 간 하트 비트를 놓친 것 외에는 오류가 없습니다. 이제 이전 환경을 사용하고 있던 libs의 정확한 버전을 사용하려고합니다.

업데이트 : 동일한 정확한 종속성 lib 버전과 5 분마다 브로커 하트 비트를 사용하면 애플리케이션이 다시 유출 된 것보다 2 일 이상 더 오랜 시간 동안 안정적으로 보였습니다.

시간별로 약 1 시간 동안 계속되는 작은 스파이크가 있었지만 "흡수 / 수집"되었습니다 .. 마지막 하나가 스파이크를 시작한 것처럼 보입니다.

첫 번째 스파이크, 첫 번째 램프 이후, 나는 새는 작업자를 다시 시작했습니다. 다른 작업자가 그 후에 새기 시작했거나 아마도 이미 새는 것, 두 번째 램프를 볼 수 있습니다.

심장 박동없이 테스트하겠습니다.

업데이트 : 2 일 후 다시 하트 비트가 유출되지 않고 동일한 동작

440m   3%   1   0% /usr/bin/python3 -m celery worker -A celery_app --without-heartbeat --workdir /app -l info -E -P eventlet -c 250 -Ofair -n worker1@ -Q p_1_queue,p_2_queue
176m   1%   0   0% /usr/bin/python3 -m celery worker -A celery_app --without-heartbeat --workdir /app -l info -E -P eventlet -c 250 -Ofair -n worker2@ -Q p_1_queue,p_2_queue
176m   1%   2   0% /usr/bin/python3 -m celery worker -A celery_app --without-heartbeat --workdir /app -l info -E -P eventlet -c 250 -Ofair -n worker5@ -Q p_1_queue,p_2_queue
176m   1%   1   0% /usr/bin/python3 -m celery worker -A celery_app --without-heartbeat --workdir /app -l info -E -P eventlet -c 250 -Ofair -n worker3@ -Q p_1_queue,p_2_queue
176m   1%   1   0% /usr/bin/python3 -m celery worker -A celery_app --without-heartbeat --workdir /app -l info -E -P eventlet -c 250 -Ofair -n worker4@ -Q p_1_queue,p_2_queue
171m   1%   1   0% /usr/bin/python3 -m celery worker -A celery_app --without-heartbeat --workdir /app -l info -E -P eventlet -c 20 -n worker_p_root@ -Q p_root_queue
157m   1%   0   0% /usr/bin/python3 -m celery beat -A celery_app --workdir /app --schedule /app/beat.db -l info

최신 정보:
셀러리 4.3.0을 사용하면 문제가 해결 된 것 같고 일주일 이후로 안정적입니다.

amqp (2.4.2)
billiard (3.6.0.0)
celery (4.3.0)
eventlet (0.24.1)
greenlet (0.4.15)
kombu (4.5.0)
vine (1.3.0)

어떻게 든 코드를 계측하는 데 도움이 될 수 있는지 알려주세요. 필요한 경우 링크와 예제를 제공하십시오.

감사합니다

또한 메모리 누수가 있습니다. 원인을 찾은 것 같습니다.
https://github.com/celery/celery/blob/master/celery/events/dispatcher.py#L75
토끼와의 연결 문제 이후에이 버퍼가 커지기 시작하는 것을 볼 수 있습니다. 나는 그것이 결국 이벤트를 지우지 못하는 이유를 이해하지 못하며 시간이 지남에 따라 계속 성장하고 점점 더 많은 숫양을 소비합니다. buffer_while_offline=False 여기 https://github.com/celery/celery/blob/master/celery/worker/consumer/events.py#L43을 전달하면 누수가 해결되는 것 같습니다. 누군가 이것이 관련이 있는지 확인할 수 있습니까?

https://github.com/celery/celery/pull/5482

@ yevhen-m 감사합니다! 그것은 우리가 메모리 누수를 해결하는 데 도움이되었습니다!

해결 방법이 있다는 것이 좋지만 적절한 해결 방법을 찾을 수 있습니까?

연속이 메모리 누수 문제를 따르십시오.

프로덕션 환경에서 셀러리를 사용하고 있으며 도커를 통해 배포하고 있습니다.
스크린 샷과 마찬가지로 동일한 문제가 발생합니다.
프로덕션 구성은 다음과 같습니다.

Docker 상위 이미지 : python 3.6.8-buster
셀러리 버전 : 4.2.0
명령 옵션 :

• 동시성 4
• 프리 페치 승수 8
• 결과 _ 백엔드 없음
• acks_late 및 reject_on_worker_lost

셀러리 버전을 4.3.0으로 업그레이드하면 메모리 누수 문제가 해결되는지 궁금합니다.

감사합니다!

셀러리 4.4.0은 최신 안정 버전입니다.

팀,이 문제에 대한 업데이트가 있습니까? 셀러리 4.4.0에서이 문제가 해결되고 수정 되었습니까?

팀,이 문제에 대한 업데이트가 있습니까? 셀러리 4.4.0에서이 문제가 해결되고 수정 되었습니까?

불행하게도. 이제 해결되었습니다.

팀,이 문제에 대한 업데이트가 있습니까? 셀러리 4.4.0에서이 문제가 해결되고 수정 되었습니까?

4.4.1에서 사용할 수 있습니다.

4.4.1에서 사용할 수 있습니다.

현재 버전 4.4.1에서 수정 되었습니까?

@auvipy 문제는 여전히 Celery 4.4.2 및 4.4.6에 있습니다. 모든 작업자에서 동일한 메모리 누수가 발생합니다.

BROKER_POOL_LIMIT = None
CELERY_ACKS_LATE = False
CELERY_TRACK_STARTED = True
CELERYD_MAX_TASKS_PER_CHILD = 1
CELERYD_PREFETCH_MULTIPLIER = 1
BROKER_TRANSPORT_OPTIONS = {
    'fanout_prefix': True,
    'fanout_patterns': True,
    'visibility_timeout': 43200,
    'health_check_interval': 180,
    'socket_keepalive': True,
    'retry_on_timeout': True,
}

셀러리 작업자는 -O fair --without-heartbeat --without-gossip -c 1 -l 플래그로 시작됩니다. 또한 -n 및 -Q 플래그를 사용하여 작업자 이름과 대기열을 설정합니다. 프리 포크 모드에서 실행 중입니다. Redis는 브로커 및 결과 저장소 모두로 구성됩니다.

~ 장기 실행 작업에서 누락 된 하트 비트가 많이 있습니다. 따라서 링크 된 이슈에보고 된 문제는 여전히 지속됩니다. ~

비활성화 된 심장 박동도 마찬가지입니다.

@jsynowiec 이 문제에 직면했을 때 저에게 도움이 된 유일한 것은 가십이 비활성화 된 작업자를 운영하는 것이 었습니다. https://github.com/celery/celery/issues/4843#issuecomment -459789086

celery 4.4.2 및 redis에서 브로커로 동일한 문제가 발생합니다. 48 시간 동안 셀러리는 메모리가 부족해질 때까지 최대 60GB의 RAM을 소비합니다.
여기에 명명 된 솔루션 중 어느 것도이 동작에 영향을 미치지 않았습니다.

celery 4.4.2 및 redis에서 브로커로 동일한 문제가 발생합니다. 48 시간 동안 셀러리는 메모리가 부족해질 때까지 최대 60GB의 RAM을 소비합니다.
여기에 명명 된 솔루션 중 어느 것도이 동작에 영향을 미치지 않았습니다.

최신 패치 버전을 사용해 보셨습니까?
OP와 같은 조건이 있습니까?

v4.4.6에서 여전히 메모리 누수가 존재합니다. 이전 의견에 나열된 설정으로 작업자를 실행합니다. OP는 RabbitMQ를 사용하고 Redis를 브로커로 사용합니다.

+1, 최소한의 작업을 수행하더라도 24 시간에 걸쳐 메모리 사용량이 점진적으로 증가합니다. 이 문제를 다시 열어야한다고 생각합니다.

메모리 누수의 원인을 프로파일 링하고 찾을 수 있습니까?

v4.4.6에서 여전히 메모리 누수가 존재합니다. 이전 의견에 나열된 설정으로 작업자를 실행합니다. OP는 RabbitMQ를 사용하고 Redis를 브로커로 사용합니다.

다른 문제이거나 수정 사항이 올바르지 않은 것 같습니다.
이것이 OP의 문제를 해결했기 때문에 아마도 다른 문제 일 것입니다.

[2020-07-31 10:51:53,176: WARNING/MainProcess] /usr/local/lib/python3.8/site-packages/redis/client.py:90: size=19.2 KiB (+19.2 KiB), count=180 (+180), average=109 B
[2020-07-31 10:53:53,271: WARNING/MainProcess] /usr/local/lib/python3.8/site-packages/redis/client.py:90: size=230 KiB (+211 KiB), count=2160 (+1980), average=109 B
[2020-07-31 10:54:53,364: WARNING/MainProcess] /usr/local/lib/python3.8/site-packages/redis/client.py:90: size=250 KiB (+19.2 KiB), count=2340 (+180), average=109 B

....

[2020-07-31 12:24:10,633: WARNING/MainProcess] /usr/local/lib/python3.8/site-packages/redis/client.py:90: size=49.9 MiB (+76.8 KiB), count=478620 (+720), average=109 B
[2020-07-31 12:25:14,528: WARNING/MainProcess] /usr/local/lib/python3.8/site-packages/redis/client.py:90: size=49.9 MiB (+19.2 KiB), count=478800 (+180), average=109 B
[2020-07-31 12:27:22,346: WARNING/MainProcess] /usr/local/lib/python3.8/site-packages/redis/client.py:90: size=49.9 MiB (+57.6 KiB), count=479340 (+540), average=109 B
[2020-07-31 12:28:26,265: WARNING/MainProcess] /usr/local/lib/python3.8/site-packages/redis/client.py:90: size=50.2 MiB (+269 KiB), count=481860 (+2520), average=109 B

CELERY_RESULT_BACKEND = False CELERY_IGNORE_RESULT = True CELERY_MAX_TASKS_PER_CHILD = 1 CELERY_WORKER_PREFETCH_MULTIPLIER = 1 CELERY_TASK_RESULT_EXPIRES = 10 CELERY_BROKER_POOL_LIMIT = 70 CELERY_REDIS_MAX_CONNECTIONS = 100
app.conf.broker_transport_options = {'visibility_timeout': 43200}

celery -A proj worker --concurrency=70 --prefetch-multiplier=1 -Ofair --pool=gevent -n --without-gossip --without-mingle

Redis 클라이언트에서 메모리 누수? 저는 celery v4.4.6을 gevent, redis를 브로커로 사용하고 결과 백엔드가 없습니다.

그것도 문제가 될 수 있습니다. 아마도 gevent에 있습니까?
CC @jamadden @andymccurdy
이 문제를 해결하고 메모리 누수가 발생하지 않도록 도와 주시겠습니까?

아마도 gevent에 있습니까?

gevent 사용하지 않습니다. 작업자는 concurrency = 1 및 prefork로 시작됩니다.

안녕하세요 여러분,이 문제가 왜 종결되었는지 확실하지 않습니다. 우리는 2 년 동안이 문제를 겪고 있으며 매번 셀러리의 마지막 버전으로 업데이트하고 있으며 여전히 큰 서버 (64-128GB RAM)의 RAM이 부족하기 때문입니다. 이 메모리 누수 문제의.

Celery 3로 다운 그레이드하거나 Rabbitmq를 교체하지 않고 해결 방법이 있습니까?

이로 인해 Celery는 프로덕션 환경에서 완전히 불안정합니다. 고칠 수 있기를 바랍니다. Celery 3로 다운 그레이드 할 수 없으므로 Celery가 전체 서버 RAM을 사용하는 것에 대해 걱정하지 않기 위해 다른 솔루션 (드라마틱)으로 이동할 계획입니다. 2 일마다 생산.

@arielcamino- 적어도 내 서버에 대해 메모리 사용량을 유지하는 데 도움이 된 100 ~ 작업 후 작업자 인스턴스를 대체하기 위해 worker_max_tasks_per_child 설정을 사용하고 있습니다. 나는 512MB의 작은 인스턴스를 실행하고 있으며 이것은 도움이되었으므로 (이전에는 내 램을 고갈 시켰습니다) 아마도 도움이 될 것입니다.

@Skowt 와우,

@arielcamino- 적어도 내 서버에 대해 메모리 사용량을 유지하는 데 도움이 된 100 ~ 작업 후 작업자 인스턴스를 대체하기 위해 worker_max_tasks_per_child 설정을 사용하고 있습니다. 나는 512MB의 작은 인스턴스를 실행하고 있으며 이것은 도움이되었으므로 (이전에는 내 램을 고갈 시켰습니다) 아마도 도움이 될 것입니다.

해결 방법을 공유해 주셔서 감사합니다. 이것은 여기에서 도움이되지 않았습니다-우리는 redis를 사용하고 있습니다.

@thedrow redis-py의 메모리 누수를 알지 못합니다. redis-py에 누출이있는 경우 누군가 Celery 환경 외부에서이를 발견하고 redis-py 문제 추적기에보고했을 것이라고 가정합니다.

내가 할 수있는 곳에서 도움을 줘서 기쁩니다 (여러 프로젝트에서 브로커로 Redis가있는 Celery를 사용합니다).하지만 배포시이 문제가 발생하지 않았습니다.

현재 버전의 gevent에서 메모리 누수가 발생하는 것을 알지 못합니다. 나는 누군가가 그것을 만났다면 누군가가 말했을 것이라고 생각합니다 (이전에 한두 번 일어났습니다). 현재 gevent 배포에는 gevent를 많이 사용하는 한 번에 몇 주 동안 여러 작업자 (웹 및 백그라운드)가 있으며 메모리 누수가 발생하지 않았습니다.

안녕하세요 여러분,이 문제가 왜 종결되었는지 확실하지 않습니다. 우리는 2 년 동안이 문제를 겪고 있으며 매번 셀러리의 마지막 버전으로 업데이트하고 있으며 여전히 큰 서버 (64-128GB RAM)의 RAM이 부족하기 때문입니다. 이 메모리 누수 문제의.

Celery 3로 다운 그레이드하거나 Rabbitmq를 교체하지 않고 해결 방법이 있습니까?

이로 인해 Celery는 프로덕션 환경에서 완전히 불안정합니다. 고칠 수 있기를 바랍니다. Celery 3로 다운 그레이드 할 수 없으므로 Celery가 전체 서버 RAM을 사용하는 것에 대해 걱정하지 않기 위해 다른 솔루션 (드라마틱)으로 이동할 계획입니다. 2 일마다 생산.

몇 명의 일꾼이 있습니까? 얼마나 많은 작업을 실행합니까? 이 작업을 얼마나 자주 실행하고 일반적으로 완료하는 데 얼마나 걸리나요?

Rabbitmq / celery가 많은 램을 사용하기 시작하는 이유는 대기열에있는 작업의 양과 관련이있을 수 있습니다. 너무 많은 작업을 대기열에 넣고 작업자가 작업을 모두 완료 할 수없는 경우 대기열이 커지고이 대기열은 점점 더 많은 RAM을 사용하고 결국 사용 가능한 모든 RAM을 소비하게됩니다. 이 문제는 Redis에서도 발생할 수 있다고 생각합니다.

나는 다른 이론이 있지만 먼저 이것이 당신의 문제의 원인인지 알고 싶습니다.

@ardilom 죄송합니다. 우리가 RabbitMQ 데이터를 datadog에 보내지 않는다는 사실을 깨달았지만 상황을 명확히하려고 노력할 것입니다. 이것은 일부 서버 RAM이 2 일마다 중단되는 방식입니다.

우리는 항상 보류중인 작업의 수를 확인하며 일반적으로 약 0입니다 (이 데이터는 며칠 전의 것입니다).

우리는 하루에 약 250,000 개의 작업을 실행하고 각각 약 4 ~ 10 개의 동시성을 가진 약 10 명의 작업자를 보유하고 있으며 평균 런타임은 약 5 초이며 작업의 종류에 따라 다릅니다.

대기중인 작업이 너무 많지 않은지 항상 messages_ready 를 확인 messages_ready 를 측정해도 괜찮다고 생각하십니까? 결국에는 약간의 피크가 있지만 일반적으로는 0에 가깝습니다.

문제를 해결하기 위해 Celery 작업자를 수동으로 다시 시작하면 RAM 사용량이 다시 정상화됩니다.

다른 것이 필요하면 알려주세요. 구성을 적용한 후 나머지 서버와 차이가 있는지 확인하기 위해 작업 서버 중 하나에서 worker_max_tasks_per_child 설정을 변경했습니다.

감사!

안녕하세요, 이것은 제 경우에 worker_max_tasks_per_child 를 1000으로 변경하고 문제를 해결했는지 확인하는 것입니다 🎉 다시 @Skowt 감사합니다

어제 언급하지 않은 것, "프리 포크"모드를 사용하고 있습니다. gevent로 이동하는 것이 문제를 해결하는 또 다른 방법 일 수 있습니다.

@arielcamino 이 문제는 특정 메모리 누수를 해결했기 때문에 종료되었습니다. 우리는 아직 메모리 누수의 또 다른 원인을 찾지 못했습니다. 우리는 문제가 있다는 것을 알고 있지만 그것을 재현하는 방법을 모릅니다.
문제를 디버깅하기 위해 버그가 재현되는 프로덕션 환경에 액세스 할 수있는 사람이 필요합니다.
계정이없는 경우이 문제가 실행 가능하지 않은지 확인해야합니다.

안녕하세요,이 문제를 다시 열 수 있나요? celery == 4.4.7 (rabbitmq 사용)을 사용하여 유사한 누수를 경험하고 있습니다. 작업자가 몇 시간 동안, 때로는 훨씬 더 안정적으로 실행 한 다음 갑자기 느리게 누수되기 시작하여 모든 메모리를 사용하게됩니다.

현재 --concurrency=1 및 플래그 --max-tasks-per-child=100 와 함께 prefork를 사용하고 있습니다.이 플래그는 상위 프로세스가 유출 된 것으로 보이므로 도움이되지 않습니다.

이 문제를 디버그하는 데 도움이되는 추가 정보를 제공 할 수 있습니다.

안녕하세요,이 문제를 다시 열 수 있나요? celery == 4.4.7 (rabbitmq 사용)을 사용하여 유사한 누수를 경험하고 있습니다. 작업자가 몇 시간 동안, 때로는 훨씬 더 안정적으로 실행 한 다음 갑자기 느리게 누수되기 시작하여 모든 메모리를 사용하게됩니다.

현재 --concurrency=1 및 플래그 --max-tasks-per-child=100 와 함께 prefork를 사용하고 있습니다.이 플래그는 상위 프로세스가 유출 된 것으로 보이므로 도움이되지 않습니다.

이 문제를 디버그하는 데 도움이되는 추가 정보를 제공 할 수 있습니다.

문제를 다시 여는 것은 큰 문제가 아니며 프로덕션에서이 문제에 직면 한 누군가의 관심이며 수정 사항을 추적하고 기여하거나 적어도 프로덕션에서 누출의 근본 원인을 찾는 데 도움이됩니다.

확실히 도울 수는 있지만 어떻게해야할지에 대한 아이디어가 부족했고 몇 가지 도구를 실행했지만 문제에 대해 많이 식별 할 수 없었습니다. 약간 좁혀지는 유일한 것은 제가 찍은 tracemalloc 스냅 샷입니다. 이것은 몇 분 정도마다 같은 장소에서 메모리가 증가하는 것을 보여줍니다. 다음은 두 스냅 샷을 비교하는 상위 10 개입니다.

/usr/local/lib/python3.8/site-packages/celery/events/dispatcher.py:148: size=259 KiB (+218 KiB), count=1026 (+867), average=259 B
/usr/local/lib/python3.8/site-packages/kombu/messaging.py:178: size=231 KiB (+194 KiB), count=1056 (+888), average=224 B
/usr/local/lib/python3.8/site-packages/amqp/connection.py:513: size=217 KiB (+182 KiB), count=703 (+591), average=316 B
/usr/local/lib/python3.8/site-packages/celery/events/dispatcher.py:214: size=207 KiB (+174 KiB), count=704 (+592), average=302 B
/usr/local/lib/python3.8/site-packages/kombu/messaging.py:200: size=204 KiB (+171 KiB), count=704 (+592), average=296 B
/usr/local/lib/python3.8/site-packages/amqp/transport.py:253: size=203 KiB (+171 KiB), count=703 (+591), average=296 B
/usr/local/lib/python3.8/site-packages/amqp/connection.py:508: size=184 KiB (+154 KiB), count=703 (+591), average=268 B
/usr/local/lib/python3.8/site-packages/celery/worker/consumer/consumer.py:445: size=182 KiB (+153 KiB), count=352 (+296), average=528 B
/usr/local/lib/python3.8/site-packages/amqp/channel.py:1758: size=169 KiB (+143 KiB), count=703 (+593), average=247 B
/usr/local/lib/python3.8/site-packages/kombu/asynchronous/hub.py:301: size=167 KiB (+140 KiB), count=351 (+295), average=486 B

문제가 여전히 존재합니다.
이것은 셀러리 작업이 기능을 수행하기 위해 앱 컨텍스트에 액세스 할 때 발생합니다.
작업을 수행 한 후 해제하거나 폐기하지 않습니다.

--max-tasks-per-child=

도움이되지 않았다

안녕하세요,이 문제를 다시 열 수 있나요? celery == 4.4.7 (rabbitmq 사용)을 사용하여 유사한 누수를 경험하고 있습니다. 작업자가 몇 시간 동안, 때로는 훨씬 더 안정적으로 실행 한 다음 갑자기 느리게 누수되기 시작하여 모든 메모리를 사용하게됩니다.
현재 --concurrency=1 및 플래그 --max-tasks-per-child=100 와 함께 prefork를 사용하고 있습니다.이 플래그는 상위 프로세스가 유출 된 것으로 보이므로 도움이되지 않습니다.

이 문제를 디버그하는 데 도움이되는 추가 정보를 제공 할 수 있습니다.

문제를 다시 여는 것은 큰 문제가 아니며 프로덕션에서이 문제에 직면 한 누군가의 관심이며 수정 사항을 추적하고 기여하거나 적어도 프로덕션에서 누출의 근본 원인을 찾는 데 도움이됩니다.

나를 위해 --max-tasks-per-child 하면 작동합니다.
이 샘플 인수 --autoscale=5,2 --max-tasks-per-child=40 대한 결과는 다음과 같습니다.

최근 셀러리 업그레이드로 인해 메모리 누수가 발생했다고 생각하지만 완전히 확신 할 수는 없습니다. 다음 설정으로 누출이 해결되었음을 공유하겠습니다.

문서에서 어떤 설정이 유효한지 알 수 없으므로 Django 설정 파일에서 이러한 모든 값을 설정하고 있습니다.

CELERY_CONCURRENCY = CELERY_WORKER_CONCURRENCY = 1
CELERY_MAX_TASKS_PER_CHILD = CELERY_WORKER_MAX_TASKS_PER_CHILD = 1

이것은 gevent 풀에서도 발생하기 때문에 우리가보고있는 누수를 해결하지 못합니다. 내가 알아 차린 것은 셀러리 예프 대기열이 매우 바쁘다는 것입니다. tracemalloc은 이벤트 디스패치를 ​​누수의 가능한 소스 중 하나로 보여 주었기 때문에 명시 적으로 작업 이벤트를 비활성화하고 플라워 인스턴스를 해제했습니다. 여기에 결과.

누수의 가능한 소스 나는 명시 적으로 작업 이벤트를 비활성화하고 꽃 인스턴스를 끕니다.

초창기부터이 문제를 조용히 지켜본 사람 (직접 경험 한 적이없는 사람)의 일화 데이터 포인트 : 위의 작업을 수행했을 때 다음과 같은 결과가 발생한 다른 프로젝트 (셀러리 작업량이 많지 않음)를 알고 있습니다. 메모리 누수를 중지합니다. 중고 정보 만 가지고 있기 때문에 동일한 근본적인 문제 (AFAIK, rabbitmq, gevent 등에 대한 정보 없음)라는 사실조차 확인할 수 없지만 상관 관계가 있다는 점이 흥미 롭습니다.

나는 그것이 어떻게 든 rabbitmq 연결과 관련이 있다고 생각합니다.이 누출을 관찰 한 스택입니다.

• celery (최신 버전) : prefork 또는 gevent pool, 둘 다 동일한 누출 패턴을 보여줍니다.
• rabbitmq (cloudamqp SaaS)
• 꽃

우리는 모든 작업에 누출이 있는지 확인했지만 누출을 찾을 수 없었기 때문에 셀러리 측면에서 무언가가 의심되는 이유입니다.

한 가지 흥미로운 사실은 현재 많은 작업자가 실행 중이라는 것입니다. 한 번 누출되기 시작하면 꽃에 오프라인으로 표시되는 것을 발견했습니다.

어디를 볼지 아이디어가 부족하여 꽃 및 작업 이벤트를 비활성화하고 누출이 다시 발생하는지 여부를 계속 모니터링합니다.

이 시점에서 메모리가 누출되는 스택의 또 다른 부분이라고 믿고 있습니다. 셀러리는 과거에 메모리 누수를 제어하는 ​​데 기여한 우연한 행동을했을 수 있지만, 우리 모두는이를 확인할만큼 비슷한 문제가없는 것 같습니다. 나는 우리 중 많은 사람들이 달리고 있다는 것을 알고 있습니다 ...

• 한 번에 많은 수의 중첩 된 작업 또는
• 작업자 내에서 멀티 코어 처리를 시작하는 몇 가지 모 놀리 식

이 경우 특정 수준의 동시성, 작업 대기열 및 하위 작업 자당 작업을 허용하거나 허용하지 않는 것에 대해 현명해야합니다. 또한 우리 모두는 메모리를 많이 사용하는 작업이 서버를 손상시키기 전에 죽일 수있는 내장 된 보호 장치를 사용해야합니다.

점점 더 많은 사람들이 셀러리에서 엄청나게 많은 CPU 바운드 및 메모리 바운드 프로세스를 실행하고 있습니다.이 프로세스는 실제로 만들어지지 않았기 때문에 빠른 시작 문서에 이에 대한 자세한 내용이 포함되어야한다고 생각합니다.

이전 의견에서 이미 언급했듯이 오래 전부터 max-tasks-per-child 및 동시성이 1 설정된 작업자를 실행하고 있습니다. 메모리 누수에 대해서는 아무것도하지 않습니다. 또한 Redis를 브로커 및 결과 백엔드로 사용하고 있습니다.

내 관찰에 따르면 RabbitMQ를 브로커로 사용할 때 max-tasks-per-child 를 1 하면 메모리 누수가 "해결"되면 셀러리가 아닌 작업 구현 문제 일 가능성이 큽니다.

우리가 관찰하고보고하는 것은 다릅니다. 단일 작업을 처리하지 않고 작업자를 며칠 동안 유휴 상태로 두더라도 메모리 제한에 도달하여 감독자에 의해 죽을 때까지 메모리가 누출됩니다. 이전 의견에서 자세한 내용과 메모리 차트를 찾을 수 있습니다.

작업자가 일정에 따라 단일 작업을 처리하는 경우 메모리 차트는 어느 정도 구형파와 비슷하게 표시되어야하지만 전체 메모리 사용량은 증가 만한다는 것을 분명히 알 수 있습니다.

저는 셀러리 작업자의 프로파일 링을 로드맵에 넣었습니다. 이 작업을 시작할 때 메모리 덤프와 자세한 내용을 공유하겠습니다.

꽃을 끄고 설정을 통해 작업 이벤트를 명시 적으로 비활성화하면 누수가 해결되었음을 확인할 수 있습니다.

아까 말씀 드렸듯이 일꾼이 새기 시작하는 순간 꽃속에서 오프라인 상태가 될 것임을 알아 차리고 셀러리 예프가 항상 바쁘게 보이기 때문에 쉬운 길을 밟아 꽃을 껐습니다.

불행히도 누수를 일으키는 코드를 찾을 수 없었습니다. 그러나 적어도이 해결 방법이 있습니다.

그렇다면 이것은 셀러리 문제가 아니라 꽃일까요?

@auvipy 꽃이 문제를 유발하지만 누출은 확실히 작업자 (셀러리)에서 발생합니다.

@auvipy 꽃이 문제를 유발하지만 누출은 확실히 작업자 (셀러리)에서 발생합니다.

그럴 수 있지. 공유해 주셔서 감사합니다.

Redis 및 Flower와 함께 Celery를 사용하고 있으며 현재 메모리 문제가 발생하지 않는다고 말해야합니다. 데이터와 관련하여 나에게 원하는 것이 있습니까?

@auvipy는 Flower를 사용하지 않습니다. 작업자는 이벤트가 비활성화 된 상태로 시작됩니다.

@auvipy는 Flower를 사용하지 않습니다. 작업자는 이벤트가 비활성화 된 상태로 시작됩니다.

디버깅을 시도하고 메모리 누수의 원인을 찾으십시오. 셀러리 또는 당신의 수 있습니다. 단위 테스트와 통합 테스트를 공유 할 수있는 것이 가장 좋습니다.

디버깅을 시도하고 메모리 누수의 원인을 찾으십시오. 셀러리 또는 당신의 수 있습니다. 단위 테스트와 통합 테스트를 공유 할 수있는 것이 가장 좋습니다.

여기서 언급 한 바와 같이, 작업자가 작업을 처리하지 않더라도 셀러리 작업자가 메모리 누수로 인해 OOM이 발생하는 것을 볼 수 있습니다.
회사의 IP가 노출 될 수 있으므로 단위 또는 통합 테스트를 공유 할 수 없습니다. 죄송합니다. 하지만 내부 로드맵에서 프로덕션 작업자의 메모리 덤프를 캡처하는 작업을 추가했습니다. 완료되면 몇 가지 시나리오에 대한 카운터 및 참조를 공유합니다.

@jsynowiec 5.0.0 GA 이전에 만들 수 있다면 (업데이트를 위해 # 6266을 따르십시오) 그것은 굉장 할 것입니다.

버그 수정이 마스터에 도착하면 4.x로도 백 포트됩니다.

@thedrow 5.0의 GA는 언제 계획됩니까? 안타깝게도 아직 Py3 😞로 마이그레이션 할 레거시 코드가 있으므로 당분간 Celery 4를 사용하고 있습니다.

하나의 릴리스 차단기와 완료해야 할 문서가 있습니다.
곧 답이 나옵니다.

꽃을 끄면 누수가 막히는 것을 확인할 수 있습니다. 우리는 거의 한 달 동안 누출없이 실행되었습니다.

따라서 이벤트 게시 메커니즘 어딘가에 여전히 버그가 있습니다.
누구든지 그것이 무엇인지 알고 있습니까?

우리는 Flower를 사용하지 않고 작업자는 --events 없이 시작되지만 지속적인 메모리 누수가 발생합니다.

곧 답이 나옵니다.

프로덕션 작업자로부터 메모리 덤프 및 개체 카운터를 얻는 데 높은 우선 순위를 할당했습니다. 몇 주 안에 데이터를 게시 할 수있을 것입니다. 또한 Python 3을 사용하여 모든 것이 실행되고 프로파일 링되도록 py2-> py3 포팅 마무리에 대한 우선 순위를 높였습니다.

제가 걱정하는 것은 여기서 두 가지 다른 문제에 대해 이야기하고 있다는 것입니다.

분명히. 하나는 이벤트 및 꽃과 관련이 있으며 RabbitMQ를 브로커로 사용할 수도 있습니다. 여기에보고 된 문제에 따르면 GitHub에서 몇 년 동안 여기저기서 나타납니다. 내 프로젝트에 영향을 미치는 다른 하나는 다른 구성 요소와 관련이 있으며 Redis를 브로커로 사용하는 것과 관련이 있습니다. 또는 루트에서 🤷🏼를 아는 동일한 코드에서 발생하는 동일한 문제 일 수 있습니다. trail 하위 작업을 추적하고 AsyncResult 인스턴스를 유출하는 것과 같습니다. 😉

@thedrow @auvipy 우리가 이제 작업자의 메모리 프로파일 링으로 이동하고 있음을 알려드립니다.

또한 Python3 마이그레이션을 완료하는 동안 https://github.com/celery/celery/issues/4470 또는 https://github.com/celery/celery/issues/5359 와 관련된 것으로 보이는 또 다른 문제가 발생했습니다 join_native 호출이 무기한 중단됩니다. 빠른 strace는 문자 그대로 읽기에 매달려 있으며, 이는 저수준 커널 / lib 항목을 나타낼 수 있습니다. 지금은 메모리 누수에 초점을 맞추면서 join 를 풀링하는 일반 모드로 전환했습니다.

안녕하세요 여러분-마침내 _some_ data : celery-memtrace-1.tar.xz , signature , my key .

아카이브에는 ~ 16 일 후 8 명의 작업자의 tracemalloc 로그, 기간에 대한 메모리 사용량 그래프 및 일부 버전 정보 (Celery 시작 배너 포함)가 포함됩니다.

나는 정직하게 이것 중 하나를 분석하는 데 상당한 시간을 소비하지 않았지만 a) 우리 코드는 목록에 없었습니다. 다른 곳에 있거나 조합 / 상호 작용 문제입니다.

다른 세부 사항이 유용 할 경우 문의하십시오. 또한이 메모리 사용량 로깅을 사용하여 8 명의 작업자를 계속 실행하므로 더 많은 / 더 나은 데이터를 수집 할 수 있습니다.

편집 : 또한 이 스레드

이 유출의 근본 원인을 찾으시기 바랍니다.
나는 이것에 대해 스스로 파헤칠 시간을 내도록 노력할 것이다.

이것이 문제를 완화하는 데 도움이 될 수 있는지 궁금합니다.
https://reliability.substack.com/p/run-python-servers-more-efficiently

메모리 누수 원인이 셀러리 자체가 아닌 요청 라이브러리 내에있을 가능성을 조사하고 있습니다. 작업에서 요청을 사용하여 셀러리에서 메모리 누수를 경험하는 다른 사람이 있습니까?

@ErrorInPersona 예, 요청이 있거나없는 작업자에 OOM을 등록하고 있습니다.

@drbig 행운이 있습니까?

글쎄, "녹색"을보세요. 바닥이 천천히 올라가고 있습니다.하지만 확실하게 ... "그래, 여전히 문제입니다"라는 빠른 확인을 제외하고는 내 쪽에서 추가 할 것이 많지 않습니다.

그러나 @thedrow가 제공 한 링크를 - try running some workers with jemalloc forced in 이 포함되어 있으므로 _eventually_에 도달하겠습니다.