Verwenden Sie Canvas-Workflows? Vielleicht ist # 4839 verwandt.

Ich gehe auch davon aus, dass Sie den Prefork-Pool für die Parallelität von Arbeitern verwenden.

Danke Georgepsarakis.

Ich verwende keinen Workflow.
Ich verwende Prefork Concurrency 1 auf einem einzelnen Server.

Die Steigerungsrate scheint ziemlich linear, ziemlich seltsam. Verarbeitet der Arbeiter in diesem Zeitraum Aufgaben? Können Sie auch eine Notiz mit dem vollständigen Befehl hinzufügen, mit dem Sie den Worker starten?

Ja. Der Mitarbeiter verarbeitet die Aufgabe weiterhin normal.

Der Worker wird mit dem folgenden Befehl gestartet.

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

Dieses Problem tritt sowohl in der Produktionsumgebung als auch in der Testumgebung auf.
Ich kann der Testumgebung ein Speicherprofil und eine Testausgabe hinzufügen.
Wenn ich etwas tun kann, sagen Sie bitte etwas.

Wir müssen verstehen, was der Worker während der Zeit ausführt, in der der Speicheranstieg beobachtet wird. Alle Informationen und Details, die Sie möglicherweise zur Verfügung stellen können, würden definitiv. Es ist auch gut, dass Sie dies reproduzieren können.

Obwohl es sich um einen Fall handelte, der zu einem vom Diagramm abweichenden Zeitpunkt auftrat, wurde das nächste Protokoll zu dem Zeitpunkt ausgegeben, als der Speicherverlust begann.

[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

Es scheint, dass es aufgetreten ist, als die Verbindung mit RabbitMQ vorübergehend unterbrochen wurde.

@marvelph also tritt es bei RabbitMQ-Wiederverbindungen auf? Vielleicht hängen diese Probleme zusammen:

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

Ja.
Es scheint, dass eine erneute Verbindung dies auslöst.

Es sieht so aus, als hätte ich das gleiche Problem ... Es ist so schwer für mich herauszufinden, was es auslöst und warum es ein Erinnerungsleck gibt. Es nervt mich mindestens einen Monat lang. Ich greife auf gebrauchten Sellerie 3 zurück und alles ist in Ordnung.

Für das Problem mit Speicherverlusten verwende ich Ubuntu 16, Sellerie 4.1.0 mit rabbitmq. Ich habe es über Docker bereitgestellt.

Der Speicherverlust tritt bei MainProcess und nicht bei ForkPoolWorker auf. Die Speichernutzung von ForkPoolWorker ist normal, aber die Speichernutzung von MainProcess nimmt ständig zu. Für fünf Sekunden ist ungefähr 0,1 MB Speicher durchgesickert. Der Speicherverlust beginnt nicht sofort nach Arbeitsbeginn, sondern möglicherweise nach ein oder zwei Tagen.

Ich habe gdb und pyrasite verwendet, um den laufenden Prozess zu injizieren und zu versuchen, gc.collect() , aber nichts wird gesammelt.

Ich habe das Protokoll überprüft, das consumer: Connection to broker lost. Trying to re-establish the connection... passiert, aber im Moment bin ich mir nicht sicher, ob dies der Zeitpunkt ist, an dem Speicherverlust auftritt.

Irgendwelche Tipps zum Debuggen dieses Problems und um herauszufinden, was wirklich passiert? Vielen Dank.

Da @marvelph erwähnt hat, dass dies möglicherweise mit der Wiederverbindung von rabbitmq zusammenhängt, versuche ich, meinen rabbitmq-Server zu stoppen. Die Speichernutzung hat nach jeder erneuten Verbindung zugenommen. Es folgt das Protokoll. Daher kann ich dieses Problem mit https://github.com/celery/kombu/issues/843 bestätigen.

Nachdem die Verbindung wieder hergestellt wurde, stoppt die Speichernutzung und steigt allmählich an. Ich bin mir also nicht sicher, ob dies der Grund für einen Speicherverlust ist.

Ich werde versuchen, mit redis herauszufinden, ob dieses Problem mit dem Speicherverlust mit rabbitmq zusammenhängt oder nicht.

[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

Obwohl ich die Protokolle überprüft habe, habe ich zum Zeitpunkt des Speicherverlusts ein Protokoll der erneuten Verbindung gefunden, aber es gab auch einen Fall, in dem ein Speicherverlust zum Zeitpunkt des erneuten Verbindens begann.
Ich stimme der Idee von jxlton zu.

Als ich Sellerie 3.x verwendete, stieß ich auch nicht auf ein solches Problem.

selbes Problem hier

Alle paar Tage muss ich die Arbeiter wegen dieses Problems neu starten
Es gibt keine signifikanten Hinweise in Protokollen, aber ich habe den Verdacht, dass sich Wiederverbindungen auswirken können. da ich Protokolleinträge irgendwo in der Zeit wieder verbinden muss, wenn der Speicher ständig wächst
Meine Conf ist Ubuntu 17, 1 Server - 1 Worker mit 3 Parallelität; Kaninchen und Redis im Backend; Alle Pakete sind die neuesten Versionen

@marvelph @ dmitry-kostin Könnten Sie bitte Ihre genaue Konfiguration (natürlich ohne vertrauliche Informationen) und möglicherweise eine Aufgabe oder ein Beispiel angeben, die das Problem reproduziert? Haben Sie auch eine Schätzung des durchschnittlichen Verfügbarkeitsintervalls, in dem die Erhöhung des Arbeitsspeichers auftritt?

Die Konfiguration befindet sich in der Nähe der Standardeinstellung

imports = ('app.tasks',)
result_persistent = True
task_ignore_result = False
task_acks_late = True
worker_concurrency = 3
worker_prefetch_multiplier = 4
enable_utc = True
Zeitzone = 'Europa / Moskau'
broker_transport_options = {'sichtbarkeitszeitlimit': 3600, 'bestätige_veröffentlichung': True, 'fanout_prefix': True, 'fanout_patterns': True}

Grundsätzlich handelt es sich um einen neu bereitgestellten Knoten. es wurde am 21.06.18-50 eingesetzt; starrte um 05/00 um 6/23 zu wachsen und stürzte schließlich um 23-00 um 6/23 ab

Die Aufgabe ist ziemlich einfach und es gibt dort keine Superlogik. Ich denke, ich kann die ganze Situation auf einem klaren temporären Projekt reproduzieren, habe aber vorerst keine freie Zeit. Wenn ich Glück habe, werde ich versuchen, am Wochenende ein vollständiges Beispiel zu machen

UPD
Wie Sie sehen können, verbraucht die Aufgabe selbst etwas Speicher. Sie können dies anhand von Spitzen in der Grafik sehen, aber zu dem Zeitpunkt, als der Speicher leckte, wurden keine Aufgaben oder andere Aktivitäten erstellt

@marvelph @ dmitry-kostin @jxltom Mir ist aufgefallen, dass Sie Python3 verwenden. Würde es Ihnen etwas ausmachen , aktivieren ? Möglicherweise müssen Sie den Worker-Prozess patchen, um die Speicherzuordnungsspuren zu protokollieren. Lassen Sie mich wissen, wenn Sie dabei Hilfe benötigen.

@georgepsarakis Sie meinen, Tracemalloc in Worker- und Protokollstatistiken wie den Top-10-Dateien für die Speichernutzung in einem bestimmten Intervall wie 5 Minuten zu aktivieren?

@jxltom Ich denke, so etwas würde helfen, den verantwortlichen Teil des Codes zu finden. Was denkst du?

@georgepsarakis Ich habe versucht, gdb und https://github.com/lmacken/pyrasite zu verwenden, um den Speicherleckprozess zu injizieren und das Debuggen über tracemalloc zu starten. Hier ist die Top 10-Datei mit der höchsten Mem-Nutzung.

Ich benutze resource.getrusage(resource.RUSAGE_SELF).ru_maxrss / 1024 und die Speichernutzung nimmt tatsächlich allmählich zu.

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

Hier ist der Unterschied zwischen zwei Schnappschüssen nach ca. 5 Minuten.

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

Irgendwelche Vorschläge, wie Sie dies weiterhin debuggen können? Ich habe keine Ahnung, wie ich vorgehen soll. Vielen Dank.

@georgepsarakis

Ich möchte ein wenig Zeit, um das Projekt für die Reproduktion auszuschneiden.

Es ist Einstellung von Sellerie.

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

Der Scheduler hat die folgenden Einstellungen.

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),
    },
}

Auf EC 2 verwende ich Supervisord, um es zu bedienen.

@georgepsarakis
Da meine Testumgebung Leistungseinbußen tolerieren kann, können Sie tracemalloc verwenden.
Können Sie einen gepatchten Sellerie erstellen, um die Speichernutzung zu sichern?

@jxltom Ich wette, Tracemalloc mit 5 Minuten wird nicht helfen, das Problem zu lokalisieren
Zum Beispiel habe ich 5 Knoten und nur 3 von ihnen hatten dieses Problem in den letzten 4 Tagen und 2 haben die ganze Zeit gut funktioniert, so dass es sehr schwierig sein wird, das Problem zu finden.
Ich habe das Gefühl, dass es einen Schalter gibt, der sich einschaltet und dann wächst der Speicher, bis dieser Speicherverbrauch des Schalters sehr gut aussieht

Ich habe versucht herauszufinden, ob ähnliche Probleme bei anderen laufenden Systemen aufgetreten sind.
Die Häufigkeit des Auftretens variiert, aber auf drei Systemen mit Celery 4.x ist ein Speicherverlust aufgetreten, der auf einem System nicht aufgetreten ist.
Das System mit einem Speicherverlust ist Python 3.5.x, und das System ohne Speicherverlust ist Python 2.7.x.

@ dmitry-kostin Was ist der Unterschied zu den beiden anderen normalen Knoten? Verwenden beide denselben Rabbitmq als Broker?

Da in unserer Diskussion erwähnt wurde, dass es sich möglicherweise um rabbitmq handelt, habe ich einen anderen neuen Knoten mit derselben Konfiguration gestartet, außer dass stattdessen redis verwendet wurde. Bisher hat dieser Knoten nach 24 Stunden keinen Speicherverlust. Ich werde es hier posten, wenn es später einen Speicherverlust gibt

@marvelph Meinst du also, dass die drei Systeme mit Speicherverlust Python3 verwenden, während dasjenige, das in Ordnung ist, Python2 verwendet?

@jxltom überhaupt kein Unterschied, und ja, sie sind auf Python 3 & Rabit als Broker und Redis im Backend
Ich habe ein Testbeispiel erstellt, um dies zu reproduzieren. Wenn es in ein paar Tagen erfolgreich sein wird, gebe ich diesen Servern Anmeldeinformationen für jemanden, der weiß, wie man diesen Fehler findet

@jxltom
Ja.
In meiner Umgebung treten in Python 2 keine Probleme auf.

Ich habe den Speicherverlust über einen längeren Zeitraum über Tracemalloc verfolgt.

Die vom Modul resource gemeldete Startspeicherauslastung beträgt 146.58MB . Nach 3,5 Stunden wird angegeben, dass die Speichernutzung 224.21MB beträgt.

Es folgt die Momentaufnahme-Differenz, die von tracemalloc gemeldet wird

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

Irgendwelche Ideen? Es sieht so aus, als ob keine einzige Datei ausläuft.

Ich habe auch gc importiert und gc.collect() gibt 0 ...

@georgepsarakis Ich konnte dies reproduzieren und mich für Access Creds anpingen

Update: Ich habe den Broker von rabbitmq auf redis aktualisiert, indem ich die Broker-URL als Umgebungsvariable aktualisiere und Docker / Code vollständig gleich halte. Und es läuft 4 Tage und es gibt keinen Speicherverlust .

Daher glaube ich, dass dieses Problem mit dem rabbitmq-Broker zusammenhängt.

Versuchen Sie nach Möglichkeit, den hier genannten Benchmark-Befehl auszuführen: https://github.com/celery/celery/issues/2927#issuecomment -171455414

Auf diesem System werden Mitarbeiter mit 20 Servern ausgeführt.
Gestern ist ein Speicherverlust aufgetreten, der jedoch auf fast allen Servern gleichzeitig auftritt.

Ich weiß nicht, ob es verwandt ist, und lasse es hier, falls es hilft.

Ich habe ein anderes Problem mit Sellerie und Rabbitmq (Sellerie verliert die Verbindung und stellt die Verbindung mehrmals pro Sekunde wieder her. Die CPU geht zu 100% auf 1 Kern, Beat kann keine neuen Aufgaben senden, Sellerie muss neu gestartet werden).

Der Grund, warum ich dies hier melde, ist der Auslöser: Nach Tagen der Überwachung glaube ich, dass ich den Anfang des Problems gefunden habe und es scheint, als würde rabbitmq einige Nachrichten vom Speicher auf die Festplatte verschieben. Zu diesem Zeitpunkt versucht Sellerie, die Verbindung so schnell wie möglich wiederherzustellen, und in rabbitmq-Protokollen werden Dutzende von Verbindungs- / Trennungsvorgängen pro Sekunde in Chargen von jeweils etwa 10 Stück angezeigt. Ein Neustart von rabbitmq behebt das Problem nicht, ein Neustart von Sellerie behebt es sofort. Ich habe keine ordnungsgemäße Lösung, aber als Beispiel funktioniert das Festlegen einer Ablaufrichtlinie, die es Nachrichten ermöglicht, immer im Speicher zu bleiben, um das Problem herum und ich habe es seitdem nicht mehr gesehen.

Angesichts der Tatsache, dass einige Details dieses Problems mit dem übereinstimmen, was ich gesehen habe (das Austauschen von rabbitmq gegen redis behebt das Problem, es gibt keinen klaren Ausgangspunkt, es passiert auf mehr als einem Worker / Server gleichzeitig). Ich denke, es könnte einen gemeinsamen Auslöser geben und es könnte sein sei das gleiche, das ich entdeckt habe.

Die Testsuite wurde von https://github.com/celery/celery/tree/master/funtests/stress in https://github.com/celery/cyanide geändert und unterstützt nur Python2.

Also führe ich es in Python2 mit rabbitmq als Broker aus. Es wurden !join: connection lost: error(104, 'Connection reset by peer') . Hängt dies mit dem Problem des Speicherverlusts zusammen?

Hier ist das Protokoll für die Testsuite.

➜  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

Hier ist das Protokoll für den Arbeiter.

➜  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') !

Ich habe aktualisiert, um Sellerie 3.1.25 mit der gleichen Stresstestsuite zu verwenden, alles ist in Ordnung.

Übrigens Für alle, die nach einer schnellen Lösung suchen - das Ersetzen von Kaninchen durch Redis löst das Problem, wie @jxltom vorgeschlagen hat. Ich habe erst jetzt mehr als eine Woche stabile Arbeit mit Redis
Das Problem liegt also definitiv irgendwo in der Nähe der Kaninchen-Sellerie-Grenze

@dieeasy wir haben das gleiche Problem erlebt. Ich gehe davon aus, dass Sie das RPC-Ergebnis-Backend verwenden. Versuchen Sie in diesem Fall, zum DB-Ergebnis-Backend zu wechseln, und prüfen Sie, ob dies hilfreich ist. Das Problem, das dies verursacht, ist: https://github.com/celery/kombu/pull/779 und wird hier erläutert: https://github.com/celery/kombu/pull/779#discussion_r134961611

Ich habe das gleiche Problem Speicherverlust
Erinnerung

Ausführung
Python 3.6.5 Sellerie 4.2.1 Backend redis Broker rabbitmq

Konfig

[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

- - Codierung: utf-8 - -

aus der Kombu-Import-Warteschlange, Exchange
aus oslo_log Protokoll als Protokollierung importieren

aus app.conf importieren CONF

LOG = logging.getLogger (__ name__)

celery_queues = (
Warteschlange ('im', exchange = Exchange ('Absender'), routing_key = 'im'),
Warteschlange ('sms', exchange = Exchange ('Absender'), routing_key = 'sms'),
Warteschlange ('mail', exchange = Exchange ('Absender'), routing_key = 'mail'),
Warteschlange ('ivr', exchange = Exchange ('Absender'), 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': Sellerie_routen
}}

**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())

Bei Bedarf kann ich weitere Informationen bereitstellen.

Für das, was es wert ist, habe ich dieses Problem und kann es konsistent reproduzieren, indem ich die Rabbitmq-Verwaltungskonsole öffne, zu Verbindungen gehe und Verbindungen mit dem Verkehr von Sellerie zu Rabbitmq schließe.

Ich habe mit Sellerie 4.1 und 4.2 und rabbitmq 3.7.7-1 getestet
BEARBEITEN: auch Python Version 3.6.5 und das Ubuntu 16.04 (AWS EC2 Image)

Ich habe ein Speicherleck mit Sellerie 4.2.1 und Redis Broker. Der Speicher wächst in 3 Stunden von 100 MiB auf 500 MiB (begrenzt), und die Arbeiter werden in der Blüte als offline markiert. Sowohl der Prefork-Pool als auch das Gevent weisen dasselbe Problem auf.

@yifeikong dies ist möglicherweise nicht das gleiche Problem, aber könnten Sie für Ihren Fall bitte die vorgeschlagene Lösung https://github.com/celery/celery/pull/4839#issuecomment -447739820 ausprobieren?

@georgepsarakis Ich verwende Python 3.6.5, daher bin ich von diesem Fehler nicht betroffen. Ich werde Tracemalloc verwenden, um Nachforschungen anzustellen. Wenn es ein Sellerie-Bug war, werde ich eine neue Ausgabe eröffnen. Vielen Dank

Möglicherweise die gleiche Ursache mit # 5047 , es scheint, dass dieser Fehler zu einem anderen Phänomen führen kann.

Wir haben das gleiche Speicherleck mit Celery 4.2.1, Kombu 4.2.2 und Python3.6 mit RabbitMQ als Broker.

$ 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

Ich kann sagen, wir haben viele Dinge ausprobiert, die andere als mögliche Problemumgehungen erwähnt haben (Redis als Broker, mit Jemalloc, Libamqp, Affenpfad __del__ auf AsyncResult ), aber wir haben immer Speicher verloren.

Bei der Analyse unseres Protokolls stellten wir fest, dass wir viele Nachrichten hatten, die sich auf verpasste Herzschläge durch Klatsch bezogen.

{"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@******"}

Eine letzte Sache, die wir versucht haben, war das Deaktivieren von Klatsch, indem die Arbeiter mit --without-gossip wurden. Überraschenderweise hatte das Deaktivieren von Klatsch eine sofortige Wirkung.

Sie können es hier sehen:

Seit wir den Klatsch in zwei Projekten mit Sellerie-Arbeitern deaktiviert haben, hat sich der Speicherverbrauch verbessert.

Wenn Sie aufpassen, bevor wir ähnliche Speicherspitzen hatten, wie hier beschrieben, https://github.com/celery/celery/issues/4843#issuecomment -399833781

Eine Sache, die ich zu verstehen versucht habe, ist, welche Auswirkungen es hat, Klatsch und Tratsch vollständig zu deaktivieren, da es nur als Arbeiterkommunikation bezeichnet wird. Wenn jemand etwas Licht ins Dunkel bringen könnte, wäre ich sehr dankbar.

Hoffe das hilft und danke für die harte Arbeit.

Warum wurde dieses Problem geschlossen?

Es gibt aktives Feedback und Interesse an dieser Ausgabe, daher öffne ich sie wieder.

Nun, @georgepsarakis, da wir diagnostiziert haben, dass mein Leck nicht # 4839 ist und Sie vermutet haben, dass es # 4843 ist, werde ich zumindest vorerst zu diesem Leck-Thread wechseln. Ich bin mir auch nicht sicher, ob # 4843 mein Leck ist. Nach der ersten Ausgabe in diesem Thread:

Dieses Problem tritt zumindest in Sellerie 4.1 und auch in Sellerie 4.2 auf.
Sellerie läuft unter Ubuntu 16 und Broker verwenden RabbitMQ.

Ich bin derzeit auf:

Python 2.7.12
Ubuntu 16.04.1 amd64
RabbitMQ 3.7.5

mit:

Sellerie 4.1.1
librabbitmq 2.0.0
amqp 2.4.0
Rebe 1.1.4
Billard 3.5.0.5
kombu 4.2.2.post1
gevent 1.2.2

Sellerie 4.1.1 + gevent 1.2.2 leckt für mich jedoch nicht (und Sellerie 3.1.25 + gevent 1.2.2 AFAICT auch nicht); Sellerie 4.2.1 + gevent 1.3.7 tut. Leider sind gevent 1.3.7 und gevent 1.2.2 nicht austauschbar, um eine gevent-Bibliothek als mögliche Ursache des Problems zu demonstrieren (oder auszuschließen).

EDIT: Hmm ... es scheint einen Gevent-Patch (022f447dd) zu geben, der den Fehler beheben könnte, auf den ich gestoßen bin. Ich werde versuchen, das zum Laufen zu bringen.

Ich habe 022f447 auf Celery 4.1.1 angewendet und gevent 1.3.7 installiert. Diese Kombination aus Sellerie und Gevent lief ... und erzeugte Speichernutzungsmuster, die mit dem Leck übereinstimmen, das ich erlebt habe. Ich werde Celery 4.2.1 + gevent 1.2.2 (mit dem umgekehrten Patch) installieren und prüfen, ob ich das übliche Speichernutzungsmuster erhalte.

Ich stelle fest, dass gevent 1.4.0 raus ist. Vielleicht sollte ich das auch versuchen, um zu sehen, wie sich das verhält.

Sellerie 4.2.1 + gevent 1.2.2 + Reverse Patch für gevent 1.2.2 scheint das Leck nicht zu erzeugen, ebenso wie Sellerie 4.2.1 + gevent 1.3.7.

Sellerie 4.2.1 + gevent 1.4.0 scheint ungefähr mit der gleichen Rate zu lecken wie 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.

Wenn ich jetzt richtig verstehe, was AMQP unter der Haube tut, hat es seinen eigenen Herzschlag und wenn es eine unterbrochene Verbindung erkennt, geht es voran und verbindet sich wieder unter der Haube. Abhängig von den aktivierten Ereignistypen (Klatsch, Herzschlag) kann dies ziemlich schnell auslaufen.
Dies sollte für jede Version von eventlet & gevent gelten, aber einige können Verbindungsprobleme aufweisen, die die Situation verschlimmern / deutlicher machen.

Hallo,

Ich vermute, dass wir das gleiche Problem haben.
Unsere Konfiguration ist unten. Kann ich entweder negieren oder bestätigen, dass dies das gleiche Problem ist, das hier diskutiert wird?

Python: 2.7
Sellerie: 4.2.1
Betriebssystem: CentOS Release 6.10
Redis als Makler

Im angehängten Bild sehen Sie:

1. Der Speicherverbrauch steigt ständig und sinkt beim Neustart.
2. Am 13. Januar haben wir ein Upgrade von Sellerie 3.1.25 auf 4.2.1 durchgeführt. Der Speicherverbrauch nimmt mit zunehmendem Tempo zu.

AKTUALISIEREN

Unabhängig von diesem Problem haben wir ein Upgrade auf Python 3.6 durchgeführt und seitdem scheint das Leck nicht mehr aufzutreten.

(Das Upgrade war am 19. Februar)

@georgepsarakis

Ich bin mir nicht sicher, wie relevant dies ist, aber ich habe meine 2 GB SWAP-Speicherplatz durch Sellerie in der Produktion erschöpft. Das Stoppen von Flower löschte die Erinnerung nicht, das Stoppen von Sellerie jedoch.

könnte jemand Sellerie 4.3rc1 versuchen?

@auvipy Ich habe Celery 4.3.0rc1 + gevent 1.4.0 installiert. pip verbesserte Billard auf 3.6.0.0 und kombu 4.3.0.

Ein bisschen verwirrt, dass Vine 1.2.0 nicht auch vom rc1-Paket benötigt wurde, da # 4839 durch dieses Upgrade behoben wurde.

Wie auch immer, Sellerie 4.3.0 rc1 scheint in Ordnung zu sein.

@ ldav1s vielen Dank für das Feedback. Wein wird also tatsächlich als Abhängigkeit in vine installiert, in vorhandenen Installationen ist dies jedoch möglicherweise nicht der Fall.

@thedrow Vielleicht sollten wir die Abhängigkeit auch in den Sellerie-Anforderungen deklarieren?

Lassen Sie uns ein Problem darüber eröffnen und dort diskutieren.

Sellerie 4.3.0rc1 + gevent 1.4.0 läuft seit einigen Tagen. Sieht so aus, als ob es auf die gleiche Weise wie Sellerie 4.2.1 + gevent 1.4.0 leckt.

Das gleiche Leck mit Sellerie 4.2.1, Python 3.6

Irgendwelche Updates dazu?

hier das gleiche Problem haben

Schöne Grüße,

Ich habe ein ähnliches Problem, bin mir aber nicht sicher, ob es dasselbe ist.

Nachdem ich unsere Sellerie-App in eine andere Umgebung / ein anderes Netzwerk migriert hatte, begannen Sellerie-Mitarbeiter zu lecken. Zuvor befanden sich die Sellerieanwendung und die rabbitmq-Instanz in derselben Umgebung / demselben Netzwerk.

Meine Konfiguration ist auf 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)

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

Die Anwendung besteht aus mehreren Mitarbeitern mit Eventlet-Pool, die über den Befehl in Supervisord gestartet werden:

[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

Das Speicherleckverhalten sieht so aus, alle ~ 10 Stunden normalerweise 1 Arbeiter, max 2 beginnen zu lecken:

Daher habe ich eine Broadcast-Nachricht erstellt, die für jeden Worker ausgeführt werden soll. Für die Verwendung von tracemalloc ist dies das Ergebnis des obersten Befehls auf dem Computer. Es gibt nur 1 Worker, der mit 1464 m leckt:

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 Ergebnisse auf dem undichten Arbeiter

[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

TOP 1 mit 25 Frames

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)

Ich hoffe, es könnte helfen, es gibt keinen Fehler in den Protokollen, außer dem verpassten Herzschlag zwischen den Arbeitern. Jetzt versuche ich, die genaue Version der Bibliotheken zu verwenden, die wir in der alten Umgebung verwendet haben.

UPDATE: Unter Verwendung der gleichen exakten Abhängigkeiten lib-Versionen und eines Broker-Heartbeat alle 5 Minuten sah die Anwendung für längere Zeit stabil aus: mehr als 2 Tage, als sie erneut durchgesickert war.

Es gab kleine Spitzen, die von Zeit zu Zeit ~ 1 Stunde lang andauerten, aber die wurden "absorbiert / gesammelt". Die letzte sieht so aus, als hätte die Spitze begonnen.

Nach der ersten Spitze, der ersten Rampe, habe ich den undichten Arbeiter neu gestartet. Wie Sie sehen können, begann ein anderer Arbeiter zu lecken, oder wahrscheinlich war es bereits undicht, die zweite Rampe.

Ich werde ohne Herzschlag testen.

UPDATE: ohne Herzschlag nach 2 Tagen wieder durchgesickert, gleiches Verhalten

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

AKTUALISIEREN:
Mit Sellerie 4.3.0 scheint das Problem behoben zu sein und es ist seit einer Woche stabil

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)

Bitte lassen Sie mich wissen, ob ich irgendwie helfen könnte, den Code zu instrumentieren. Falls erforderlich, geben Sie bitte Links und Beispiele an.

Vielen Dank

Ich habe auch ein Speicherleck. Es sieht so aus, als hätte ich es geschafft, die Ursache zu finden.
https://github.com/celery/celery/blob/master/celery/events/dispatcher.py#L75
Ich kann sehen, dass dieser Puffer nach Verbindungsproblemen mit Kaninchen zu wachsen beginnt. Ich verstehe nicht, warum es letztendlich nicht gelingt, Ereignisse zu löschen, es wächst im Laufe der Zeit weiter und verbraucht immer mehr RAM. Das Übergeben von buffer_while_offline=False hier https://github.com/celery/celery/blob/master/celery/worker/consumer/events.py#L43 scheint das Leck für mich zu beheben. Kann jemand bitte überprüfen, ob dies verwandt ist?

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

@ yevhen-m vielen Dank! Das hat uns geholfen, den Speicherverlust zu beheben!

Es ist gut, dass wir eine Problemumgehung haben, aber können wir bitte eine geeignete Lösung finden?

Folgen Sie diesem Problem mit dem Speicherverlust

Ich verwende Sellerie in einer Produktionsumgebung und stelle ihn über Docker bereit.
Wie der Screenshot haben wir das gleiche Problem.
Unsere Produktionskonfiguration ist unten dargestellt.

Übergeordnetes Docker-Image: Python 3.6.8-Buster
Sellerieversion: 4.2.0
Befehlsoptionen:

• Parallelität 4
• Prefetch-Multiplikator 8
• Kein result_backend
• acks_late und reverse_on_worker_lost

Ich frage mich, ob ein Upgrade der Sellerieversion auf 4.3.0 das Problem des Speicherverlusts löst.

Vielen Dank!

Sellerie 4.4.0 ist der neueste Stall

Team, gibt es ein Update zu diesem Problem? Wurde dies in Sellerie 4.4.0 angesprochen und behoben?

Team, gibt es ein Update zu diesem Problem? Wurde dies in Sellerie 4.4.0 angesprochen und behoben?

Unglücklicherweise nicht. Es ist jetzt angesprochen.

Team, gibt es ein Update zu diesem Problem? Wurde dies in Sellerie 4.4.0 angesprochen und behoben?

es wird am 4.4.1 verfügbar sein

es wird am 4.4.1 verfügbar sein

ist es in der aktuellen Version 4.4.1 behoben?

@auvipy Das Problem ist in Sellerie 4.4.2 und 4.4.6 immer noch vorhanden. Wir sehen bei allen Arbeitern die gleichen Speicherlecks.

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

Sellerie-Arbeiter wird mit -O fair --without-heartbeat --without-gossip -c 1 -l -Flaggen gestartet. Wir verwenden auch die Flags -n und -Q , um den Namen und die Warteschlangen der Mitarbeiter festzulegen. Läuft im Prefork-Modus. Redis als sowohl Broker als auch Ergebnisspeicher konfiguriert.

~ Wir sehen viele verpasste Herzschläge bei lang laufenden Aufgaben. Das in verknüpften Problemen gemeldete Problem besteht also weiterhin. ~

Das Gleiche gilt für behinderte Herzschläge.

@jsynowiec Als ich mit diesem Problem konfrontiert wurde, funktionierte das einzige, was für mich funktionierte, das Ausführen der Mitarbeiter mit deaktiviertem Klatsch. Ich erwähnte hier etwas darüber https://github.com/celery/celery/issues/4843#issuecomment -459789086

Wir haben das gleiche Problem mit Sellerie 4.4.2 und Redis als Broker. Über einen Zeitraum von 48 Stunden verbraucht Sellerie bis zu 60 GB RAM, bis schließlich der Speicher knapp wird.
Keine der hier genannten Lösungen hatte Auswirkungen auf dieses Verhalten.

Wir haben das gleiche Problem mit Sellerie 4.4.2 und Redis als Broker. Über einen Zeitraum von 48 Stunden verbraucht Sellerie bis zu 60 GB RAM, bis schließlich der Speicher knapp wird.
Keine der hier genannten Lösungen hatte Auswirkungen auf dieses Verhalten.

Haben Sie unsere neueste Patch-Version ausprobiert?
Haben Sie die gleichen Bedingungen wie beim OP?

In Version 4.4.6 sind immer noch Speicherlecks vorhanden. Wir führen Worker mit Einstellungen aus, die in einem früheren Kommentar aufgeführt sind . OP verwendet RabbitMQ, wir verwenden Redis als Broker.

+1, wobei festgestellt wird, dass die Speichernutzung innerhalb von 24 Stunden allmählich zunimmt, selbst wenn nur minimale Arbeit erledigt wird. Ich denke, dieses Thema sollte wieder geöffnet werden.

Können Sie die Wurzel Ihres Speicherverlusts profilieren und herausfinden?

In Version 4.4.6 sind immer noch Speicherlecks vorhanden. Wir führen Worker mit Einstellungen aus, die in einem früheren Kommentar aufgeführt sind . OP verwendet RabbitMQ, wir verwenden Redis als Broker.

Es scheint, dass dies ein anderes Problem ist oder dass unser Fix nicht korrekt war.
Da dies das Problem des OP gelöst hat, ist es wahrscheinlich ein anderes Problem, oder?

[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 Client leckt Speicher? Ich verwende Sellerie v4.4.6 mit gevent, redis als Broker und ohne Ergebnis-Backend.

Vielleicht ist das auch ein Problem. Vielleicht ist es in gevent?
CC @jamadden @andymccurdy
Können Sie uns bitte helfen, dieses Problem zu beheben und sicherzustellen, dass kein Speicher an Ihrem Ende verloren geht?

Vielleicht ist es in gevent?

Wir verwenden nicht gevent . Worker werden mit Parallelität = 1 und Prefork gestartet.

Hallo Leute, ich bin mir nicht sicher, warum dieses Problem geschlossen ist. Wir haben dieses Problem seit 2 Jahren, aktualisieren jedes Mal auf die letzte Version von Celery und haben immer noch große Server (64-128 GB RAM), denen ständig der RAM ausgeht, weil dieser Speicherleckprobleme.

Gibt es eine Problemumgehung, ohne ein Downgrade auf Celery 3 durchzuführen oder Rabbitmq zu ersetzen?

Dies macht Sellerie in Produktionsumgebungen völlig instabil. Ich hoffe, es kann behoben werden. Wir können kein Downgrade auf Sellerie 3 durchführen. Daher planen wir, auf eine andere Lösung (möglicherweise Dramatiq) umzusteigen, um uns keine Sorgen mehr darüber zu machen, dass Sellerie den gesamten RAM des Servers verschlingt Produktion alle 2 Tage.

@arielcamino - Ich habe die Einstellung worker_max_tasks_per_child verwendet , um Worker-Instanzen nach 100 ~ Aufgaben zu ersetzen, was dazu beigetragen hat, die Speichernutzung zumindest für meine Server aufrechtzuerhalten. Ich verwende winzige Instanzen von 512 MB und dies hat geholfen (zuvor würde mein RAM erschöpft sein), also wird es Ihnen vielleicht helfen.

@ Skowt wow, das ist super hilfreich, vielen Dank! Ich werde es gleich versuchen.

@arielcamino - Ich habe die Einstellung worker_max_tasks_per_child verwendet , um Worker-Instanzen nach 100 ~ Aufgaben zu ersetzen, was dazu beigetragen hat, die Speichernutzung zumindest für meine Server aufrechtzuerhalten. Ich verwende winzige Instanzen von 512 MB und dies hat geholfen (zuvor würde mein RAM erschöpft sein), also wird es Ihnen vielleicht helfen.

Vielen Dank, dass Sie uns Ihre Problemumgehung mitgeteilt haben. Dies hat hier nicht geholfen - wir verwenden jedoch Redis.

@thedrow Mir sind keine Speicherlecks in redis-py bekannt. Wenn redis-py ein Leck hatte, gehe ich davon aus, dass jemand außerhalb der Sellerie-Umgebung darauf gestoßen wäre und es dem redis-py Issue Tracker gemeldet hätte.

Gerne helfe ich, wo ich kann (ich verwende Celery mit Redis als Broker für mehrere Projekte), aber ich habe dieses Problem in meinen Bereitstellungen nicht festgestellt.

Mir sind keine Speicherlecks in aktuellen Versionen von gevent bekannt. Ich gehe davon aus (hoffe), dass jemand etwas gesagt hätte, wenn er darauf gestoßen wäre (es ist ein- oder zweimal zuvor passiert). Meine aktuellen Bereitstellungen von gevent haben mehrere Mitarbeiter (Web und Hintergrund), die wochenlang stark mit gevent arbeiten, und wir haben keine Speicherlecks festgestellt.

Hallo Leute, ich bin mir nicht sicher, warum dieses Problem geschlossen ist. Wir haben dieses Problem seit 2 Jahren, aktualisieren jedes Mal auf die letzte Version von Celery und haben immer noch große Server (64-128 GB RAM), denen ständig der RAM ausgeht, weil dieser Speicherleckprobleme.

Gibt es eine Problemumgehung, ohne ein Downgrade auf Celery 3 durchzuführen oder Rabbitmq zu ersetzen?

Dies macht Sellerie in Produktionsumgebungen völlig instabil. Ich hoffe, es kann behoben werden. Wir können kein Downgrade auf Sellerie 3 durchführen. Daher planen wir, auf eine andere Lösung (möglicherweise Dramatiq) umzusteigen, um uns keine Sorgen mehr darüber zu machen, dass Sellerie den gesamten RAM des Servers verschlingt Produktion alle 2 Tage.

Wie viele Arbeiter haben Sie? Wie viele Aufgaben führen Sie aus? Wie oft führen Sie diese Aufgaben aus und wie lange dauert es normalerweise, bis sie abgeschlossen sind?

Der Grund, warum Rabbitmq / Sellerie anfängt, viel RAM zu verwenden, kann mit der Anzahl der Aufgaben in der Warteschlange zusammenhängen. Wenn Sie zu viele Aufgaben in die Warteschlange stellen und die Mitarbeiter nicht alle Aufgaben ausführen können, wird die Warteschlange vergrößert, und in dieser Warteschlange wird immer mehr RAM verwendet, und schließlich wird der gesamte verfügbare RAM belegt. Ich glaube, dass dieses Problem auch bei Redis auftreten könnte.

Ich habe eine andere Theorie, aber zuerst möchte ich wissen, ob dies der Grund für Ihr Problem sein könnte.

@ardilom Entschuldigung, ich habe gerade festgestellt, dass wir keine RabbitMQ-Daten an datadog senden, aber ich werde versuchen, unsere Situation zu klären. So geht der RAM einiger Server alle 2 Tage aus:

Wir überprüfen immer die Anzahl der anstehenden Aufgaben und liegen normalerweise bei 0 (diese Daten stammen von vor einigen Tagen):

Wir führen ungefähr 250.000 Aufgaben pro Tag aus, wir haben ungefähr 10 Mitarbeiter, jeder mit ungefähr 4 bis 10 Parallelität, die durchschnittliche Laufzeit beträgt ungefähr 5 Sekunden, es hängt von der Art der Aufgabe ab.

Wir überprüfen messages_ready immer, um sicherzustellen, dass nicht zu viele Aufgaben in der Warteschlange stehen (dies sehen Sie im zweiten Bild). Ist es Ihrer Meinung nach in Ordnung, messages_ready zu messen? Wir haben schließlich einige Peaks, aber normalerweise liegen diese nahe bei 0.

Um das Problem zu lösen, starte ich den Sellerie-Worker einfach manuell neu und die RAM-Auslastung wird wieder normal.

Lassen Sie mich wissen, wenn Sie noch etwas benötigen. Ich habe gerade die Einstellung von worker_max_tasks_per_child auf einem der Aufgabenserver geändert, um

Vielen Dank!

Hallo Leute, dies soll bestätigen, dass das Ändern von worker_max_tasks_per_child in 1000 in meinem Fall das Problem behoben hat. Nochmals vielen Dank

Etwas, das ich gestern nicht erwähnt habe, ich verwende den "Prefork" -Modus. Vielleicht ist der Wechsel zu gevent eine andere Möglichkeit, das Problem zu beheben.

@arielcamino Dieses Problem wurde geschlossen, da wir einen bestimmten Speicherverlust behoben haben. Wir haben noch keine andere Ursache für den Speicherverlust gefunden. Wir wissen, dass es ein Problem gibt, aber wir wissen nicht, wie wir es reproduzieren sollen.
Wir brauchen jemanden mit Zugriff auf eine Produktionsumgebung, in der sich der Fehler reproduziert, um das Problem zu beheben.
Wenn wir keine haben, müssen wir feststellen, dass dieses Problem nicht behoben werden kann.

Hallo, können wir dieses Problem erneut öffnen? Wir haben ähnliche Lecks, bei Verwendung von Sellerie == 4.4.7 (mit rabbitmq) läuft der Arbeiter einige Stunden lang stabil, manchmal viel länger, und dann beginnt er plötzlich langsam zu lecken und verbraucht den gesamten Speicher.

Derzeit wird Prefork mit --concurrency=1 und dem Flag --max-tasks-per-child=100 was nicht zu helfen scheint, da der übergeordnete Prozess anscheinend undicht ist.

Ich kann weitere Informationen bereitstellen, um dieses Problem zu beheben.

Hallo, können wir dieses Problem erneut öffnen? Wir haben ähnliche Lecks, bei Verwendung von Sellerie == 4.4.7 (mit rabbitmq) läuft der Arbeiter einige Stunden lang stabil, manchmal viel länger, und dann beginnt er plötzlich langsam zu lecken und verbraucht den gesamten Speicher.

Derzeit wird Prefork mit --concurrency=1 und dem Flag --max-tasks-per-child=100 was nicht zu helfen scheint, da der übergeordnete Prozess anscheinend undicht ist.

Ich kann weitere Informationen bereitstellen, um dieses Problem zu beheben.

Die Wiedereröffnung des Problems ist keine große Sache, es ist das Interesse von jemandem, der sich in der Produktion damit auseinandersetzt und dabei hilft, eine Lösung zu finden und zumindest die Grundursache für das Leck in der Produktion herauszufinden.

Ich kann definitiv helfen, aber mir gingen die Ideen aus, was zu tun ist. Ich hatte ein paar Tools, konnte aber nicht viel über das Problem herausfinden. Das einzige, was es irgendwie einschränkt, sind die Tracemalloc-Schnappschüsse, die ich gemacht habe und die zeigen, dass der Speicher alle paar Minuten an denselben Stellen zunimmt. Dies sind die Top 10, die zwei Schnappschüsse vergleichen:

/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

Das Problem besteht weiterhin
Dies geschieht, wenn eine Sellerie-Task auf den App-Kontext zugreift, um eine Funktionalität auszuführen
Es wird nach Ausführung der Aufgabe nicht freigegeben oder entsorgt

--max-tasks-per-child=

war nicht hilfreich

Hallo, können wir dieses Problem erneut öffnen? Wir haben ähnliche Lecks, bei Verwendung von Sellerie == 4.4.7 (mit rabbitmq) läuft der Arbeiter einige Stunden lang stabil, manchmal viel länger, und dann beginnt er plötzlich langsam zu lecken und verbraucht den gesamten Speicher.
Derzeit wird Prefork mit --concurrency=1 und dem Flag --max-tasks-per-child=100 was nicht zu helfen scheint, da der übergeordnete Prozess anscheinend undicht ist.

Ich kann weitere Informationen bereitstellen, um dieses Problem zu beheben.

Die Wiedereröffnung des Problems ist keine große Sache, es ist das Interesse von jemandem, der sich in der Produktion damit auseinandersetzt und dabei hilft, eine Lösung zu finden und zumindest die Grundursache für das Leck in der Produktion herauszufinden.

Für mich funktioniert es, wenn ich --max-tasks-per-child hinzufüge.
Wie für diese Beispielargumente --autoscale=5,2 --max-tasks-per-child=40 das Ergebnis so

Obwohl ich glaube, dass ein kürzlich durchgeführtes Sellerie-Upgrade das Speicherleck eingeführt hat, kann ich nicht ganz sicher sein. Ich werde mitteilen, dass die folgende Einstellung das Leck behoben hat.

Ich kann in der Dokumentation nicht feststellen, welche Einstellungen gültig sind. Daher stelle ich alle diese Werte in meiner Django-Einstellungsdatei ein.

CELERY_CONCURRENCY = CELERY_WORKER_CONCURRENCY = 1
CELERY_MAX_TASKS_PER_CHILD = CELERY_WORKER_MAX_TASKS_PER_CHILD = 1

Dies löst nicht das Leck, das wir sehen, wie es auch im Gevent-Pool passiert. Was mir aufgefallen ist, dass wir die Sellerie-Warteschlange ziemlich voll haben. Da das Tracemalloc den Ereignisversand als eine der möglichen Quellen für das Leck angezeigt hat, habe ich Aufgabenereignisse explizit deaktiviert und unsere Blumeninstanz deaktiviert. Im Moment scheint es, dass das Leck nicht mehr auftritt. Ich werde es über das Wochenende laufen lassen und teilen die Ergebnisse hier.

Mögliche Ursachen für das Leck Ich habe Aufgabenereignisse explizit deaktiviert und unsere Blumeninstanz deaktiviert

Anekdotischer Datenpunkt von jemandem, der dieses Problem von Anfang an still beobachtet hat (und es nie direkt erlebt hat): Mir ist ein anderes Projekt bekannt (mit einer nicht unwesentlichen Arbeitsbelastung für Sellerie), bei dem das oben Genannte das gleiche Ergebnis hatte Stoppen eines Speicherverlusts. Da ich nur Informationen aus zweiter Hand habe, kann ich offensichtlich nicht bestätigen, dass es sich sogar um dasselbe zugrunde liegende Problem handelt (AFAIK, es war rabbitmq, keine Ahnung von gevent usw.), aber es ist interessant, dass es korreliert.

Ich vermute, es hat irgendwie etwas mit der rabbitmq-Verbindung zu tun, dem Stapel, den wir dieses Leck beobachtet haben:

• Sellerie (neueste Version): entweder Prefork oder Gevent Pool, beide zeigen das gleiche Leckmuster.
• rabbitmq (cloudamqp SaaS)
• Blume

Wir haben alle unsere Aufgaben auf Lecks überprüft und konnten keine Lecks finden. Deshalb habe ich den Verdacht, etwas auf Sellerieseite zu sein.

Eine interessante Tatsache ist, dass derzeit viele Arbeiter am Laufen sind, und ich habe festgestellt, dass, sobald man anfängt zu lecken, dies auch auf der Blume als offline angezeigt wird.

Da mir die Ideen ausgegangen sind, wo ich suchen soll, habe ich Blumen- und Aufgabenereignisse deaktiviert und werde weiterhin überwachen, ob das Leck zurückkommt oder nicht.

Ich bin offen zu glauben, dass es ein weiterer Teil meines Stapels ist, der an dieser Stelle Speicher verliert. Sellerie hatte in der Vergangenheit möglicherweise ein zufälliges Verhalten, das zur Kontrolle von Speicherlecks beitrug, aber wir alle zusammen scheinen nicht ähnliche Probleme zu haben, um dies zu bestätigen. Ich weiß, dass viele von uns entweder rennen ...

• Eine große Anzahl verschachtelter Aufgaben gleichzeitig oder
• Einige monolithische Elemente, die die Multi-Core-Verarbeitung innerhalb des Workers starten

In diesen Fällen müssen wir nur klug sein, wenn es darum geht, ein bestimmtes Maß an Parallelität, Aufgabenwarteschlangen und Aufgaben pro untergeordnetem Mitarbeiter zuzulassen oder nicht zuzulassen. Darüber hinaus sollten wir alle integrierte Sicherheitsvorkehrungen verwenden, die speicherhungrige Aufgaben beenden können, bevor sie die Möglichkeit haben, unsere Server zum Absturz zu bringen.

Eine zunehmende Anzahl von Menschen führt schwerfällige CPU-gebundene und speichergebundene Prozesse in Sellerie aus, für die es nicht wirklich gemacht war. Ich denke, die Schnellstartdokumentation sollte diesbezüglich detailliertere Informationen enthalten.

Wie bereits in meinen vorherigen Kommentaren erwähnt, führen wir Mitarbeiter aus, bei denen sowohl max-tasks-per-child als auch die Parallelität seit langer Zeit auf 1 eingestellt sind. Es tut nichts gegen Speicherverlust. Darüber hinaus verwenden wir Redis sowohl als Broker- als auch als Ergebnis-Backend.

Nach meinen Beobachtungen ist es bei Verwendung von max-tasks-per-child auf 1 , wenn RabbitMQ als Broker verwendet wird, höchstwahrscheinlich ein Problem bei der Aufgabenimplementierung, nicht bei Sellerie.

Was wir beobachten und berichten, ist anders. Selbst wenn wir den Mitarbeiter mehrere Tage lang im Leerlauf lassen, ohne eine einzelne Aufgabe zu verarbeiten, verliert er den Speicher bis zu einem Punkt, an dem er das Speicherlimit erreicht und vom Supervisor getötet wird. Weitere Details und Speicherdiagramme finden Sie in früheren Kommentaren.

Wenn der Worker eine einzelne Aufgabe termingerecht verarbeitet, sollte das Speicherdiagramm mehr oder weniger eine Rechteckwelle aufweisen. Sie können jedoch deutlich erkennen, dass die Gesamtspeicherauslastung nur zunimmt.

Ich habe es geschafft, die Profilerstellung von Sellerie-Arbeitern in unsere Roadmap aufzunehmen. Ich werde Speicherabbilder und weitere Details freigeben, wenn wir damit beginnen.

Ich kann bestätigen, dass das Ausschalten der Blume (und das explizite Deaktivieren von Aufgabenereignissen durch Einstellungen) das Leck behoben hat.

Wie ich bereits erwähnte, bemerkte ich in dem Moment, in dem der Arbeiter zu lecken begann, in der Blüte, dass es offline gehen würde und der Sellerieev immer ziemlich beschäftigt war, also ging ich den einfachen Weg durch und schaltete die Blume aus.

Leider konnte ich den Code, der das Leck verursacht, nicht finden. Aber zumindest gibt es diese Problemumgehung.

dann ist das wohl kein sellerieproblem sondern blume?

@auvipy Blume löst das Problem aus, aber das Leck tritt definitiv beim Arbeiter (Sellerie) auf

@auvipy Blume löst das Problem aus, aber das Leck tritt definitiv beim Arbeiter (Sellerie) auf

Meinetwegen. danke für das Teilen.

Ich verwende Sellerie mit Redis und Flower und muss sagen, dass derzeit keine Speicherprobleme auftreten. Was können Sie von mir in Bezug auf Daten wollen?

@auvipy verwendet keine Blume. Arbeiter werden mit deaktivierten Ereignissen gestartet.

@auvipy verwendet keine Blume. Arbeiter werden mit deaktivierten Ereignissen gestartet.

Bitte versuchen Sie zu debuggen und die Wurzel des Speicherverlusts herauszufinden. könnte Sellerie sein oder du könntest. Es ist am besten, wenn Sie Unit- und Integrationstests gemeinsam nutzen können

Bitte versuchen Sie zu debuggen und die Wurzel des Speicherverlusts herauszufinden. könnte Sellerie sein oder du könntest. Es ist am besten, wenn Sie Unit- und Integrationstests gemeinsam nutzen können

Erwähnt hier , dass wir OOMs sehen, weil Sellerie-Arbeiter Speicher verlieren, selbst wenn keine Aufgaben vom Arbeiter verarbeitet werden.
Einheiten- oder Integrationstests können nicht gemeinsam genutzt werden, da dies die IP des Unternehmens offenlegen würde. Es tut uns leid. Aber ich habe es geschafft, eine Aufgabe zum Erfassen von Speicherabbildern für Produktionsmitarbeiter in unserer internen Roadmap hinzuzufügen. Wird Zähler und Refs für einige Szenarien teilen, wenn es fertig ist.

@jsynowiec Wenn du es vor 5.0.0 GA

Sobald ein Bugfix im Master landet, wird er ebenfalls auf 4.x zurückportiert.

@thedrow Wann ist ein GA von 5,0 geplant? Leider haben wir einen Legacy-Code, der noch auf Py3 migriert werden soll. Daher bleiben wir vorerst bei Celery 4.

Wir haben einen Release-Blocker und einige Dokumentationen zu vervollständigen.
Die Antwort ist sehr bald.

Ich kann bestätigen, dass das Ausschalten der Blume das Leck stoppt. Wir sind jetzt fast einen Monat ohne Leck gelaufen.

Irgendwo in unserem Mechanismus zur Veröffentlichung von Ereignissen gibt es also immer noch einen Fehler.
Hat jemand eine Idee was es sein könnte?

Wir verwenden Flower nicht und Worker werden ohne --events gestartet, es treten jedoch kontinuierliche Speicherverluste auf.

Die Antwort ist sehr bald.

Ich habe es geschafft, Speicherauszüge und Objektzähler von Produktionsmitarbeitern mit hoher Priorität zu versehen. Ich sollte in den nächsten Wochen einige Daten veröffentlichen können. Wir haben auch die Priorität für die Fertigstellung der py2-> py3-Portierung erhöht, damit alles mit Python 3 ausgeführt und profiliert werden kann

Ich mache mir Sorgen, dass wir hier über zwei verschiedene Themen sprechen.

Anscheinend. Eine bezieht sich auf Ereignisse und vielleicht auf Flower, vielleicht auch auf RabbitMQ als Broker. Laut hier gemeldeten Problemen taucht es auf GitHub seit einigen Jahren hier und da auf. Die andere (die sich auf mein Projekt auswirkt) bezieht sich auf verschiedene Komponenten und höchstwahrscheinlich auf die Verwendung von Redis als Broker. Oder vielleicht an der Wurzel, das sind die gleichen Probleme, die aus dem gleichen Code stammen, der weiß, 🤷🏼. Wie die mit trail , die Unteraufgaben verfolgt und Instanzen von AsyncResult 😉 verliert

@thedrow @auvipy Ich möchte Sie nur wissen lassen, dass wir uns jetzt der Speicherprofilerstellung von Arbeitnehmern

Beim Abschluss der Python3-Migration ist ein weiteres Problem aufgetreten, das mit https://github.com/celery/celery/issues/4470 oder https://github.com/celery/celery/issues/5359 in Zusammenhang zu stehen scheint join_native unbestimmte Zeit, obwohl alle Aufgaben innerhalb der Gruppe bereits erledigt sind. Schneller Hinweis darauf, dass er buchstäblich beim Lesen hängt, was auf Kernel / Lib-Inhalte auf niedriger Ebene hinweisen könnte. Im Moment haben wir zu Plain gewechselt und join da wir uns auf Speicherlecks konzentrieren.

Hallo allerseits - endlich einige Daten: Sellerie-Memtrace-1.tar.xz , Unterschrift , mein Schlüssel .

Das Archiv enthält tracemalloc Protokolle von 8 Mitarbeitern nach ~ 16 Tagen, ein Diagramm zur Speichernutzung für den Zeitraum und einige Versionsinformationen (einschließlich des Sellerie-Startbanners).

Ich habe ehrlich gesagt keine nennenswerte Zeit damit verbracht, irgendetwas davon zu analysieren, aber a) unser Code war nie in der Liste, b) es kann auch eine seltsame Interaktion mit SQLAlchemy sein, die wir auch überall verwenden, so dass es nicht unmöglich ist, dass das Problem auftritt ist woanders oder es ist ein Kombinations- / Interaktionsproblem.

Wenn andere Details nützlich wären, fragen Sie bitte. Wir führen diese 8 Worker auch weiterhin mit dieser Protokollierung der Speichernutzung aus, damit möglicherweise mehr / bessere Daten erfasst werden können.

BEARBEITEN : Auch dieser Kommentar aus diesem Thread ist verwandt - wir verwenden immer noch die gleichen Einstellungen.

Ich hoffe, Sie finden die Hauptursache für dieses Leck.
Ich werde versuchen, mir etwas Zeit zu nehmen, um mich selbst damit zu beschäftigen.

Ich frage mich, ob dies dazu beitragen könnte, das Problem zu lösen.
https://reliability.substack.com/p/run-python-servers-more-efficiently

Wir untersuchen die Möglichkeit, dass der Speicherleckursprung in der Anforderungsbibliothek und nicht in Sellerie selbst liegt. Jemand anderes, bei dem Speicherverluste bei Sellerie aufgrund von Anforderungen in den Aufgaben auftreten?

@ErrorInPersona Ja, wir registrieren OOMs bei Mitarbeitern mit und ohne Anfragen gleichermaßen.

@drbig Hast du Glück?

Schauen Sie sich das "Grüne" an, der Boden steigt langsam aber sicher ... Abgesehen von einer schnellen Bestätigung von "Ja, es ist immer noch ein Problem", das ich leider nicht viel hinzufügen muss.

Allerdings habe ich den von @thedrow bereitgestellten Link To -Do-Liste (eine Grube ohne - try running some workers with jemalloc forced in , also werde ich _eventually_ darauf zurückkommen.