क्या आप कैनवास वर्कफ़्लोज़ का उपयोग कर रहे हैं? शायद # 4839 संबंधित है।

इसके अलावा, मुझे लगता है कि आप कार्यकर्ता संगरोध के लिए प्रीफ़ॉर्क पूल का उपयोग कर रहे हैं?

धन्यवाद जार्जपार्किस।

मैं वर्कफ़्लो का उपयोग नहीं कर रहा हूँ।
मैं सिंगल सर्वर पर प्रीफॉर्क कॉनक्योर 1 का उपयोग करता हूं।

वृद्धि दर काफी रैखिक, काफी अजीब लगती है। क्या इस समय के दौरान श्रमिक प्रसंस्करण कार्य करता है? इसके अलावा, क्या आप उस पूरी कमांड के साथ एक नोट जोड़ सकते हैं जिसका उपयोग आप कार्यकर्ता को शुरू करने के लिए कर रहे हैं?

हाँ। कार्यकर्ता सामान्य रूप से कार्य को संसाधित करना जारी रखता है।

कार्यकर्ता को निम्नलिखित कमांड के साथ शुरू किया जाता है।

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

यह समस्या उत्पादन वातावरण और परीक्षण वातावरण दोनों में हो रही है।
मैं परीक्षण वातावरण में मेमोरी प्रोफाइल और परीक्षण आउटपुट जोड़ सकता हूं।
अगर मुझे कुछ हो सकता है, तो कृपया कुछ कहें।

हमें यह समझने की आवश्यकता है कि उस समय के दौरान कार्यकर्ता क्या चल रहा है कि स्मृति में वृद्धि देखी गई है। आपके द्वारा प्रदान की जाने वाली कोई भी जानकारी और विवरण निश्चित रूप से प्रदान करेगा। यह भी अच्छा है कि आप इसे पुन: पेश कर सकते हैं।

हालाँकि यह ग्राफ़ से अलग समय पर होने वाला एक मामला था, मेमोरी रिसाव शुरू होने के समय अगला लॉग आउटपुट था।

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

ऐसा लगता है कि यह तब हुआ जब RabbitMQ के साथ कनेक्शन अस्थायी रूप से काट दिया गया था।

@marvelph तो यह RabbitMQ के

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

हाँ।
ऐसा लगता है कि सामंजस्य इसे ट्रिगर करता है।

ऐसा लगता है कि मेरे पास एक ही मुद्दा है ... मेरे लिए यह पता लगाना बहुत मुश्किल है कि यह क्या है और क्यों एक यादगार लीक है। यह मुझे कम से कम एक महीने के लिए परेशान करता है। मैं अजवाइन 3 का उपयोग करने के लिए वापस आ गया और सब कुछ ठीक है।

स्मृति रिसाव समस्या के लिए, मैं ubuntu 16, अजवाइन 4.1.0 का उपयोग खरगोश के साथ कर रहा हूं। मैंने इसे डॉकटर के माध्यम से तैनात किया।

मेमोरी लीक मेनप्रोसेस नहीं फोर्कपूलवॉकर के साथ है। ForkPoolWorker की मेमोरी का उपयोग सामान्य है, लेकिन मेनप्रोसेस की मेमोरी का उपयोग हमेशा बढ़ रहा है। पांच सेकंड के लिए, लगभग 0.1MB मेमरी लीक हुई है। स्मृति रिसाव काम शुरू होने के तुरंत बाद शुरू नहीं होता है, लेकिन शायद एक या दो दिनों के बाद।

मैंने रनिंग प्रक्रिया को इंजेक्ट करने के लिए gdb और pyrasite का उपयोग किया और gc.collect() , लेकिन कुछ भी एकत्र नहीं किया गया।

मैंने लॉग की जाँच की, consumer: Connection to broker lost. Trying to re-establish the connection... हुआ, लेकिन अभी के लिए मुझे यकीन नहीं है कि यह वह समय है जब मेमोरी लीक होती है।

इस मुद्दे को डीबग करने और वास्तव में क्या होता है यह पता लगाने के लिए कोई संकेत? धन्यवाद।

चूंकि @marvelph ने उल्लेख किया है कि यह खरगोश के पुन: संयोजन के साथ संबंधित हो सकता है, मैं अपने खरगोश सर्वर को रोकने की कोशिश करता हूं। प्रत्येक पुन: संयोजन के बाद मेमोरी उपयोग में वृद्धि हुई, निम्न लॉग है। इसलिए मैं इस https://github.com/celery/kombu/issues/843 मुद्दे की पुष्टि कर सकता हूं।

लेकिन कनेक्शन के फिर से जुड़ जाने के बाद, मेमोरी का उपयोग धीरे-धीरे बढ़ने के लिए रुक जाता है। इसलिए मुझे यकीन नहीं है कि यह मेमोरी लीक का कारण है।

मैं यह पता लगाने के लिए रेडिस का उपयोग करने की कोशिश करूंगा कि यह मेमोरी लीक मुद्दा wtih rabbitmq से संबंधित है या नहीं।

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

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

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

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

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

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

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

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

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

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

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

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

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

हालाँकि, मैंने लॉग की जाँच की, मुझे मेमोरी लीक के समय पुन: संयोजन का एक लॉग मिला, लेकिन एक ऐसा मामला भी था जहाँ एक मेमोरी लीक उस समय शुरू हुई जब पुनरावृत्ति नहीं हुई थी।
मैं jxlton के विचार से सहमत हूं।

इसके अलावा, जब मैं सेलेरी 3.x का उपयोग कर रहा था, तो मुझे इस तरह की समस्या का सामना नहीं करना पड़ा।

वही समस्या है

हर कुछ दिनों में मुझे इस समस्या के कारण श्रमिकों को फिर से शुरू करना पड़ता है
लॉग में कोई महत्वपूर्ण सुराग नहीं हैं, लेकिन मुझे संदेह है कि पुन: संयोजन प्रभावित कर सकता है; चूँकि मैंने लॉग एंट्रीज़ को समय में फिर से जोड़ दिया है जब मेमोरी लगातार बढ़ने लगती है
मेरा आत्मविश्वास ubuntu 17 है, 1 सर्वर - 1 कार्यकर्ता 3 संगामिति के साथ; खरगोश और बैकेंड पर रेडिस; सभी पैकेज नवीनतम संस्करण हैं

@marvelph @ dmitry-

डिफ़ॉल्ट करने के लिए पास है

आयात = ('app.tasks')
result_persistent = सत्य
task_ignore_result = गलत
task_acks_late = सत्य
worker_concurrency = 3
कार्यकर्ता_परिवर्तन_मूलिपी = ४
enable_utc = सही
समयक्षेत्र = 'यूरोप / मास्को'
ब्रोकर_ट्रांसपोर्ट_ओप्शंस = {'दृश्यता_ टाइमआउट': 3600, 'कन्फर्म_प्रकाश': सच, 'फैनआउट_परिवर्तन': सच, 'फैनआउट_पार्टन': सच}

मूल रूप से यह नया तैनात नोड है; इसे 06/21 18-50 पर तैनात किया गया था; 6/23 को 05-00 के आस-पास बढ़ने की कोशिश की और अंत में 6/23 को 23-00 के आसपास दुर्घटनाग्रस्त कर दिया

कार्य बहुत सरल है और वहाँ कोई सुपरलॉजिक नहीं है, मुझे लगता है कि मैं एक स्पष्ट अस्थायी परियोजना पर पूरी स्थिति को पुन: पेश कर सकता हूं, लेकिन अभी के लिए कोई खाली समय नहीं है, अगर मैं भाग्यशाली होगा तो मैं सप्ताहांत पर एक पूर्ण उदाहरण करने की कोशिश करूंगा

युपीडी
जैसा कि आप देख सकते हैं कि कार्य स्वयं कुछ मेमोरी का उपभोग करता है जिसे आप ग्राफ़ पर स्पाइक्स द्वारा देख सकते हैं, लेकिन वह समय जब मेमोरी लीक करने के लिए घूर रही थी कोई उत्पादन या कोई अन्य कार्य नहीं थे

@marvelph @ dmitry- kostin @jxltom मैंने देखा कि आप पायथन 3 का उपयोग करते हैं। क्या आप प्रक्रिया के लिए ट्रेसस्मॉलॉक को सक्षम करने का मन करेंगे? आपको मेमोरी आवंटन निशान को लॉग करने के लिए कार्यकर्ता प्रक्रिया को पैच करने की आवश्यकता हो सकती है, मुझे बताएं कि क्या आपको इसके साथ मदद की आवश्यकता है।

आप कार्यकर्ता में tracemalloc सक्षम और लॉग ऐसे शीर्ष 10 स्मृति उपयोग फ़ाइलों के रूप में आँकड़े, जैसे 5 मिनट के अंतराल पर एक विशिष्ट मतलब @georgepsarakis?

@jxltom मुझे लगता है कि कुछ ऐसा है जो कोड के उस भाग को खोजने में मदद करेगा जो जिम्मेदार है। तुम क्या सोचते हो?

@georgepsarakis I'v ने मेमोरी लीक प्रक्रिया को इंजेक्ट करने के लिए gdb और https://github.com/lmacken/pyrasite का उपयोग करने की कोशिश की, और ट्रेसमैलोक के माध्यम से डिबग शुरू किया। यहां सर्वोच्च मेम उपयोग के साथ शीर्ष 10 फ़ाइल है।

मैं resource.getrusage(resource.RUSAGE_SELF).ru_maxrss / 1024 उपयोग करता हूं और मेमोरी का उपयोग धीरे-धीरे वास्तव में बढ़ रहा है।

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

यहां लगभग 5 मिनट के बाद दो स्नैपशॉट के बीच अंतर है।

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

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

यह कैसे डिबग करने के लिए जारी रखने के लिए कोई सुझाव? मुझे आगे बढ़ने का कोई सुराग नहीं है। धन्यवाद।

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

ईसी 2 पर, मैं इसे संचालित करने के लिए पर्यवेक्षक का उपयोग कर रहा हूं।

@georgepsarakis
चूंकि मेरा परीक्षण वातावरण प्रदर्शन में गिरावट को सहन कर सकता है, आप ट्रेसमैलोक का उपयोग कर सकते हैं।
क्या आप मेमोरी उपयोग को डंप करने के लिए गद्देदार अजवाइन बना सकते हैं?

@jxltom I समस्या का पता लगाने में मदद के लिए 5 मिनट के साथ ट्रेसमॉलोक शर्त लगाता है
उदाहरण के लिए मेरे पास 5 नोड्स हैं और उनमें से केवल 3 में पिछले 4 दिनों से यह समस्या थी, और 2 ने इस बार ठीक काम किया, इसलिए समस्या का पता लगाना बहुत मुश्किल हो जाएगा ।।
मुझे ऐसा लगता है कि कुछ टॉगल है जो स्विच ऑन करता है और फिर मेमोरी बढ़ने लगती है, जब तक कि यह स्विच मेमोरी की खपत बहुत अच्छी नहीं लगती

मैंने यह पता लगाने की कोशिश की कि क्या अन्य रनिंग सिस्टमों में भी ऐसी ही समस्या है।
घटना की आवृत्ति अलग-अलग होती है, लेकिन सेलेरी 4.x का उपयोग करते हुए तीन प्रणालियों पर एक मेमोरी रिसाव हुआ है, और यह एक सिस्टम पर नहीं हुआ है।
जिस सिस्टम में मेमोरी लीक है वह पायथन 3.5.x है, और बिना मेमोरी लीक वाला सिस्टम पायथन 2.7.x है।

@ dmitry-kostin अन्य दो सामान्य नोड्स के साथ क्या अंतर है, क्या वे दोनों एक ही खरगोश का दलाल के रूप में उपयोग कर रहे हैं?

चूँकि हमारी चर्चा में उल्लिखित है कि यह खरगोश से संबंधित हो सकता है, इसलिए मैंने रेडिस का उपयोग करने के अलावा उसी विन्यास के साथ एक और नया नोड शुरू किया। अब तक, 24 घंटे चलने के बाद इस नोड में कोई मेमोरी रिसाव नहीं है। मैं इसे यहाँ पोस्ट करूँगा अगर बाद में इसकी मेमोरी लीक हो जाए

@marvelph तो क्या आपका मतलब है कि मेमोरी लीक वाले तीन सिस्टम python3 का उपयोग कर रहे हैं जबकि जो ठीक है वह python2 का उपयोग कर रहा है?

@jxltom में कोई अंतर नहीं है, और हाँ वे अजगर 3 पर हैं और दलालों के रूप में दलाल और रेडिस
मैंने इसे पुन: पेश करने के लिए एक परीक्षण उदाहरण बनाया, अगर यह कुछ दिनों में सफल हो जाएगा तो मैं इस सर्वर को किसी ऐसे व्यक्ति के लिए क्रेडेंशियल्स दूंगा जो इस बग का पता लगाने के बारे में जानते हैं

@jxltom
हाँ।
जहां तक ​​मेरे पर्यावरण का सवाल है, अजगर 2 में समस्याएं नहीं हैं।

मैंने एक लंबी अवधि के भीतर ट्रेसमेलॉक के माध्यम से मेमोरी लीक को ट्रैक किया।

resource मॉड्यूल द्वारा रिपोर्ट की जाने वाली प्रारंभ मेमोरी उपयोग 3.5 घंटे के बाद 146.58MB , यह रिपोर्ट करती है कि मेमोरी उपयोग 224.21MB ।

निम्नलिखित स्नैपशॉट अंतर tracemalloc द्वारा रिपोर्ट किया गया है

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

कोई विचार? ऐसा लगता है कि यह एक भी फ़ाइल लीक नहीं है?

मैंने gc आयात किया, और gc.collect() 0 ...

@georgepsarakis मैं इसे पुनः प्राप्त करने में सक्षम था, मुझे एक्सेस क्रेडिट के लिए पिंग कर रहा था

अद्यतन: मैंने ब्रोकर को खरगोश से लेकर रेडिस तक ब्रोकर को अपडेट किया है, ताकि ब्रोकर यूआरएल को पर्यावरण चर के रूप में अपडेट कर सकें और डॉकटर / कोड को पूरी तरह से एक ही रख सकें। और यह 4 दिनों के लिए चल रहा है और मेमोरी लीक नहीं है ।

इसलिए मेरा मानना ​​है कि यह मुद्दा खरगोश दलाल के साथ जुड़ा हुआ है।

यदि संभव हो तो कृपया बेंचमार्क कमांड चलाने की कोशिश करें, यहाँ उल्लेख किया गया है: https://github.com/celery/celery/issues/2927#issuecomment -171455414

यह प्रणाली 20 सर्वरों के साथ श्रमिकों को चला रही है।
स्मृति रिसाव कल हुआ था, लेकिन यह एक ही समय में लगभग सभी सर्वरों पर हो रहा है।

अगर यह संबंधित है तो यह न जानें कि यह किस मामले में मदद करता है।

मेरे पास अजवाइन और खरगोश के साथ एक अलग मुद्दा है (अजवाइन कनेक्शन खो देता है और प्रति सेकंड समय के भार को फिर से जोड़ना शुरू कर देता है, सीपीयू 1 कोर पर 100% जाता है, हरा नए कार्यों को नहीं भेज सकता है, अजवाइन को फिर से शुरू करने की आवश्यकता है)।

इसका कारण मैं यहां बता रहा हूं यह ट्रिगर है: निगरानी के दिनों के बाद मुझे लगता है कि मैं मुद्दे की शुरुआत में स्थित हूं और यह प्रतीत होता है कि खरगोश स्मृति से डिस्क पर कुछ संदेश चला रहा है। उस समय अजवाइन जितनी जल्दी हो सके फिर से जोड़ने की कोशिश करना शुरू कर देता है और खरगोश लॉग्स प्रति सेकंड दसियों कनेक्शन / वियोजन संचालन दिखाते हैं, ~ 10 के बैच में या एक बार में। रैबिटबार्ट को पुनरारंभ करना समस्या को ठीक नहीं करता है, अजवाइन को फिर से शुरू करना इसे तुरंत ठीक करता है। मेरे पास एक उचित फ़िक्स नहीं है, लेकिन एक उदाहरण के रूप में, एक एक्सपायर पॉलिसी की स्थापना करने से संदेशों को हमेशा स्मृति में बने रहने की अनुमति मिलती है जो इस मुद्दे के आसपास काम करती है और मैंने इसे तब से नहीं देखा है।

इस मुद्दे के कुछ विवरणों को देखते हुए मैंने जो देखा, उसे (लाल खरगोश के साथ खरगोशों की अदला-बदली करना) इसे ठीक करता है, एक स्पष्ट शुरुआती बिंदु नहीं है, यह एक ही समय में एक से अधिक कार्यकर्ता / सर्वर पर होता है) मुझे लगता है कि एक सामान्य ट्रिगर हो सकता है और यह हो सकता है वही हो जो मैंने देखा था।

परीक्षण सूट को https://github.com/celery/celery/tree/master/funtests/stress से https://github.com/celery/cyanide में बदल दिया जाता है, और यह केवल Python2 का समर्थन करता है।

इसलिए मैं इसे दलाल के रूप में खरगोश के साथ पायथन 2 में चलाता हूं। इसने !join: connection lost: error(104, 'Connection reset by peer') उठाया। क्या यह मेमोरी लीक मुद्दे से संबंधित है?

यहाँ परीक्षण सूट के लिए लॉग है।

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

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

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

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

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

यहां कार्यकर्ता के लिए लॉग है।

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

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


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

मैंने एक ही स्ट्रेस टेस्ट सूट के साथ अजवाइन 3.1.25 का उपयोग करने के लिए अपडेट किया है, सब कुछ ठीक है।

BTW उन सभी के लिए जो तेजी से ठीक होने की तलाश में हैं - रैबीज के साथ खरगोश की जगह समस्या को हल करता है जैसा कि @jxltom ने सुझाव दिया है, मेरे पास केवल रेडिस के साथ स्थिर काम के सप्ताह से अधिक है
तो समस्या निश्चित रूप से खरगोश के पास कहीं <-> अजवाइन सीमा है

@dieeasy हमने एक ही मुद्दे का अनुभव किया है। मुझे लगता है कि आप आरपीसी परिणाम बैकएंड का उपयोग कर रहे हैं। यदि हां, तो DB परिणाम बैकएंड पर स्विच करने का प्रयास करें और देखें कि क्या मदद करता है। इस समस्या का कारण यह है कि: https://github.com/celery/kombu/pull/779 और यहाँ समझाया गया है: https://github.com/celery/kombu/pull/779#discussion_r13496801111

मैं एक ही समस्या स्मृति रिसाव है
स्मृति

संस्करण
अजगर 3.6.5 अजवाइन 4.2.1 बैकेंड redis ब्रोकर rabbitmq

कॉन्फ़िग

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

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

`` `अजगर

- - कोडिंग: utf-8 - -

कोम्बू आयात कतार से, एक्सचेंज
लॉगिंग के रूप में oslo_log आयात लॉग से

app.conf से आयात CONF

Log = logging.getLogger (__ name__)

celery_queues = (
कतार ('im', विनिमय = विनिमय ('प्रेषक'), मार्ग_की = 'im'),
कतार ('एसएमएस', विनिमय = विनिमय ('प्रेषक'), मार्ग_की = 'एसएमएस'),
कतार ('मेल', विनिमय = विनिमय ('प्रेषक'), मार्ग_की = 'मेल'),
कतार ('ivr', विनिमय = विनिमय ('प्रेषक'), मार्ग_की = 'ivr')
)

celery_routes = {
'प्रेषक।'
'प्रेषक। एसएमएस': {'कतार': 'एसएमएस', 'रूटिंग_की': 'एसएमएस'}}
'प्रेषक। ईमेल': {'कतार': 'मेल', 'रूटिंग_की': 'मेल'},
'प्रेषक।'
}

विन्यास = {
'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_serialis,
'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())

जरूरत पड़ने पर और जानकारी दे सकता हूं।

इसके लायक क्या है, मैं इस मुद्दे पर हूं और खरगोश के प्रबंधन कंसोल को खोलकर, कनेक्शन के लिए जा रहा हूं और अजवाइन से खरगोश के लिए यातायात के साथ कनेक्शन बंद करके इसे लगातार पुन: उत्पन्न कर सकता हूं।

मैंने अजवाइन ४.१ और ४.२ और खरगोश ३. ..-1-१ के साथ परीक्षण किया है
संपादित करें: भी अजगर संस्करण 3.6.5 और ubuntu 16.04 (AWS EC2 छवि)

मैं अजवाइन 4.2.1 और रेडिस ब्रोकर के साथ मेमोरी लीक कर रहा हूं। स्मृति 3 घंटे में 100 MiB से 500 MiB (सीमित) तक बढ़ती है, और श्रमिकों को फूल में ऑफ़लाइन के रूप में चिह्नित किया जाता है। प्रीफ़ॉर्क पूल और जीवेंट दोनों एक ही मुद्दा दिखाते हैं।

@yifeikong यह एक ही मुद्दा नहीं हो सकता है, लेकिन अपने मामले के लिए आप प्रस्तावित समाधान की कोशिश कर सकते हैं https://github.com/celery/celery/pull/4839#issuecomment -447739820?

@georgepsarakis मैं Python 3.6.5 का उपयोग कर रहा हूं, इसलिए मैं इस बग से प्रभावित नहीं हूं। मैं कुछ शोध करने के लिए ट्रेसमैलोक का उपयोग करूंगा। यदि यह एक अजवाइन बग था, तो मैं एक नया मुद्दा खोलूंगा। धन्यवाद

शायद # 5047 के साथ भी यही कारण है, ऐसा लगता है कि यह बग अलग घटना को जन्म दे सकता है।

हम एक ही मेमोरी लीक का सामना कर रहे हैं, जिसमें सेलरी 4.2.1, कोम्बू 4.2.2 और पायथन 3.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

मैं कह सकता हूं कि हमने कई चीजों की कोशिश की है जो अन्य लोगों ने संभावित वर्कआर्ड्स (ब्रोकर के रूप में रेडिस, जेमलॉक, लिबामकप, बंदर पथ __del__ AsyncResult ) का उपयोग करते हुए उल्लेख किया है लेकिन हमने हमेशा मेमोरी लीक होने को समाप्त कर दिया है।

अपने लॉग का विश्लेषण करके हमने देखा कि हमारे पास गपशप से छूटे हुए दिल की धड़कन से संबंधित बहुत सारे संदेश थे।

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

एक आखिरी चीज जो हमने कोशिश की, श्रमिकों को --without-gossip साथ चलाकर गपशप को अक्षम कर दिया, आश्चर्यजनक रूप से, गपशप को अक्षम करने का तत्काल प्रभाव पड़ा।

आप इसे यहां देख सकते हैं:

चूंकि हमने अजवाइन के मजदूरों को चलाने वाली दो परियोजनाओं में गपशप को निष्क्रिय कर दिया है, इसलिए मेमोरी की खपत में सुधार हुआ है।

अगर आप ध्यान दें, तो इससे पहले कि हम यहां बताए गए समान मेमोरी स्पाइक्स के बारे में बता रहे थे, https://github.com/celery/celery/issues/4843#issuecomment -399833781

एक बात जो मैं पूरी तरह से समझने की कोशिश कर रहा हूं, वह यह है कि पूरी तरह से अक्षम गपशप के निहितार्थ क्या हैं, क्योंकि यह केवल कार्यकर्ता <-> कार्यकर्ता संचार के रूप में वर्णित है, अगर कोई इस बारे में कुछ प्रकाश डाल सकता है तो मैं बहुत आभारी रहूंगा।

आशा है कि यह मदद करता है और कड़ी मेहनत के लिए धन्यवाद।

यह मुद्दा क्यों बंद किया गया?

इस मुद्दे पर सक्रिय प्रतिक्रिया और रुचि है, इसलिए मैं फिर से खोल रहा हूं।

खैर @georgepsarakis के बाद से हमने अपने रिसाव का निदान # 4839 नहीं होने के रूप में किया था, और आपको संदेह था कि यह # 4843 था, मैं कम से कम अभी इस लीक धागे को पलटूंगा। मुझे यकीन नहीं है कि # 4843 मेरा लीक है। इस धागे पर प्रारंभिक अंक के अनुसार:

यह समस्या कम से कम सेलेरी 4.1 में होती है, और यह सेलेरी 4.2 में भी होती है।
अजवाइन Ubuntu 16 पर चल रही है और दलाल RabbitMQ का उपयोग करते हैं।

मैं वर्तमान में हूँ:

अजगर 2.7.12
Ubuntu 16.04.1 amd64
खरगोश ३.bit.५

का उपयोग कर:

अजवाइन 4.1.1
librabbitmq 2.0.0
amqp 2.4.0
बेल 1.1.4
बिलियर्ड 3.5.0.5
kombu 4.2.2.post1
१.२.२

हालाँकि, Celery 4.1.1 + gevent 1.2.2 मेरे लिए लीक नहीं है (और ना ही Celery 3.1.25 + gevent 1.2.2 AFAQT); अजवाइन 4.2.1 + जीवेंट 1.3.7 करता है। दुर्भाग्यवश, जीईएनईटी 1.3.7 और जीवेंट 1.2.2 समस्या के संभावित स्रोत के रूप में एक जीवेंट लाइब्रेरी को प्रदर्शित करने (या बाहर करने) के लिए विनिमेय नहीं हैं।

संपादित करें: हम्म ... लगता है कि यह एक त्रुटि पैच (022f447dd) है जो ऐसा लगता है कि मुझे मिली त्रुटि को ठीक कर सकता है। मैं कोशिश करूंगा और काम करूंगा।

मैंने 022f447 को सेलेरी 4.1.1 पर लागू किया और 1.3.7 जियोवेंट स्थापित किया। उस सेलेरी + जीवेंट कॉम्बिनेशन ने दौड़ लगाई ... और स्मृति उपयोग पैटर्न का उत्पादन किया जो मेरे द्वारा अनुभव की गई रिसाव के अनुरूप है। मैं Celery 4.2.1 + gevent 1.2.2 (रिवर्स पैच के साथ) स्थापित करूँगा और देखूंगा कि मुझे सामान्य मेमोरी उपयोग पैटर्न मिलता है या नहीं।

मुझे लगता है कि 1.4.0 जेंट बाहर है। हो सकता है कि मैं एक भंवर दे दूं कि कैसे व्यवहार किया जाए।

सेलेरी 4.2.1 + जीवेंट 1.2.2 + जियोवेंट 1.2.2 के लिए रिवर्स पैच लीक का उत्पादन नहीं लगता जैसा कि सेलेरी 4.2.1 + जीवेंट 1.3.7 है।

अजवाइन 4.2.1 + जीवेंट 1.4.0, लगभग 1.3.7 एएफएआईसीटी के समान दर पर लीक होता है।

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.

अब, अगर मैं सही ढंग से समझता हूं कि एएमक्यूपी हुड के तहत क्या करता है, तो इसका अपना दिल की धड़कन है और जब यह टूटे हुए कनेक्शन का पता लगाता है, तो यह आगे बढ़ता है और हुड के नीचे पुन: जुड़ जाता है। सक्षम होने वाली घटनाओं (गपशप, दिल की धड़कन) के आधार पर, यह बहुत तेजी से लीक हो सकता है।
यह ईवेंटलेट और जियोवेंट के किसी भी संस्करण के लिए सही होना चाहिए, लेकिन कुछ कनेक्शन मुद्दों को प्रदर्शित कर सकता है जो चीजों को बदतर / अधिक ध्यान देने योग्य बनाते हैं।

नमस्ते,

मुझे संदेह है कि हम एक ही मुद्दे पर चल रहे हैं।
हमारा विन्यास नीचे है। क्या मैं या तो नकार सकता हूं या पुष्टि कर सकता हूं कि यह वही मुद्दा है जिस पर यहां चर्चा की गई है?

अजगर: 2.7
अजवाइन: 4.2.1
OS: CentOS रिलीज़ 6.10
दलाल के रूप में रेडिस

संलग्न चित्र में आप देख सकते हैं:

1. मेमोरी की खपत लगातार बढ़ रही है और पुनः आरंभ करने पर गिर रही है।
2. 13 जनवरी को - हमने अजवाइन 3.1.25 से 4.2.1 तक उन्नत किया। मेमोरी की खपत बढ़ने की गति बढ़ती है।

अपडेट करें

इस मुद्दे के बावजूद, हमने अजगर 3.6 में अपग्रेड किया और तब से ऐसा लगता है कि रिसाव अब नहीं होता है।

(19 फरवरी को अपग्रेड हुआ था)

@georgepsarakis

यह सुनिश्चित नहीं है कि यह कितना प्रासंगिक है, लेकिन मैं उत्पादन में अजवाइन द्वारा समाप्त होने वाले मेरे 2GB SWAP स्थान का उपयोग कर रहा हूं। स्टॉपिंग फ्लॉवर ने मेमोरी को साफ नहीं किया, लेकिन सेलेरी को रोक दिया

किसी को अजवाइन की कोशिश कर सकता है 4.3rc1?

@auvipy मैंने Celery 4.3.0rc1 + gevent 1.4.0 स्थापित किया। अपग्रेडेड बिलियर्ड को 3.6.0.0 और कोम्बू को 4.3.0।

यह देखते हुए कि rc1 पैकेज द्वारा बेल 1.2.0 भी आवश्यक नहीं था, यह देखते हुए कि # 4839 उस अपग्रेड द्वारा तय किया गया है।

वैसे भी, सेलेरी 4.3.0 आरसी 1 ठीक चलता है।

@ ldav1s प्रतिक्रिया के लिए बहुत बहुत धन्यवाद। तो, वास्तव में पाई-एमक्यूपी में एक निर्भरता के रूप में बेल को घोषित किया जाता है। नई स्थापनाओं में नवीनतम vine संस्करण स्थापित किए जाएंगे लेकिन मौजूदा लोगों में ऐसा नहीं हो सकता है।

@thedrow शायद हमें सेलेरी आवश्यकताओं में भी निर्भरता की घोषणा करनी चाहिए?

आइए इसके बारे में एक मुद्दा खोलें और इस पर चर्चा करें।

Celery 4.3.0rc1 + gevent 1.4.0 अब कुछ दिनों से चल रहा है। ऐसा लगता है कि यह Celery 4.2.1 + gevent 1.4.0 के समान फैशन में लीक हो रहा है।

अजवाइन के साथ समान रिसाव 4.2.1, अजगर 3.6

इस पर कोई अपडेट?

यहाँ एक ही समस्या है

अभिवादन,

मैं एक समान समस्या का सामना कर रहा हूं, लेकिन मुझे यकीन नहीं है कि यह समान है।

जब मैंने एक अलग वातावरण / नेटवर्क में हमारे अजवाइन ऐप को माइग्रेट किया, तब से अजवाइन के श्रमिकों का रिसाव शुरू हो गया। इससे पहले अजवाइन के अनुप्रयोग और खरगोश उदाहरण एक ही वातावरण / नेटवर्क में थे।

मेरा विन्यास अजगर 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

आवेदन कई श्रमिकों द्वारा बनाया गया है, जो ईवेंट्स पूल के साथ शुरू होता है, पर्यवेक्षक में कमांड के माध्यम से शुरू किया जाता है:

[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 लीक शुरू होता है:

इसलिए मैंने प्रत्येक कार्यकर्ता पर ट्रेसमैलोक का उपयोग करने के लिए एक प्रसारण संदेश बनाया है, यह मशीन पर शीर्ष कमांड का परिणाम है, 1 कार्यकर्ता केवल 1464m के साथ लीक है:

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

ट्रेसमैलोक TOP 10 लीक करने वाले कार्यकर्ता पर परिणाम

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

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

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

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

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

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

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

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

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

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

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

25 फ्रेम के साथ शीर्ष 1

TOP 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मुझे आशा है कि यह मदद कर सकता है, श्रमिकों के बीच याद की धड़कन के अलावा लॉग में कोई त्रुटि नहीं है। अब मैं पुराने env का उपयोग करने वाले लिबास के सटीक संस्करण का उपयोग करने की कोशिश कर रहा हूं।

अद्यतन: एक ही सटीक निर्भरता के काम के संस्करणों और एक ब्रोकर दिल की धड़कन का उपयोग करते हुए हर 5 मिनट में आवेदन लंबे समय तक स्थिर दिखता था: 2 दिनों से अधिक, फिर से लीक होने की तुलना में।

समय-समय पर ~ 1 घंटे के लिए छोटे स्पाइक जारी थे, लेकिन "अवशोषित / एकत्रित" थे .. पिछले एक स्पाइक की तरह लग रहा है।

1 स्पाइक, 1 रैंप के बाद, मैंने लीकिंग वर्कर को फिर से शुरू कर दिया है .. जैसा कि आप देख सकते हैं कि एक और वर्कर ने इसके बाद लीक करना शुरू कर दिया है या शायद यह पहले से ही लीक हो रहा था, दूसरा रैंप।

मैं दिल की धड़कन के बिना परीक्षण करने जा रहा हूं।

अद्यतन: दिल की धड़कन के बिना 2 दिनों के बाद फिर से लीक, एक ही व्यवहार

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

अपडेट करें:
अजवाइन 4.3.0 का उपयोग करने से यह समस्या हल हो गई है और यह एक सप्ताह से स्थिर है

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

कृपया मुझे बताएं कि क्या मैं किसी तरह से कोड की मदद कर सकता हूं। यदि आवश्यक हो तो लिंक और उदाहरण प्रदान करें।

धन्यवाद

मुझे मेमोरी लीक भी हो रही है। ऐसा लगता है कि मैं कारण खोजने में कामयाब रहा हूं।
https://github.com/celery/celery/blob/master/celery/events/dispatcher.py#L75
मैं देख सकता हूं कि यह बफर खरगोश के साथ कनेक्शन के मुद्दों के बाद बढ़ने लगता है। मुझे समझ नहीं आ रहा है कि आखिरकार यह घटनाओं को स्पष्ट करने में विफल क्यों है, यह समय के साथ बढ़ता रहता है और अधिक से अधिक राम का उपभोग करता है। यहाँ buffer_while_offline=False https://github.com/celery/celery/blob/master/celery/worker/consumer/events.py#L43 मेरे लिए लीक को ठीक करने के लिए लगता है। क्या कोई कृपया जाँच कर सकता है कि क्या यह संबंधित है?

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

@ yevhen-m आपका बहुत-बहुत धन्यवाद! जिससे हमें मेमोरी लीकेज को हल करने में मदद मिली!

यह अच्छा है कि हमारे पास वर्कअराउंड है लेकिन क्या हम एक उचित समाधान पा सकते हैं?

निरंतर इस स्मृति रिसाव मुद्दे का पालन करें

मैं एक उत्पादन वातावरण में अजवाइन का उपयोग कर रहा हूं, और मैं इसे डॉकटर के माध्यम से तैनात कर रहा हूं।
स्क्रीनशॉट की तरह, हमें भी यही समस्या आ रही है।
हमारे उत्पादन विन्यास नीचे दिखाया गया है।

डॉकर पैरेंट छवि: अजगर 3.6.8-बस्टर
अजवाइन संस्करण: 4.2.0
कमांड विकल्प:

• संगामिति ४
• प्रीफैच-मल्टीप्लायर 8
• कोई परिणाम_बेंड नहीं
• acks_late और reject_on_worker_lost

मुझे आश्चर्य है कि अगर अजवाइन के संस्करण को 4.3.0 में अपग्रेड करना स्मृति रिसाव मुद्दे को हल करता है।

धन्यवाद!

अजवाइन 4.4.0 नवीनतम स्थिर है

टीम, क्या इस मुद्दे के बारे में कोई अपडेट है? क्या यह पता था और अजवाइन 4.4.0 में तय किया गया था?

टीम, क्या इस मुद्दे के बारे में कोई अपडेट है? क्या यह पता था और अजवाइन 4.4.0 में तय किया गया था?

दुर्भाग्यवश नहीं। अब यह पता चला है।

टीम, क्या इस मुद्दे के बारे में कोई अपडेट है? क्या यह पता था और अजवाइन 4.4.0 में तय किया गया था?

यह 4.4.1 पर उपलब्ध होगा

यह 4.4.1 पर उपलब्ध होगा

क्या यह वर्तमान संस्करण 4.4.1 में तय किया गया है?

@auvipy समस्या अभी भी अजवाइन 4.4.2, और 4.4.6 में मौजूद है। हम सभी श्रमिकों में समान मेमोरी लीक देखते हैं।

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

अजवाइन के कार्यकर्ता को -O fair --without-heartbeat --without-gossip -c 1 -l झंडे के साथ शुरू किया जाता है। हम कार्यकर्ता नाम और कतारों को सेट करने के लिए -n और -Q झंडे का भी उपयोग करते हैं। प्रीफ़ॉर्क मोड में चल रहा है। Redis, दलाल और परिणाम स्टोर दोनों के रूप में कॉन्फ़िगर किया गया है।

~ हम लंबे समय तक चलने वाले कार्यों में बहुत से चूक गए हैं। तो जुड़ी समस्याओं में रिपोर्ट की गई समस्या अभी भी बनी हुई है। ~

यह विकलांग दिल की धड़कन के साथ भी ऐसा ही है।

@jsynowiec जब मैंने इस मुद्दे का सामना किया तो मेरे लिए काम करने वाली एकमात्र चीज़ गॉसिप विकलांगों के साथ चल रही थी, मैंने इसके बारे में यहाँ कुछ उल्लेख किया है https://github.com/celery/celery/issues/4843#issuecommentment -459789086

हम अजवाइन 4.4.2 के साथ एक ही समस्या का सामना कर रहे हैं और ब्रोकर के रूप में रेडिस हैं। 48 घंटे से अधिक के अजवाइन की खपत 60 जीबी रैम तक होती है, जो अंत में मेमोरी से बाहर निकल जाती है।
इस नाम के किसी भी समाधान का इस व्यवहार पर कोई प्रभाव नहीं पड़ा।

हम अजवाइन 4.4.2 के साथ एक ही समस्या का सामना कर रहे हैं और ब्रोकर के रूप में रेडिस हैं। 48 घंटे से अधिक के अजवाइन की खपत 60 जीबी रैम तक होती है, जो अंत में मेमोरी से बाहर निकल जाती है।
इस नाम के किसी भी समाधान का इस व्यवहार पर कोई प्रभाव नहीं पड़ा।

क्या आपने हमारे नवीनतम पैच संस्करण की कोशिश की?
क्या आपके पास ओपी के समान शर्तें हैं?

मेमोरी लीक अभी भी v4.4.6 पर मौजूद है। हम पहले की टिप्पणी में सूचीबद्ध सेटिंग्स के साथ श्रमिकों को चलाते हैं। ओपी RabbitMQ का उपयोग करता है, हम रेडिस को ब्रोकर के रूप में उपयोग करते हैं।

+1, स्मृति के उपयोग को ध्यान में रखते हुए धीरे-धीरे कम से कम 24 घंटे बढ़ जाते हैं, यहां तक ​​कि न्यूनतम काम भी किया जाता है। मुझे लगता है कि इस मुद्दे को फिर से खोला जाना चाहिए।

क्या आप अपनी मेमोरी लीक की जड़ का पता लगा सकते हैं?

मेमोरी लीक अभी भी v4.4.6 पर मौजूद है। हम पहले की टिप्पणी में सूचीबद्ध सेटिंग्स के साथ श्रमिकों को चलाते हैं। ओपी RabbitMQ का उपयोग करता है, हम रेडिस को ब्रोकर के रूप में उपयोग करते हैं।

ऐसा लगता है कि यह एक अलग मुद्दा है या यह कि हमारा फिक्स सही नहीं था।
चूंकि इससे ओपी की समस्या हल हो गई, इसलिए यह शायद एक अलग मुद्दा है?

[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

मेमोरी लीक करने वाले रेडिस क्लाइंट? मैं अजवाइन v4.4.6 का उपयोग कर रहा हूँ, साथ ही ब्रेंट के रूप में रेडी, ब्रोकर के रूप में और कोई परिणाम नहीं।

शायद यह भी एक मुद्दा है। शायद यह जियोवेंट में है?
CC @jamadden @andymccurdy
क्या आप कृपया इस मुद्दे को शांत करने में मदद कर सकते हैं और यह सुनिश्चित कर सकते हैं कि कोई स्मृति आपके अंत में लीक न हो?

शायद यह जियोवेंट में है?

हम gevent का उपयोग नहीं कर रहे हैं। श्रमिकों को संगामिति = 1 और प्रीफ़ॉर्क के साथ शुरू किया जाता है।

हाय दोस्तों, यह निश्चित नहीं है कि यह मुद्दा क्यों बंद हो गया है, हम 2 साल से इस मुद्दे पर चल रहे हैं, हर बार सेलेरी के अंतिम संस्करण को अपडेट कर रहे हैं, और अभी भी बड़े सेवर (64-128 जीबी रैम) लगातार रैम से बाहर चल रहे हैं क्योंकि इस स्मृति रिसाव मुद्दों की।

क्या सेलेरी 3 में अपग्रेड किए बिना या रैबिटमैक को बदलने के लिए कोई वर्कअराउंड है?

यह सेलेरी को उत्पादन के वातावरण पर पूरी तरह से अस्थिर बनाता है, मुझे उम्मीद है कि इसे ठीक किया जा सकता है, हम सेलेरी 3 को डाउनग्रेड नहीं कर सकते हैं इसलिए हम एक और समाधान (शायद ड्रामातिक) पर जाने की योजना बना रहे हैं ताकि सेलेरी पूरे सर्वर रैम खाने के बारे में चिंता करना बंद कर सके। उत्पादन हर 2 दिन।

@arielcamino - मैं 100 ~ कार्यों के बाद कार्यकर्ता उदाहरणों को बदलने के लिए सेटिंग कार्यकर्ता_ max_tasks_per_child का उपयोग कर रहा हूं जिन्होंने स्मृति उपयोग को बनाए रखने में मदद की है, कम से कम मेरे सर्वर के लिए। मैं 512MB के छोटे उदाहरण चला रहा हूं और इससे मुझे (पहले मेरे राम को थकने में) मदद मिली, इसलिए शायद यह आपकी मदद करेगा।

@ शो वाह, यह सुपर उपयोगी है, बहुत बहुत धन्यवाद! अभी कोशिश करेंगे।

@arielcamino - मैं 100 ~ कार्यों के बाद कार्यकर्ता उदाहरणों को बदलने के लिए सेटिंग कार्यकर्ता_ max_tasks_per_child का उपयोग कर रहा हूं जिन्होंने स्मृति उपयोग को बनाए रखने में मदद की है, कम से कम मेरे सर्वर के लिए। मैं 512MB के छोटे उदाहरण चला रहा हूं और इससे मुझे (पहले मेरे राम को थकने में) मदद मिली, इसलिए शायद यह आपकी मदद करेगा।

अपना वर्कअराउंड साझा करने के लिए धन्यवाद। इससे यहां मदद नहीं मिली - हम हालांकि रेडिस का उपयोग कर रहे हैं।

@thedrow मुझे redis-py में किसी भी मेमोरी लीक के बारे में पता नहीं है। यदि रेडिस-पी में एक रिसाव था, तो मुझे लगता है कि किसी ने इसे अजवाइन के वातावरण के बाहर सामना किया होगा और इसे रेडिस-पी इश्यू ट्रैकर की सूचना दी थी।

जहां मैं कर सकता हूं, वहां मदद करने के लिए खुश (मैं कई परियोजनाओं पर एक दलाल के रूप में सेलेरी डब्ल्यू / रेडिस का उपयोग करता हूं), लेकिन मैंने अपनी तैनाती में इस मुद्दे का सामना नहीं किया है।

मुझे जियोवेंट के वर्तमान संस्करणों में किसी भी मेमोरी लीक के बारे में पता नहीं है। मुझे लगता है कि (आशा) किसी ने कुछ कहा होगा अगर उन्होंने सामना किया है (यह एक या दो बार पहले हुआ है)। जियवेंट की मेरी वर्तमान तैनाती में कई कार्यकर्ता (वेब ​​और बैकग्राउंड) हैं, जो एक समय पर भारी मात्रा में जियोवेंट का उपयोग कर रहे हैं और हमने मेमोरी लीक का सामना नहीं किया है।

हाय दोस्तों, यह निश्चित नहीं है कि यह मुद्दा क्यों बंद हो गया है, हम 2 साल से इस मुद्दे पर चल रहे हैं, हर बार सेलेरी के अंतिम संस्करण को अपडेट कर रहे हैं, और अभी भी बड़े सेवर (64-128 जीबी रैम) लगातार रैम से बाहर चल रहे हैं क्योंकि इस स्मृति रिसाव मुद्दों की।

क्या सेलेरी 3 में अपग्रेड किए बिना या रैबिटमैक को बदलने के लिए कोई वर्कअराउंड है?

यह सेलेरी को उत्पादन के वातावरण पर पूरी तरह से अस्थिर बनाता है, मुझे उम्मीद है कि इसे ठीक किया जा सकता है, हम सेलेरी 3 को डाउनग्रेड नहीं कर सकते हैं इसलिए हम एक और समाधान (शायद ड्रामातिक) पर जाने की योजना बना रहे हैं ताकि सेलेरी पूरे सर्वर रैम खाने के बारे में चिंता करना बंद कर सके। उत्पादन हर 2 दिन।

आपके पास कितने कार्यकर्ता हैं? आप कितने कार्य चलाते हैं? आप कितनी बार इस कार्य को चलाते हैं और आमतौर पर इन्हें पूरा करने में कितना समय लगता है?

कारण है कि खरगोश / अजवाइन राम का बहुत उपयोग करना शुरू कर देता है कतार से जुड़े कार्यों की मात्रा से संबंधित हो सकता है। यदि आप बहुत सारे कामों की कतार लगाते हैं और कर्मचारी उन सभी को पूरा नहीं कर सकते हैं, तो यह कतार को बड़ा कर देगा और यह कतार अधिक से अधिक RAM का उपयोग करेगी और अंततः यह उपलब्ध सभी RAM का उपभोग करेगी। मेरा मानना ​​है कि यह समस्या रेडिस के साथ भी हो सकती है।

मेरे पास एक और सिद्धांत है लेकिन पहले मैं जानना चाहता हूं कि क्या यह आपकी समस्या का कारण हो सकता है।

@ardilom क्षमा करें, मैंने महसूस किया है कि हम RabbitMQ डेटा को डेटाडॉग पर नहीं भेज रहे हैं, लेकिन मैं अपनी स्थिति को स्पष्ट करने की कोशिश करूंगा, यह है कि हर 2 दिनों में कुछ सर्वर रैम नीचे कैसे जाते हैं:

हम हमेशा लंबित कार्यों की संख्या की जाँच करते हैं, और आम तौर पर लगभग 0 है (यह डेटा कुछ दिनों पहले से है):

हम प्रति दिन लगभग 250,000 कार्य चलाते हैं, हमारे पास लगभग 10 कर्मचारी हैं, प्रत्येक में लगभग 4 से 10 संगामिति हैं, औसत रनटाइम लगभग 5 सेकंड है, यह कार्य के प्रकार पर निर्भर करता है।

हम हमेशा संदेशों को पहले से ही जांच लेते हैं यह सुनिश्चित करने के लिए कि बहुत सारे कार्य कतारबद्ध नहीं हैं (यह वही है जो आप दूसरी छवि में देखते हैं), क्या आपको लगता है कि संदेशों को पहले से ही मापना ठीक है? हमारे पास अंततः कुछ शिखर हैं, लेकिन आम तौर पर ये 0 के करीब हैं।

समस्या को हल करने के लिए, मैं अभी सेलेरी कार्यकर्ता को मैन्युअल रूप से पुनरारंभ करता हूं और रैम का उपयोग फिर से सामान्य हो जाता है।

मुझे बताएं कि क्या आपको किसी और चीज की जरूरत है, मैंने सिर्फ एक कार्य सर्वर पर कार्यकर्ता_मैक्स_टैक्स_पर_चाइल्ड की सेटिंग बदल दी है, यह देखने के लिए कि कॉन्फ़िगरेशन को लागू करने के बाद बाकी के साथ कोई अंतर है या नहीं।

धन्यवाद!

हाय दोस्तों, यह पुष्टि करने के लिए है कि मेरे मामले में 1000_max_tasks_per_child को बदलते हुए @Skowt

कल मैंने जो कुछ उल्लेख नहीं किया है, मैं "प्रीफ़ॉर्क" मोड का उपयोग कर रहा हूं, हो सकता है कि मुद्दे को हल करने के लिए एक और तरीका है।

@arielcamino इस मुद्दे को बंद कर दिया गया था क्योंकि हमने एक विशिष्ट मेमोरी लीक को हल किया था। स्मृति रिसाव का एक और कारण हमें अभी तक नहीं मिल पाया है। हम जानते हैं कि एक समस्या है लेकिन हम नहीं जानते कि इसे कैसे पुन: पेश किया जाए।
हमें उत्पादन वातावरण तक पहुंच के साथ किसी की आवश्यकता है जहां बग समस्या को कम करने के लिए पुन: पेश करता है।
यदि हमारे पास एक नहीं है, तो हमें यह निर्धारित करना होगा कि यह मुद्दा कार्रवाई योग्य नहीं है।

हैलो, क्या हम इस मुद्दे को फिर से खोल सकते हैं? हम अजवाइन का उपयोग करते हुए समान लीक का अनुभव कर रहे हैं == 4.4.7 (खरगोश के साथ) हमारे पास कार्यकर्ता कुछ घंटों के लिए स्थिर चल रहा है, कभी-कभी बहुत अधिक होता है, और फिर अचानक धीरे-धीरे लीक होने लगता है और सभी मेमोरी का उपयोग करके समाप्त होता है।

वर्तमान में --concurrency=1 और ध्वज --max-tasks-per-child=100 साथ प्रीफ़ॉर्क का उपयोग कर रहा है, जो तब तक मदद करने के लिए प्रतीत नहीं होता है जब से मूल प्रक्रिया एक लीक हो जाती है।

मैं इस समस्या को डीबग करने में अधिक जानकारी प्रदान कर सकता हूं।

हैलो, क्या हम इस मुद्दे को फिर से खोल सकते हैं? हम अजवाइन का उपयोग करते हुए समान लीक का अनुभव कर रहे हैं == 4.4.7 (खरगोश के साथ) हमारे पास कार्यकर्ता कुछ घंटों के लिए स्थिर चल रहा है, कभी-कभी बहुत अधिक होता है, और फिर अचानक धीरे-धीरे लीक होने लगता है और सभी मेमोरी का उपयोग करके समाप्त होता है।

वर्तमान में --concurrency=1 और ध्वज --max-tasks-per-child=100 साथ प्रीफ़ॉर्क का उपयोग कर रहा है, जो तब तक मदद करने के लिए प्रतीत नहीं होता है जब से मूल प्रक्रिया एक लीक हो जाती है।

मैं इस समस्या को डीबग करने में अधिक जानकारी प्रदान कर सकता हूं।

इस मुद्दे को फिर से खोलना कोई बड़ी बात नहीं है, यह किसी के हित में है जो प्रोडक्शन और हेल्प ट्रैक में इसका सामना कर रहा है और एक फिक्स योगदान देता है या कम से कम उत्पादन में रिसाव के मूल कारण का पता लगाता है।

मैं निश्चित रूप से मदद कर सकता हूं, लेकिन मुझे लगता है कि मुझे क्या करना है पर विचारों से बाहर चला गया, मैंने कुछ उपकरण चलाए लेकिन इस मुद्दे के बारे में ज्यादा पहचान नहीं कर सका। केवल एक चीज जो थोड़े इसे नीचे बताती है, वह ट्रेसमैलोक स्नैपशॉट है जो मैंने लिया था, जो हर दो या दो मिनट में एक ही स्थान पर मेमोरी बढ़ाने को दर्शाता है। यह दो स्नैपशॉट की तुलना करने वाला शीर्ष 10 है:

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

मुद्दा अभी भी मौजूद है
यह तब होता है जब एक कार्य करने के लिए अजवाइन कार्य एक्सेस ऐप संदर्भ होता है
यह कार्य करने के बाद इसे जारी नहीं करेगा या इसका निपटान नहीं करेगा

--max-tasks-per-child=

सहायक नहीं था

हैलो, क्या हम इस मुद्दे को फिर से खोल सकते हैं? हम अजवाइन का उपयोग करते हुए समान लीक का अनुभव कर रहे हैं == 4.4.7 (खरगोश के साथ) हमारे पास कार्यकर्ता कुछ घंटों के लिए स्थिर चल रहा है, कभी-कभी बहुत अधिक होता है, और फिर अचानक धीरे-धीरे लीक होने लगता है और सभी मेमोरी का उपयोग करके समाप्त होता है।
वर्तमान में --concurrency=1 और ध्वज --max-tasks-per-child=100 साथ प्रीफ़ॉर्क का उपयोग कर रहा है, जो तब तक मदद करने के लिए प्रतीत नहीं होता है जब से मूल प्रक्रिया एक लीक हो जाती है।

मैं इस समस्या को डीबग करने में अधिक जानकारी प्रदान कर सकता हूं।

इस मुद्दे को फिर से खोलना कोई बड़ी बात नहीं है, यह किसी के हित में है जो प्रोडक्शन और हेल्प ट्रैक में इसका सामना कर रहा है और एक फिक्स योगदान देता है या कम से कम उत्पादन में रिसाव के मूल कारण का पता लगाता है।

मेरे लिए अगर मैं --max-tasks-per-child जोड़ूं तो यह काम करता है।
इस नमूने के लिए --autoscale=5,2 --max-tasks-per-child=40 तर्क इस तरह है

हालांकि मेरा मानना ​​है कि हाल ही में अजवाइन के उन्नयन ने मेमोरी रिसाव को शुरू किया, मैं कुल आश्वस्त नहीं हो सकता। मैं साझा करूंगा कि निम्नलिखित सेटिंग ने रिसाव को हल कर दिया है।

मैं यह नहीं बता सकता कि कौन सी सेटिंग्स दस्तावेज़ीकरण द्वारा मान्य हैं, इसलिए मैं अपनी Django सेटिंग्स फ़ाइल में इन सभी मानों की सेटिंग कर रहा हूं।

CELERY_CONCURRENCY = CELERY_WORKER_CONCURRENCY = 1
CELERY_MAX_TASKS_PER_CHILD = CELERY_WORKER_MAX_TASKS_PER_CHILD = 1

यह उस रिसाव को हल नहीं करता है जिसे हम देख रहे हैं, क्योंकि यह जियोवेंट पूल में भी होता है। मैंने देखा कि हमारे पास बहुत व्यस्त है। क्योंकि ट्रेसमैलोक ने इवेंट को लीक के संभावित संभावित स्रोतों में से एक के रूप में दिखाया था क्योंकि मैंने स्पष्ट रूप से अक्षम किए गए कार्य ईवेंट और हमारे फूलों की आवृत्ति को बंद कर दिया है, अब के लिए ऐसा प्रतीत होता है कि रिसाव अब नहीं हो रहा है, मैं इसे सप्ताहांत और शेयर के माध्यम से चलने दूंगा यहाँ परिणाम।

रिसाव के संभावित स्रोत मैं स्पष्ट रूप से अक्षम कार्य घटनाओं और हमारे फूल उदाहरण बंद कर देते हैं

किसी से जो इस मुद्दे को चुपचाप देख रहा है (और कभी भी इसका प्रत्यक्ष रूप से कभी अनुभव नहीं किया है) से उपाख्यानात्मक डाटपॉइंट: मैं एक अन्य परियोजना (अजवाइन के लिए एक नॉन-इंबस्टैंटियल वर्कलोड के साथ) से अवगत हूं, जहां ऊपर करने का एक ही परिणाम था स्मृति रिसाव को रोकना। केवल दूसरे हाथ की जानकारी होने के बाद, मैं _ob ज़ाहिर है कि यह पुष्टि नहीं कर सकता है कि यह भी एक ही अंतर्निहित मुद्दा था (AFAIK यह rabbitmq था, जियवेंट आदि के बारे में कोई विचार नहीं है), लेकिन यह दिलचस्प है कि यह सहसंबंधित है।

मुझे संदेह है कि यह खरगोश के कनेक्शन के साथ कुछ करने के लिए है, जिस स्टैक को हम इस रिसाव को देख रहे हैं:

• सेलेरी (नवीनतम संस्करण): या तो प्रीफ़ॉर्क या जियोवेंट पूल, दोनों एक ही लीक पैटर्न दिखाते हैं।
• खरगोशबीम (बादामकप सास)
• फूल

हमने लीक के लिए अपने सभी कार्यों की जाँच की है और कोई भी लीक नहीं पाया है, इसीलिए अजवाइन की तरफ कुछ होने का मेरा संदेह है।

एक दिलचस्प तथ्य यह है कि वर्तमान में हमारे पास कई श्रमिक चल रहे हैं, और मैंने देखा कि, एक बार लीक होने के बाद यह फूल पर ऑफ़लाइन भी दिखाई देता है।

जैसा कि मैंने विचारों से बाहर भाग लिया जहां मैं अक्षम फूलों और कार्य घटनाओं को देखता हूं और निगरानी रखेगा कि क्या रिसाव वापस आएगा या नहीं।

मैं विश्वास करने के लिए खुला हूं कि यह मेरे स्टैक का एक और हिस्सा है जो इस बिंदु पर मेमोरी लीक कर रहा है। सेलेरी का अतीत में गंभीर व्यवहार हो सकता है जो स्मृति लीक को नियंत्रित करने में योगदान देता है, लेकिन हम सभी को इस बात की पुष्टि करने के लिए समान मुद्दे नहीं हैं। मुझे पता है कि हम में से बहुत से या तो चल रहे हैं ...

• एक बार में नेस्टेड कार्यों की एक बड़ी संख्या, या
• कुछ अखंड जो कार्यकर्ता के भीतर मल्टी-कोर प्रसंस्करण को बंद कर देते हैं

इन मामलों में, हमें केवल एक निश्चित स्तर की संगामना, कार्य पंक्तिबद्धता और बाल कार्यकर्ता के कार्यों को अनुमति देने या अस्वीकार करने के बारे में स्मार्ट होना चाहिए। इसके अतिरिक्त, हम सभी को अंतर्निहित सुरक्षा उपायों का उपयोग करना चाहिए जो स्मृति-भूख कार्यों को मार सकते हैं इससे पहले कि उनके पास हमारे सर्वर को क्रैश करने का अवसर हो।

अजवाइन में भारी संख्या में लोग भारी-भरकम सीपीयू-बाउंड और मेमोरी-बाउंड प्रोसेस चला रहे हैं, जो वास्तव में इसके लिए नहीं बनाया गया था, इसलिए मुझे लगता है कि क्विकस्टार्ट डॉक्यूमेंट में इस पर अधिक विवरण शामिल होना चाहिए।

जैसा कि मेरी पिछली टिप्पणियों में पहले ही उल्लेख किया जा चुका है, हम बहुत पहले से दोनों max-tasks-per-child और संगोष्ठी को 1 रहे हैं। यह मेमोरी को लीक करने के बारे में कुछ नहीं करता है। इसके अलावा, हम Redis को ब्रोकर और परिणाम बैकेंड दोनों के रूप में उपयोग कर रहे हैं।

मेरी टिप्पणियों से, जब RabbitMQ को ब्रोकर के रूप में उपयोग किया जाता है, यदि max-tasks-per-child से 1 "

हम जो देख रहे हैं और रिपोर्ट कर रहे हैं वह अलग है। यहां तक ​​कि अगर हम एक कार्य को संसाधित किए बिना कई दिनों के लिए कार्यकर्ता बेकार छोड़ देते हैं, तो यह मेमोरी को एक बिंदु पर लीक कर देता है जब यह मेमोरी सीमा को हिट करता है और पर्यवेक्षक द्वारा मारा जाता है। आप पहले की टिप्पणियों में अधिक विवरण और मेमोरी चार्ट पा सकते हैं।

वर्कर द्वारा शेड्यूल पर एक ही कार्य को संसाधित करने के साथ, मेमोरी चार्ट को कम या ज्यादा एक स्क्वायर वेव की तरह दिखाना चाहिए, लेकिन आप स्पष्ट रूप से देख सकते हैं कि समग्र मेमोरी उपयोग केवल उठाता है।

मैं अपने रोडमैप पर अजवाइन श्रमिकों की रूपरेखा डालने में कामयाब रहा। जब हम इस पर काम करना शुरू करेंगे तो मैं मेमोरी डंप और अधिक विवरण साझा करूँगा।

मैं पुष्टि कर सकता हूं कि फूल को बंद करना (और सेटिंग्स के माध्यम से कार्य की घटनाओं को स्पष्ट रूप से अक्षम करना) ने रिसाव को ठीक कर दिया।

जैसा कि मैंने पहले उल्लेख किया था, उस समय जब मजदूर ने लीक करना शुरू किया तो मैंने फूल में देखा कि यह ऑफ़लाइन हो जाएगा और सेलेरिएव हमेशा काफी व्यस्त दिखा, इसलिए मैं आसान रास्ते से गुजर गया और फूलों को बंद कर दिया।

दुर्भाग्य से मुझे उस कोड का टुकड़ा नहीं मिला जो रिसाव का कारण बनता है। लेकिन कम से कम इस काम के आसपास है।

तो शायद यह अजवाइन का मुद्दा नहीं बल्कि फूल है?

@ युवीपी फूल समस्या को ट्रिगर करता है, लेकिन रिसाव निश्चित रूप से कार्यकर्ता (अजवाइन) पर होता है

@ युवीपी फूल समस्या को ट्रिगर करता है, लेकिन रिसाव निश्चित रूप से कार्यकर्ता (अजवाइन) पर होता है

काफी उचित। साझा करने के लिए धन्यवाद।

मैं सेलेरी का उपयोग रेडिस और फ्लावर के साथ कर रहा हूं, और मुझे यह कहना होगा कि मैं वर्तमान में कोई भी स्मृति समस्या नहीं देख रहा हूं। डेटा के संबंध में आप मुझसे कुछ भी मांग सकते हैं?

@ तावीज़ फूल का उपयोग नहीं। श्रमिकों को विकलांगों के साथ शुरू किया जाता है।

@ तावीज़ फूल का उपयोग नहीं। श्रमिकों को विकलांगों के साथ शुरू किया जाता है।

कृपया डिबग करने की कोशिश करें और मेमोरी लीक की जड़ का पता लगाएं। अजवाइन या आपका हो सकता है। यह सबसे अच्छा होगा यदि आप इकाई और एकीकरण परीक्षण साझा कर सकते हैं

कृपया डिबग करने की कोशिश करें और मेमोरी लीक की जड़ का पता लगाएं। अजवाइन या आपका हो सकता है। यह सबसे अच्छा होगा यदि आप इकाई और एकीकरण परीक्षण साझा कर सकते हैं

यहाँ उल्लेख किया गया हैं , भले ही किसी भी कार्यकर्त्ता द्वारा कोई कार्य संसाधित न किया गया हो।
इकाई या एकीकरण परीक्षण साझा नहीं कर सकते क्योंकि यह कंपनी के आईपी को उजागर करेगा। माफ़ करना। लेकिन मैं हमारे आंतरिक रोडमैप पर उत्पादन श्रमिकों पर मेमोरी डंप को कैप्चर करने के लिए एक कार्य जोड़ने में कामयाब रहा। काम पूरा होने पर कुछ परिदृश्यों के लिए काउंटर और रेफरी साझा करेंगे।

@jsynowiec यदि आप इसे 5.0.0 जीए (अपडेट के लिए # 6266 का पालन करें) से पहले बना सकते हैं जो कि भयानक होगा।

एक बार मास्टर में बगफिक्स लैंड करने के बाद इसे 4.x पर भी वापस भेज दिया जाएगा।

@thedrow 5.0 के GA की योजना कब बनाई गई है? दुर्भाग्य से, हमारे पास कुछ विरासत कोड हैं जो अभी भी Py3 to के लिए माइग्रेट होने के कारण हैं इसलिए हम कुछ समय के लिए Celery 4 के साथ फंस गए हैं।

हमारे पास एक रिलीज अवरोधक है और पूरा करने के लिए कुछ दस्तावेज हैं।
जवाब बहुत जल्द है।

मैं पुष्टि कर सकता हूं कि फूल को बंद करने से रिसाव बंद हो जाता है। हम अब लगभग एक महीने पहले बिना किसी रिसाव के चल रहे हैं।

इसलिए हमारी घटनाओं के प्रकाशन तंत्र में अभी भी एक बग है।
क्या किसी को अंदाजा है कि यह क्या हो सकता है?

हम फूल का उपयोग नहीं करते हैं और श्रमिकों को --events बिना शुरू किया जाता है, फिर भी हम निरंतर मेमोरी लीक का अनुभव करते हैं।

जवाब बहुत जल्द है।

मैं उत्पादन कर्मियों से मेमोरी डंप और ऑब्जेक्ट काउंटर प्राप्त करने के लिए उच्च प्राथमिकता देने में कामयाब रहा हूं। मुझे निम्नलिखित हफ्तों में कुछ डेटा पोस्ट करने में सक्षम होना चाहिए। हमने py2 को अंतिम रूप देने पर भी प्राथमिकता दी है-> py3 पोर्टिंग इसलिए सब कुछ चलना चाहिए, और प्रोफाइल 3 का उपयोग करके प्रोफाइलिंग की जानी चाहिए

मुझे चिंता इस बात की है कि हम यहां दो अलग-अलग मुद्दों पर बात कर रहे हैं।

जाहिरा तौर पर। एक घटनाओं से संबंधित है और शायद फूल, शायद एक दलाल के रूप में रैबिटक्यू का उपयोग कर रहा है। GitHub पर, कुछ वर्षों से यहाँ और वहाँ की समस्याओं के अनुसार। अन्य एक (जो मेरी परियोजना को प्रभावित करता है) विभिन्न घटकों से संबंधित है और सबसे अधिक संभावना है कि एक ब्रोकर के रूप में रेडिस का उपयोग करने से संबंधित है। या हो सकता है कि रूट पर, वे वही मुद्दे हैं जो उसी कोड में उत्पन्न होते हैं जो 🤷🏼 जानता है। जैसे trail सबटुक का ट्रैक रखना और AsyncResult of का इंस्टेंस लीक करना

@thedrow @auvipy आपको यह बताने की अनुमति है कि हम अब श्रमिकों की मेमोरी प्रोफाइलिंग की ओर बढ़ रहे हैं।

इसके अलावा, Python3 माइग्रेशन को अंतिम रूप देते समय हम एक और मुद्दा जो कि https://github.com/celery/celery/issues/4470 या https://github.com/celery/celery/issues/5359 से संबंधित है, पर हिट करते हैं join_native कॉल अनिश्चित काल के लिए लटकाए जाते हैं, जबकि समूह में सभी कार्य पहले से ही किए जा रहे हैं। त्वरित स्ट्रेस इसका शाब्दिक रूप से पढ़ने पर लटकने का संकेत देता है, जो कुछ निम्न-स्तरीय कर्नेल / लिबास सामग्री को इंगित कर सकता है। अभी के लिए हमने मेमोरी पर ध्यान केंद्रित करते हुए join पूल करते हुए सादे पर स्विच किया।

सभी को नमस्कार - अंत में _some_ data: celery-memtrace-1.tar.xz , हस्ताक्षर , मेरी कुंजी ।

संग्रह में ~ 16 दिनों के बाद 8 श्रमिकों से tracemalloc लॉग होते हैं, अवधि के लिए एक मेमोरी उपयोग ग्राफ और कुछ संस्करण जानकारी (सेलेरी स्टार्टअप बैनर सहित)।

मैंने ईमानदारी से किसी भी महत्वपूर्ण समय का विश्लेषण नहीं किया है, लेकिन क) हमारा कोड सूची में कभी नहीं था, ख) यह SQLAlchemy के साथ कुछ अजीब बातचीत हो सकती है जिसका हम हर जगह उपयोग करते हैं, इसलिए यह असंभव नहीं है कि समस्या कहीं और है, या यह एक संयोजन / बातचीत समस्या है।

यदि कोई अन्य विवरण उपयोगी होगा, तो कृपया पूछें। हम इस स्मृति उपयोग लॉगिंग के साथ उन 8 श्रमिकों को चलाना जारी रखते हैं, इसलिए शायद अधिक / बेहतर डेटा एकत्र करने में सक्षम होंगे।

EDIT : इसके अलावा इस थ्रेड की

मुझे आशा है कि आपको इस लीक का मूल कारण मिल जाएगा।
मैं खुद को खोदने के लिए कुछ समय देने की कोशिश करूँगा।

मुझे आश्चर्य है कि अगर यह समस्या को कम करने में मदद कर सकता है।
https://reliability.substack.com/p/run-python-servers-more-efficiently

हम इस संभावना की जांच कर रहे हैं कि स्मृति-लीक मूल अनुरोध पुस्तकालय के भीतर ही नहीं है। कोई और जो कार्यों में अनुरोधों का उपयोग करके अजवाइन में स्मृति-लीक का अनुभव कर रहा है?

@ErrorInPersona हाँ, हम एक जैसे अनुरोधों के साथ श्रमिकों में OOM पंजीकृत कर रहे हैं।

@drbig कोई किस्मत?

ठीक है, "ग्रीन वन" को देखें, मंजिल बढ़ रही है, धीरे-धीरे लेकिन निश्चित रूप से ... तो "यप की त्वरित पुष्टि के अलावा, यह अभी भी एक मुद्दा है" मेरी तरफ से जोड़ने के लिए बहुत नहीं, दुर्भाग्य से।

हालाँकि, मैंने उस लिंक को स्किम कर दिया है, जो @thedrow ने प्रदान किया है और मेरी टू-डू सूची (एक अथाह गड्ढा) में अब - try running some workers with jemalloc forced in , इसलिए मुझे वह मिल जाएगा, _eventually_।