Canvasワークフローを使用していますか？多分＃4839が関連しています。

また、ワーカーの並行性のためにプリフォークプールを使用していると思いますか？

georgepsarakis 2018年06月23日

georgepsarakisに感謝します。

ワークフローを使用していません。
単一サーバーでprefork同時実行1を使用します。

marvelph 2018年06月23日

増加率はかなり直線的で、かなり奇妙に見えます。ワーカーはこの期間中にタスクを処理していますか？また、ワーカーの起動に使用している完全なコマンドを使用してメモを追加できますか？

georgepsarakis 2018年06月23日

はい。ワーカーは引き続きタスクを正常に処理します。

ワーカーは次のコマンドで起動します。

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

marvelph 2018年06月23日

この問題は、実稼働環境とテスト環境の両方で発生しています。
テスト環境にメモリプロファイルとテスト出力を追加できます。
何かできることがあれば、何か言ってください。

marvelph 2018年06月23日

メモリの増加が観察されている間、ワーカーが何を実行しているかを理解する必要があります。あなたが提供できるかもしれないどんな情報と詳細も間違いなくそうするでしょう。これを再現できるのもいいですね。

georgepsarakis 2018年06月23日

グラフとは異なるタイミングで発生した場合ですが、メモリリークが発生したタイミングで次のログが出力されました。

[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 2018年06月23日

@marvelphなので、RabbitMQの再接続中に発生しますか？おそらく、これらの問題は関連しています。

georgepsarakis 2018年06月24日

はい。
再接続がトリガーのようです。

marvelph 2018年06月24日

同じ問題が発生しているようです...何が原因で、なぜメモリリークが発生するのかを見つけるのは非常に困難です。少なくとも1か月はイライラします。中古のセロリ3にフォールバックしましたが、すべて問題ありません。

メモリリークの問題については、ubuntu 16、celery4.1.0とrabbitmqを使用しています。 Dockerを介してデプロイしました。

メモリリークは、ForkPoolWorkerではなくMainProcessにあります。 ForkPoolWorkerのメモリ使用量は正常ですが、MainProcessのメモリ使用量は常に増加しています。 5秒間、約0.1MBのメモリがリークします。メモリリークは、作業がすぐに開始された後ではなく、おそらく1〜2日後に開始されます。

gdbとpyrasiteを使用して実行中のプロセスを挿入し、 gc.collect()を試行しましたが、何も収集されません。

ログを確認したところ、 consumer: Connection to broker lost. Trying to re-establish the connection...が発生しましたが、今のところ、これがメモリリークが発生する時期かどうかはわかりません。

この問題をデバッグし、実際に何が起こるかを知るためのヒントはありますか？ありがとう。

jxltom 2018年06月25日

@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

jxltom 2018年06月25日

ログを確認したところ、メモリリークのタイミングで再接続のログが見つかりましたが、再接続が発生しなかったタイミングでメモリリークが発生する場合もありました。
私はjxltonの考えに同意します。

また、Celery 3.xを使用していたときは、このような問題は発生しませんでした。

marvelph 2018年06月25日

ここで同じ問題
screenshot 2018-06-25 11 09 22
この問題のため、数日ごとにワーカーを再起動する必要があります
ログには重要な手がかりはありませんが、再接続が影響を与える可能性があるのではないかと疑っています。メモリが絶えず増加し始める時間のどこかにログエントリを再接続しているので
私のconfはubuntu17、1サーバー-1ワーカー、3同時実行です。バックエンドでのウサギとredis。すべてのパッケージは最新バージョンです

dmitry-kostin 2018年06月25日

👍2

@marvelph @

georgepsarakis 2018年06月25日

設定はデフォルトに近い

imports =（ 'app.tasks'、）
result_persistent = True
task_ignore_result = False
task_acks_late = True
worker_concurrency = 3
worker_prefetch_multiplier = 4
enable_utc = True
タイムゾーン= 'ヨーロッパ/モスクワ'
browser_transport_options = {'visibility_timeout'：3600、 'confirm_publish'：True、 'fanout_prefix'：True、 'fanout_patterns'：True}

screenshot 2018-06-25 11 35 17
基本的に、これは新しくデプロイされたノードです。 06 / 2118-50に展開されました。 05-00頃に6/23の成長を見つめ、最終的に23-00頃に6/23に墜落した

タスクは非常に単純で、そこにはスーパーロジックはありません。明確な一時的なプロジェクトで状況全体を再現できると思いますが、今のところ自由な時間はありません。運が良ければ、週末に完全な例を試してみます。

UPD
タスク自体がメモリを消費していることがわかるように、グラフのスパイクで確認できますが、メモリがリークし始めたときは、タスクやその他のアクティビティは生成されていませんでした。

dmitry-kostin 2018年06月25日

@marvelph @ kostin @ jxltomPython3を使用していることに気づきました。プロセスでtracemallocを有効にして

georgepsarakis 2018年06月25日

@georgepsarakis 5分などの特定の間隔で、上位10個のメモリ使用量ファイルなどのワーカーおよびログ統計でtracemallocを有効にすることを意味しますか？

jxltom 2018年06月25日

@jxltomそのようなものは、コードの原因となる部分を見つけるのに役立つと思います。どう思いますか？

georgepsarakis 2018年06月25日

@georgepsarakis gdbとhttps://github.com/lmacken/pyrasiteを使用してメモリリークプロセスを挿入し、tracemallocを介してデバッグを開始しようとしました。これは、memの使用量が最も多い上位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分後の2つのスナップショットの違いは次のとおりです。

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

jxltom 2018年06月25日

👍1

これをデバッグし続ける方法について何か提案はありますか？どうすればいいのかわからない。ありがとう。

jxltom 2018年06月25日

@georgepsarakis

少し時間をかけてプロジェクトを切り取って複製したいと思います。

セロリの設定です。

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では、監視対象を使用して操作しています。

marvelph 2018年06月26日

@georgepsarakis
私のテスト環境はパフォーマンスの低下に耐えることができるので、tracemallocを使用できます。
パッチを適用したCeleryを作成して、メモリ使用量をダンプできますか？

marvelph 2018年06月26日

@jxltom私は5分でません
たとえば、5つのノードがあり、過去4日間にこの問題が発生したのは3つだけで、この間2つは正常に機能したため、問題を特定するのは非常に困難です。
このスイッチのメモリ消費量が非常によく見えるまで、スイッチをオンにしてからメモリが増え始めるトグルがあるように感じます

dmitry-kostin 2018年06月26日

他の実行中のシステムでも同様の問題が発生したかどうかを調べてみました。
発生頻度はさまざまですが、Celery 4.xを使用している3つのシステムでメモリリークが発生しており、1つのシステムでは発生していません。
メモリリークのあるシステムはPython3.5.xであり、メモリリークのないシステムはPython2.7.xです。

marvelph 2018年06月26日

@ dmitry-kostin他の2つの通常のノードとの違いは何ですか、どちらもブローカーとして同じrabbitmqを使用していますか？

私たちの議論では、rabbitmqに関連している可能性があると述べたので、代わりにredisを使用することを除いて、同じ構成で別の新しいノードを開始しました。これまでのところ、このノードには24時間実行した後のメモリリークはありません。後でメモリリークが発生した場合は、ここに投稿します

jxltom 2018年06月26日

@marvelphでは、メモリリークのある3つのシステムがpython3を使用しているのに対し、問題のないシステムはpython2を使用しているということですか？

jxltom 2018年06月26日

@jxltomまったく違いはありません。はい、Python 3にあり、ブローカーとしてRabitを使用し、バックエンドでRedisを使用しています。
私はこれを再現するためのテスト例を作成しました。数日で成功する場合は、このバグを見つける方法を知っている誰かのために、このサーバーに資格情報を提供します。

dmitry-kostin 2018年06月26日

@jxltom
はい。
私の環境に関する限り、Python2では問題は発生しません。

marvelph 2018年06月26日

より長い期間内に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返します...

jxltom 2018年06月26日

@georgepsarakisこれを再現でき、アクセス

dmitry-kostin 2018年06月29日

更新：ブローカーのURLを環境変数として更新し、Docker /コードを完全に同じに保つことで、ブローカーをrabbitmqからredisに更新しました。そして、それは4日間実行されており、メモリリークはありません。

したがって、この問題はrabbitmqブローカーに関連していると思います。

jxltom 2018年06月29日

可能であれば、ここに記載されているベンチマークコマンドを実行してみてください： https ：

georgepsarakis 2018年06月29日

このシステムは、20台のサーバーでワーカーを実行しています。
昨日メモリリークが発生しましたが、ほぼすべてのサーバーで同時に発生しています。
memoryleak

marvelph 2018年06月30日

👍2

関連しているかどうかわからないので、役立つ場合に備えてここに残しておきます。

セロリとrabbitmqに別の問題があります（セロリが接続を失い、1秒あたりの負荷の再接続を開始し、CPUが1コアで100％になり、ビートが新しいタスクを送信できず、セロリを再起動する必要があります）。

ここでこれを報告する理由はトリガーです。何日も監視した後、問題の始まりを見つけたと思います。rabbitmqがいくつかのメッセージをメモリからディスクに移動しているようです。その時点で、セロリはできるだけ速く再接続を試み始め、rabbitmqログには、一度に約10のバッチで、1秒あたり数十の接続/切断操作が表示されます。 rabbitmqを再起動しても問題は修正されませんが、celeryを再起動するとすぐに修正されます。適切な修正はありませんが、例として、メッセージを常にメモリに保持できるようにする有効期限ポリシーを設定すると、問題が回避され、それ以降は確認されていません。

この問題のいくつかの詳細が私が見たものと一致することを考えると（rabbitmqをredisと交換すると修正されます、明確な開始点はありません、同時に複数のワーカー/サーバーで発生します）共通のトリガーがある可能性があります私が見つけたのと同じである。

nicbus 2018年06月30日

テストスイートは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') !

jxltom 2018年07月03日

同じストレステストスイートでセロリ3.1.25を使用するように更新しましたが、すべて問題ありません。

jxltom 2018年07月03日

ところで、迅速な修正を探しているすべての人にとって–ウサギをredisに置き換えると、@ jxltomが示唆するように問題が解決します。私は、
ですから、問題は間違いなくウサギ<->セロリの国境近くにあります

dmitry-kostin 2018年07月09日

👍5

@dieeasy同じ問題が発生しました。 RPC結果バックエンドを使用していると思います。その場合は、DB結果バックエンドに切り替えてみて、それが役立つかどうかを確認してください。これを引き起こす問題は次のとおりです： https ： https ：

encodeltd 2018年08月17日

同じ問題がありますメモリリーク
記憶

バージョン
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

`` `python

----コーディング：utf-8 ----

昆布インポートキュー、Exchangeから
oslo_logからログとしてログをインポート

app.confからインポートCONF

LOG = logging.getLogger（__ name__）

celery_queues =（
Queue（ 'im'、exchange = Exchange（ 'sender'）、routing_key = 'im'）、
Queue（ 'sms'、exchange = Exchange（ 'sender'）、routing_key = 'sms'）、
Queue（ 'mail'、exchange = Exchange（ 'sender'）、routing_key = 'mail'）、
Queue（ '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'}
}

config = {
'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())

必要に応じて、より多くの情報を提供できます。

kolapapa 2018年11月07日

価値があるので、私はこの問題を抱えており、rabbitmq管理コンソールを開き、接続に移動し、セロリからrabbitmqへのトラフィックとの接続を閉じることで一貫して再現できます。

セロリ4.1と4.2、およびrabbitmq3.7.7-1でテストしました
編集：Pythonバージョン3.6.5とubuntu 16.04（AWS EC2イメージ）も

ConnorWhalen 2018年11月29日

セロリ4.2.1とredisブローカーでメモリリークが発生しています。メモリは3時間で100MiBから500MiB（制限付き）に増加し、ワーカーは花でオフラインとしてマークされます。 preforkプールとgeventの両方で同じ問題が発生します。

yifeikong 2018年12月28日

@yifeikongこれは同じ問題ではないかもしれませんが、あなたのケースでは、 https： //github.com/celery/celery/pull/4839#issuecomment-447739820で提案されている解決策を試してみて

georgepsarakis 2018年12月28日

@georgepsarakis Python 3.6.5を使用しているので、このバグの影響を受けません。 tracemallocを使用して調査を行います。セロリのバグだったら、新しい号を開きます。ありがとう

yifeikong 2018年12月29日

おそらく＃5047と同じ原因ですが、このバグは別の現象につながる可能性があるようです。

ssikyou 2019年01月20日

ブローカーとしてRabbitMQを使用してCelery4.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、 AsyncResultモンキーパス__del__を使用）が、常にメモリリークが発生していました。

ログを分析したところ、ゴシップからのハートビートの欠落に関連するメッセージがたくさんあることがわかりました。

{"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で実行してゴシップを無効にすること

あなたはここでそれを見ることができます：
celery-memory-14d

セロリワーカーを実行している2つのプロジェクトでゴシップを無効にしてから、メモリ消費量が改善されました。

注意を払うと、ここで説明されているのと同様のメモリスパイクが発生する前に、 https： //github.com/celery/celery/issues/4843#issuecomment -399833781

私が完全に理解しようとしていることの1つは、ゴシップを完全に無効にすることの意味は何であるかということです。ゴシップは労働者<->労働者のコミュニケーションとしてのみ説明されているため、誰かがこれについて光を当てることができれば、私は非常に感謝します。

これがお役に立てば幸いです。ハードワークに感謝します。

menecio 2019年02月01日

👍3

この問題が解決されたのはなぜですか？

AvnerCohen 2019年02月04日

👍17

この問題には積極的なフィードバックと関心が寄せられているので、再開します。

georgepsarakis 2019年02月04日

👍11

@georgepsarakisは、リークが＃4839ではないと診断し、＃4843であると疑っていたので、少なくとも今のところ、このリークスレッドに切り替えます。＃4843も私のリークかどうかはわかりません。このスレッドの最初の問題によると：

この問題は、少なくともCelery 4.1で発生し、Celery4.2でも発生します。
CeleryはUbuntu16で実行されており、ブローカーはRabbitMQを使用します。

私は現在：

Python 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もリークしません）。セロリ4.2.1+ gevent1.3.7はそうです。残念ながら、gevent1.3.7とgevent1.2.2は、問題の考えられる原因としてgeventライブラリを示す（または除外する）ために互換性がありません。

編集：うーん...私が遭遇したエラーを修正できるように見えるgeventパッチ（022f447dd）があるようです。私はそれを機能させるように努めます。

ldav1s 2019年02月08日

セロリ4.1.1に022f447を適用し、gevent1.3.7をインストールしました。そのCelery + geventの組み合わせが実行され、私が経験したリークと一致するメモリ使用パターンが生成されました。 Celery 4.2.1 + gevent 1.2.2（リバースパッチ付き）をインストールして、通常のメモリ使用パターンが得られるかどうかを確認します。

gevent1.4.0がリリースされていることに気づきました。たぶん、それがどのように動作するかを確認するために、それも回転させる必要があります。

ldav1s 2019年02月09日

Celery 4.2.1 + gevent 1.2.2 + gevent 1.2.2のリバースパッチは、Celery 4.2.1 + gevent1.3.7のようにリークを生成しないようです。

ldav1s 2019年02月13日

Celery 4.2.1 + gevent 1.4.0は、gevent 1.3.7AFAICTとほぼ同じ速度でリークしているようです。

ldav1s 2019年02月14日

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が内部で何をするかを正しく理解していれば、AMQPには独自のハートビートがあり、接続の切断を検出すると、内部で先に進んで再接続します。有効になっているイベントの種類（ゴシップ、ハートビート）によっては、これはかなり速くリークする可能性があります。
これは、eventletとgeventのすべてのバージョンに当てはまるはずですが、接続の問題が発生して事態が悪化したり、目立ったりする可能性があります。

iafilatov 2019年02月16日

👍2 👀1

こんにちは、

同じ問題が発生しているのではないかと思います。
構成は以下のとおりです。これがここで説明したのと同じ問題であることを否定または確認できますか？

Python：2.7
セロリ：4.2.1
OS：CentOSリリース6.10
ブローカーとしてのRedis

添付の画像では、次のことがわかります。

メモリ消費量は絶えず増加し、再起動時に低下します。
1月13日、セロリ3.1.25から4.2.1にアップグレードしました。メモリ消費量の増加ペースが大きくなります。

更新

この問題に関係なく、Python 3.6にアップグレードしました。それ以降、リークは発生しなくなったようです。

（アップグレードは2月19日でした）

@georgepsarakis

Gabaie 2019年02月18日

👀1

これがどれほど関連性があるかはわかりませんが、本番環境でセロリによって2GBのSWAPスペースが使い果たされています。花を止めることは記憶をクリアしませんでした、しかしセロリを止めることはそうしました。

pembo13 2019年02月21日

誰かがセロリ4.3rc1を試すことができますか？

auvipy 2019年02月21日

@auvipy Celery 4.3.0rc1 +

＃4839がそのアップグレードによって修正されていることを考えると、つる1.2.0もrc1パッケージに必要ではなかったことに戸惑いました。

とにかく、Celery 4.3.0rc1は問題なく動作しているようです。

ldav1s 2019年02月22日

👍1

@ ldav1sフィードバックをありがとうpy-amqpの依存関係として宣言されています。新規インストールでは、最新のvineバージョンがインストールされますが、これは既存のバージョンでは発生しない可能性があります。

@thedrowおそらく、

georgepsarakis 2019年02月22日

👍1

それについての問題を開いて、そこで議論しましょう。

thedrow 2019年02月24日

Celery 4.3.0rc1 + gevent 1.4.0は、数日実行されています。 Celery 4.2.1 + gevent1.4.0と同じ方法でリークしているようです。

ldav1s 2019年02月25日

👍3

セロリ4.2.1、Python3.6で同じリークがあります

これに関する更新はありますか？

yogevyuval 2019年03月02日

👍5

ここで同じ問題を抱えている

bilalbayasut 2019年03月28日

👎2

ご挨拶、

同様の問題が発生していますが、同じかどうかはわかりません。

セロリアプリを別の環境/ネットワークに移行した後、セロリワーカーがリークし始めました。以前は、celeryアプリケーションとrabbitmqインスタンスは同じ環境/ネットワークにありました。

私の設定はPython3.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)

celeryconfig

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のコマンドを介して開始されたイベントレットプールを持つ複数のワーカーで構成されています。

[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コマンドの結果であり、1464mでリークしているワーカーは1つだけです。

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

リークしているワーカーのtracemallocTOP10の結果

[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フレームのTOP1

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)

私はそれが助けになることを願っています、労働者間の逃した心拍を除いて、ログにエラーはありません。今、私は古い環境を使用していたライブラリの正確なバージョンを使用しようとしています。

更新：同じ正確な依存関係のlibバージョンと5分ごとのブローカーハートビートを使用すると、アプリケーションは2日以上、再びリークするよりも長い間安定しているように見えました。

時間ごとに約1時間続く小さなスパイクがありましたが、「吸収/収集」されました。最後のスパイクはスパイクを開始したように見えます。

1回目のスパイク、1回目のランプの後、リークしているワーカーを再起動しました。別のワーカーがその後リークし始めたか、おそらくすでにリークしていた2回目のランプです。

ハートビートなしでテストします。

更新：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を使用すると、問題は解決したようで、1週間から安定しています。

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)

コードをインストルメント化して、なんとかして手助けできるかどうか教えてください。必要に応じて、リンクと例を提供してください。

ありがとうございました

davidedeangelismdb 2019年03月29日

👍2

また、メモリリークが発生しています。原因を突き止めたようです。
https://github.com/celery/celery/blob/master/celery/events/dispatcher.py#L75
このバッファは、ウサギとの接続の問題の後に大きくなり始めることがわかります。最終的にイベントをクリアできない理由がわかりません。時間の経過とともに成長し続け、RAMをますます消費します。ここでbuffer_while_offline=False渡すと、 https：//github.com/celery/celery/blob/master/celery/worker/consumer/events.py#L43でリークが修正されたようです。誰かがこれが関連しているかどうかを確認できますか？

yevhen-m 2019年04月24日

👍2

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

auvipy 2019年04月24日

@ yevhen-mどうもありがとうございました！それは私たちがメモリリークを解決するのに役立ちました！

slavpetroff 2019年09月04日

🚀2 🎉2

回避策があるのは良いことですが、適切な修正を見つけることができますか？

thedrow 2019年09月10日

このメモリリークの問題を継続的に追跡する

lxkaka 2019年12月26日

celery-pod-screencshot-lastweek

私は本番環境でセロリを使用しており、Dockerを介して展開しています。
スクリーンショットのように、同じ問題が発生しています。
本番構成を以下に示します。

Dockerの親イメージ：python3.6.8-バスター
セロリバージョン：4.2.0
コマンドオプション：

並行性4
プリフェッチ乗数8
result_backendはありません
acks_lateおよびreject_on_worker_lost

セロリのバージョンを4.3.0にアップグレードすると、メモリリークの問題が解決するかどうか疑問に思います。

ありがとうございました！

yoonnoon 2019年12月27日

セロリ4.4.0は最新の安定版です

auvipy 2019年12月27日

チーム、この問題に関する更新はありますか？これはセロリ4.4.0で対処され、修正されましたか？

spidernello 2020年01月28日

👀7

チーム、この問題に関する更新はありますか？これはセロリ4.4.0で対処され、修正されましたか？

残念だけど違う。現在、対処されています。

thedrow 2020年02月09日

チーム、この問題に関する更新はありますか？これはセロリ4.4.0で対処され、修正されましたか？

4.4.1で利用可能になります

auvipy 2020年02月26日

4.4.1で利用可能になります

現在のバージョン4.4.1で修正されていますか？

nixon1333 2020年03月23日

@auvipyこの問題は、

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フラグと

〜長時間実行されているタスクでは、多くのハートビートの欠落が見られます。したがって、リンクされた問題で報告された問題は引き続き発生します。〜

ハートビートが無効の場合も同じです。

jsynowiec 2020年04月13日

👍1

@jsynowiecこの問題に直面したとき、私https://github.com/celery/celery/issues/4843#issuecomment -459789086

menecio 2020年05月11日

セロリ4.4.2とredisでブローカーとして同じ問題が発生しています。セロリは48時間の間に、最終的にメモリが不足するまで最大60GBのRAMを消費します。
ここで名前を挙げたソリューションはどれも、この動作に影響を与えませんでした。

ErrorInPersona 2020年07月10日

👍2

セロリ4.4.2とredisでブローカーとして同じ問題が発生しています。セロリは48時間の間に、最終的にメモリが不足するまで最大60GBのRAMを消費します。
ここで名前を挙げたソリューションはどれも、この動作に影響を与えませんでした。

最新のパッチバージョンを試しましたか？
OPと同じ条件はありますか？

thedrow 2020年07月12日

v4.4.6でもメモリリークが発生します。以前のコメントに記載されて

jsynowiec 2020年07月12日

+1、最小限の作業でさえ、メモリ使用量が24時間にわたって徐々に増加することに気づきます。この問題は再開されるべきだと思います。

Skowt 2020年07月12日

あなたはあなたのメモリリークの原因をプロファイリングして見つけることができますか？

auvipy 2020年07月13日

v4.4.6でもメモリリークが発生します。以前のコメントに記載されて

これは別の問題であるか、修正が正しくなかったようです。
これでOPの問題が解決したので、おそらく別の問題ですよね？

thedrow 2020年07月14日

👍1

[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クライアントがメモリリークしていますか？私はセロリv4.4.6をgevent、redisをブローカーとして使用しており、結果のバックエンドはありません。

susoo 2020年07月31日

👍1

多分それも問題です。多分それはgeventにありますか？
CC @jamadden @andymccurdy
この問題を解決し、メモリがリークしていないことを確認するのを手伝っていただけませんか。

thedrow 2020年08月02日

👍1

多分それはgeventにありますか？

geventは使用していません。ワーカーは、concurrency = 1およびpreforkで開始されます。

jsynowiec 2020年08月03日

👍1

こんにちは皆さん、この問題が解決された理由はわかりません。この問題は2年間発生しており、毎回最新バージョンのCeleryに更新されていますが、大きなサーバー（64〜128 GBのRAM）では常にRAMが不足しています。このメモリリークの問題の。

Celery 3にダウングレードしたり、Rabbitmqを置き換えたりせずに、回避策はありますか？

これにより、Celeryは実稼働環境で完全に不安定になります。修正できるといいのですが、Celery 3にダウングレードできないため、Celeryがサーバー全体のRAMを消費する心配をなくすために、別のソリューション（おそらくDramatiq）に移行することを計画しています。 2日ごとの生産。

arielcamino 2020年08月03日

👍1

@ arielcamino-設定worker_max_tasks_per_childを使用して、少なくとも私のサーバーでは、メモリ使用量を維持するのに

Skowt 2020年08月03日

🎉1 👍1

@Skowtうわー、それはとても役に立ちます、どうもありがとう！今すぐ試してみます。

arielcamino 2020年08月03日

@ arielcamino-設定worker_max_tasks_per_childを使用して、少なくとも私のサーバーでは、メモリ使用量を維持するのに

回避策を共有していただきありがとうございます。これはここでは役に立ちませんでした-しかし、私たちはredisを使用しています。

ErrorInPersona 2020年08月03日

@ thedrowredis-pyでのメモリリークを認識していません。 redis-pyにリークがあった場合、誰かがCelery環境の外でリークに遭遇し、redis-py問題追跡システムに報告したと思います。

できる限りサポートさせていただきます（いくつかのプロジェクトでブローカーとしてCelery w / Redisを使用しています）が、展開でこの問題が発生したことはありません。

andymccurdy 2020年08月03日

❤1 👍1

現在のバージョンのgeventでメモリリークが発生していることに気づいていません。私は、誰かがそれに遭遇した場合、誰かが何かを言ったであろうと思います（それは以前に1回か2回起こったことがあります）。私の現在のgeventの展開では、geventを頻繁に使用して、一度に複数のワーカー（Webとバックグラウンド）が数週間稼働しており、メモリリークは発生していません。

jamadden 2020年08月03日

👍2 ❤1

こんにちは皆さん、この問題が解決された理由はわかりません。この問題は2年間発生しており、毎回最新バージョンのCeleryに更新されていますが、大きなサーバー（64〜128 GBのRAM）では常にRAMが不足しています。このメモリリークの問題の。
Celery 3にダウングレードしたり、Rabbitmqを置き換えたりせずに、回避策はありますか？
これにより、Celeryは実稼働環境で完全に不安定になります。修正できるといいのですが、Celery 3にダウングレードできないため、Celeryがサーバー全体のRAMを消費する心配をなくすために、別のソリューション（おそらくDramatiq）に移行することを計画しています。 2日ごとの生産。

何人の労働者がいますか？いくつのタスクを実行しますか？このタスクを実行する頻度と、通常、完了するまでにかかる時間はどれくらいですか。

Rabbitmq / celeryが大量のRAMを使用し始める理由は、キューに入れられたタスクの量に関連している可能性があります。キューに入れるタスクが多すぎてワーカーがすべてを完了できない場合、キューが拡大し、このキューはますます多くのRAMを使用し、最終的には使用可能なすべてのRAMを消費します。この問題はRedisでも発生する可能性があると思います。

私には別の理論がありますが、最初にこれがあなたの問題の理由であるかどうかを知りたいです。

ardilom 2020年08月03日

👍1

@ardilom申し訳ありませんが、RabbitMQデータをdatadogに送信していないことに気づきましたが、状況を明確にしようと思います。これは、一部のサーバーのRAMが2日ごとにダウンする方法です。
memory-leaks-1

保留中のタスクの数を常にチェックしており、通常は約0です（このデータは数日前のものです）。

memory-leaks-2

1日あたり約250,000のタスクを実行し、約10人のワーカーがいて、それぞれが約4〜10の同時実行性を持ち、平均実行時間は約5秒です。これは、タスクの種類によって異なります。

私たちは常にmessages_readyをチェックして、キューに入れられているタスクが多すぎないことを確認しますか？最終的にはいくつかのピークがありますが、通常、これらは0に近い値です。

この問題を解決するには、Celeryワーカーを手動で再起動するだけで、RAMの使用量が再び正常になります。

他に何か必要な場合はお知らせください。構成を適用した後、タスクサーバーの1つで

ありがとう！

arielcamino 2020年08月03日

こんにちはみんな、これは私の場合、 worker_max_tasks_per_childを1000に変更して問題を修正したことを確認するためです🎉ありがとう@Skowt

昨日言及しなかったことがありますが、私は「プリフォーク」モードを使用しています。おそらく、geventに移行することが問題を解決する別の方法です。

arielcamino 2020年08月04日

🎉1 👎1

@arielcamino特定のメモリリークを解決したため、この問題は解決されました。メモリリークの別の原因はまだ見つかっていません。問題があることはわかっていますが、それを再現する方法がわかりません。
問題をデバッグするには、バグが再現される本番環境にアクセスできる人が必要です。
ない場合は、この問題が実行可能ではないと判断する必要があります。

thedrow 2020年08月04日

👍1

こんにちは、この問題を再開できますか？ celery == 4.4.7（rabbitmqを使用）を使用すると、同様のリークが発生します。ワーカーは数時間、場合によってはそれ以上安定して実行されます。その後、突然リークが始まり、すべてのメモリを使用することになります。

現在、 --concurrency=1とフラグ--max-tasks-per-child=100でpreforkを使用していますが、親プロセスがリークしているように見えるため、役に立たないようです。

celery_leak

この問題のデバッグに役立つ詳細情報を提供できます。

loop0 2020年08月07日

👍1

こんにちは、この問題を再開できますか？ celery == 4.4.7（rabbitmqを使用）を使用すると、同様のリークが発生します。ワーカーは数時間、場合によってはそれ以上安定して実行されます。その後、突然リークが始まり、すべてのメモリを使用することになります。
現在、 --concurrency=1とフラグ--max-tasks-per-child=100でpreforkを使用していますが、親プロセスがリークしているように見えるため、役に立たないようです。
この問題のデバッグに役立つ詳細情報を提供できます。

問題を再開することは大したことではありません。本番環境でこれに直面している誰かの利益であり、修正を追跡して貢献するか、少なくとも本番環境でのリークの根本原因を見つけるのに役立ちます。

auvipy 2020年08月12日

私は間違いなく助けることができますが、私は何をすべきかについてのアイデアを少し使い果たしました、私はいくつかのツールを実行しましたが、問題について多くを特定することができませんでした。ちょっと絞り込んだのは、私が撮ったtracemallocスナップショットだけです。これは、同じ場所で数分ごとにメモリが増加していることを示しています。これは、2つのスナップショットを比較したトップ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

loop0 2020年08月12日

問題はまだ存在します
これは、セロリタスクがアプリコンテキストにアクセスして機能を実行するときに発生します
タスクの実行後に解放または破棄されません

--max-tasks-per-child=

役に立たなかった

Kalanamith 2020年08月13日

こんにちは、この問題を再開できますか？ 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結果は次のようになります

Screenshot 2020-08-13 at 2 26 13 PM

nixon1333 2020年08月13日

最近のセロリのアップグレードによってメモリリークが発生したと思いますが、完全に自信はありません。次の設定でリークが解決したことを共有します。

ドキュメントでどの設定が有効かわからないので、Django設定ファイルでこれらすべての値を設定しています。

CELERY_CONCURRENCY = CELERY_WORKER_CONCURRENCY = 1
CELERY_MAX_TASKS_PER_CHILD = CELERY_WORKER_MAX_TASKS_PER_CHILD = 1

chrisconlan 2020年08月14日

❤1 👎1

これは、geventプールでも発生するため、発生しているリークを解決しません。私が気付いたのは、celeryevキューが非常に混雑していることです。 tracemallocは、リークの考えられる原因の1つとしてイベントのディスパッチを示したため、タスクイベントを明示的に無効にし、flowerインスタンスをオフにしました。今のところ、リークは発生していないようです。週末に実行して共有します。ここに結果があります。

loop0 2020年08月14日

リークの考えられる原因タスクイベントを明示的に無効にし、flowerインスタンスをオフにしました

早い段階からこの問題を黙って見ている（そして直接経験したことがない）誰かからの逸話的なデータポイント：上記を実行したときに同じ結果が得られた別のプロジェクト（セロリの作業負荷がそれほど大きくない）を知っていますメモリリークを停止します。中古の情報しかないので、それが同じ根本的な問題であるかどうかは_明らかに_確認できません（AFAIKはrabbitmqであり、geventについてはわかりません）が、相関しているのは興味深いことです。

kezabelle 2020年08月14日

👍1

私はそれがどういうわけかrabbitmq接続と関係があると思います、私たちがこのリークを観察しているスタック：

セロリ（最新バージョン）：プリフォークまたはゲイベントプールのいずれかで、どちらも同じリークパターンを示します。
rabbitmq（cloudamqp SaaS）
花

すべてのタスクでリークをチェックしましたが、リークは見つかりませんでした。そのため、セロリ側にいるのではないかと疑っています。

興味深い事実の1つは、現在多くのワーカーが実行されていることです。リークが開始されると、花にもオフラインとして表示されることに気付きました。

どこを見ればよいかわからなくなったので、フラワーイベントとタスクイベントを無効にし、リークが再発するかどうかを監視し続けます。

loop0 2020年08月14日

この時点でメモリリークが発生しているのは、スタックの別の部分であると私は信じています。セロリは過去に偶然の行動を起こし、メモリリークの制御に貢献した可能性がありますが、私たち全員がそれを確認するのに十分な同様の問題を抱えているようには見えません。私たちの多くがどちらかを実行していることを知っています...

一度に膨大な数のネストされたタスク、または
ワーカー内でマルチコア処理を開始するいくつかのモノリシック

このような場合、特定のレベルの同時実行性、タスクキューイング、およびチャイルドワーカーごとのタスクを許可または禁止することについて賢明である必要があります。さらに、サーバーをクラッシュさせる前に、メモリを大量に消費するタスクを強制終了できる組み込みのセーフガードを使用する必要があります。

ますます多くの人々がセロリで重いCPUバウンドおよびメモリバウンドプロセスを実行していますが、それは実際には意図されていなかったので、クイックスタートドキュメントにはこれに関する詳細を含める必要があると思います。

chrisconlan 2020年08月14日

すでに私の以前のコメントで述べたように、我々は両方で労働者を実行しているmax-tasks-per-childと同時実行セットに1ずっと前から。メモリリークについては何もしません。さらに、ブローカーと結果のバックエンドの両方としてRedisを使用しています。

私の観察によると、RabbitMQをブローカーとして使用する場合、 max-tasks-per-childを1すると、メモリリークが「解決」される可能性が高く、セロリではなくタスクの実装に問題がある可能性があります。

私たちが観察し、報告しているものは異なります。 1つのタスクを処理せずに、ワーカーを数日間アイドル状態のままにしても、メモリ制限に達してスーパーバイザーによって強制終了されるまでメモリリークが発生します。あなたは以前のコメントでより多くの詳細と記憶チャートを見つけることができます。

ワーカーが1つのタスクをスケジュールどおりに処理すると、メモリチャートは多かれ少なかれ方形波のように表示されますが、全体的なメモリ使用量が増えるだけであることがはっきりとわかります。
Screenshot 2020-08-14 at 20 42 24

セロリ労働者のプロファイリングをロードマップに載せることができました。これに取り組み始めるときに、メモリダンプと詳細を共有します。

jsynowiec 2020年08月14日

🚀1 ❤1 👍1

花をオフにする（そして設定を通じてタスクイベントを明示的に無効にする）ことでリークが修正されたことを確認できます。

さっきも言ったように、作業員が漏れ始めた瞬間、花がオフラインになり、セレリエフはいつも忙しいので、簡単な方法で花を消しました。

残念ながら、リークの原因となるコードは見つかりませんでした。しかし、少なくともこの回避策はあります。

loop0 2020年08月17日

それならおそらくこれはセロリの問題ではなく花ですか？

auvipy 2020年08月17日

@auvipy flowerが問題を引き起こしますが、リークは間違いなくワーカー（セロリ）で発生します

loop0 2020年08月17日

@auvipy flowerが問題を引き起こしますが、リークは間違いなくワーカー（セロリ）で発生します

けっこうだ。共有してくれてありがとう。

auvipy 2020年08月17日

私はRedisとFlowerでCeleryを使用していますが、現在メモリの問題は発生していないと言わざるを得ません。データに関して私に何か欲しいものはありますか？

pembo13 2020年08月17日

👍1

@auvipyはFlowerを使用していません。ワーカーは、イベントを無効にして開始されます。

jsynowiec 2020年08月18日

@auvipyはFlowerを使用していません。ワーカーは、イベントを無効にして開始されます。

デバッグして、メモリリークの原因を見つけてください。セロリかあなたの可能性があります。ユニットテストと統合テストを共有できれば最高です

auvipy 2020年08月18日

デバッグして、メモリリークの原因を見つけてください。セロリかあなたの可能性があります。ユニットテストと統合テストを共有できれば最高です

ここで言及し
会社のIPが公開されるため、ユニットテストまたは統合テストを共有できません。ごめんなさい。しかし、社内ロードマップに本番ワーカーのメモリダンプをキャプチャするタスクを追加することができました。完了したら、いくつかのシナリオのカウンターと参照を共有します。

jsynowiec 2020年08月18日

👍2

@jsynowiec 5.0.0 GAより前に作成できる場合（更新については＃6266に従ってください）、それは素晴らしいことです。

バグ修正がマスターに到達すると、4.xにもバックポートされます。

thedrow 2020年09月01日

@thedrow 5.0のGA

jsynowiec 2020年09月07日

1つのリリースブロッカーといくつかのドキュメントがあります。
答えはすぐです。

thedrow 2020年09月09日

👍1

花を消すと漏れが止まることが確認できます。ほぼ1か月間、リークなしで稼働しています。

loop0 2020年09月09日

👍1

そのため、イベント公開メカニズムのどこかにまだバグがあります。
誰かがそれが何であるかについての考えを持っていますか？

thedrow 2020年09月10日

Flowerは使用せず、ワーカーは--eventsなしで開始されますが、メモリリークが継続的に発生します。

答えはすぐです。

プロダクションワーカーからのメモリダンプとオブジェクトカウンターの取得に高い優先度を割り当てることができました。次の数週間でいくつかのデータを投稿できるようになるはずです。また、Python 3を使用してすべてを実行し、プロファイリングする必要があるように、py2-> py3移植を完了することの優先度を上げました。

jsynowiec 2020年09月10日

❤3

私が心配しているのは、ここで2つの異なる問題について話しているということです。

thedrow 2020年09月13日

どうやら。 1つはイベントに関連しており、おそらくFlowerであり、ブローカーとしてRabbitMQを使用している可能性もあります。ここで報告されている問題によると、GitHubでは、数年前からあちこちに表示されています。もう1つ（私のプロジェクトに影響を与える）は、さまざまなコンポーネントに関連しており、Redisをブローカーとして使用することに関連している可能性があります。または、おそらく根本的に、それらは🤷🏼を知っている同じコードに起因する同じ問題です。 trailがサブタスクを追跡し、 AsyncResultインスタンスをリークしているようなものです😉

jsynowiec 2020年09月14日

@ thedrow @ auvipyワーカーのメモリプロファイリングに移行していることをお知らせします。

また、Python3の移行を完了しているときに、 https：//github.com/celery/celery/issues/4470またはhttps://github.com/celery/celery/issues/5359に関連していると思われる別の問題が発生しましたjoin_nativeへの呼び出しが無期限にハングします。クイックstraceは、文字通り読み取りにハングアップしていることを示しています。これは、低レベルのカーネル/ライブラリのものを示している可能性があります。今のところ、メモリリークに焦点を合わせているため、プレーンに切り替えてjoinをプールしました。

jsynowiec 2020年09月28日

👀3

みなさん、こんにちは-最後に_some_データ： celery-memtrace-1.tar.xz 、署名、私の鍵。

アーカイブには、約16日後の8人のワーカーからのtracemallocログ、その期間のメモリ使用量グラフ、およびいくつかのバージョン情報（Celeryスタートアップバナーを含む）が含まれています。

私は正直なところ、これを分析するのにかなりの時間を費やしていませんが、a）コードがリストに含まれていなかった、b）どこでも使用しているSQLAlchemyとの奇妙な相互作用である可能性があるため、問題が発生することは不可能ではありません他の場所にあるか、組み合わせ/相互作用の問題です。

他の詳細が役立つ場合は、お問い合わせください。また、このメモリ使用量ログを使用してこれらの8つのワーカーを引き続き実行するため、より多くの/より良いデータを収集できる可能性があります。

編集：このスレッドからのこのコメントも関連しています-私たちはまだ同じ設定を使用しています。

drbig 2020年11月03日

🎉1

このリークの根本的な原因を見つけていただければ幸いです。
これを自分で掘り下げる時間を作ってみます。

thedrow 2020年11月03日

これが問題の軽減に役立つのではないかと思います。
https://reliability.substack.com/p/run-python-servers-more-efficiently

thedrow 2020年11月17日

メモリリークの原因がセロリ自体ではなくリクエストライブラリ内にある可能性を調査しています。タスクのリクエストを使用してセロリのメモリリークを経験している他の人はいますか？

ErrorInPersona 2020年11月17日

👍2 👎1

@ErrorInPersonaはい、リクエストの有無にかかわらず、ワーカーにOOMを登録しています。

jsynowiec 2020年11月17日

👍1

@drbig運がいいですか？

thedrow 2020年11月17日

Screenshot_2020-11-17_12-56-28

さて、「緑のもの」を見てください。床はゆっくりと、しかし確実に上昇しています...ですから、残念ながら、「うん、それはまだ問題です」という簡単な確認を除いて、私の側から追加することはあまりありません。

ただし、 @ thedrowが提供するリンクを- try running some workers with jemalloc forced inが含まれるようになったので、_最終的に_それについて説明します。

drbig 2020年11月17日

❤1

Celery: 継続的なメモリリーク

最も参考になるコメント

全てのコメント129件

----コーディング：utf-8 ----

関連する問題