عالق في قراءة الأنبوب.

proc] # ls -l / proc / 8401 / fd
مجموع 0
lr-x ------ 1 dsl dsl 64 May 5 17:26 0 -> pipe: [124716100]
l-wx ------ 1 dsl dsl 64 May 5 17:26 1 -> pipe: [124716101]
lr-x ------ 1 dsl dsl 64 May 5 17:26 10 -> pipe: [124716464]
l-wx ------ 1 dsl dsl 64 May 5 17:26 13 -> pipe: [124716465]

تضمين التغريدة

• متى يحدث هذا عادة؟
• كيف يبدو سجل العامل؟
• هل هناك أيضًا الكثير من استخدام وحدة المعالجة المركزية أو مجرد استهلاك للذاكرة؟

هل تستخدم redis كوسيط؟ رؤية أعراض مماثلة مع سمسار redis على الكرفس 3.1.8 والبلياردو 3.3.0.16. على الرغم من عدم استهلاك ذاكرة عالية.

كذلك هنا. joostdevries يحدث هذا كثيرًا لنا ، ويصعب تحديد الظروف. لدينا 4 عمال يستخدمون خلفية redis.

يقوم العمال بتسجيل الدخول قبل أن يكونوا عالقين:

[2015-08-07 16:50:40,140: INFO/MainProcess] Task feeds.transformers.rss_atom.by[6dbd5f0d-222b-4c5c-bd22-5e05bb63447b] succeeded in 0.0153002970037s: {}
[2015-08-07 16:50:40,141: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[8a582425-456d-4e49-93c8-eb375967cac5]
[2015-08-07 16:50:40,155: INFO/MainProcess] Task feeds.transformers.rss_atom.by[3f60a721-2a6e-4494-bda7-b7b939efe66a] succeeded in 0.00693402900652s: {}
[2015-08-07 16:50:40,157: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[486cc62d-d330-467f-b30c-02005c2038b6]
[2015-08-07 16:50:40,171: INFO/MainProcess] Task feeds.transformers.rss_atom.by[8a582425-456d-4e49-93c8-eb375967cac5] succeeded in 0.0071912699932s: {}
[2015-08-07 16:50:40,173: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[538a71a6-0c33-494a-adfe-575f7465e9d4]
[2015-08-07 16:50:40,188: INFO/MainProcess] Task feeds.transformers.rss_atom.by[486cc62d-d330-467f-b30c-02005c2038b6] succeeded in 0.0155014329939s: {}
[2015-08-07 16:50:40,189: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[2ad9294a-7553-468a-a3dc-73a8f2cea188]
[2015-08-07 16:50:40,203: INFO/MainProcess] Task feeds.transformers.rss_atom.by[538a71a6-0c33-494a-adfe-575f7465e9d4] succeeded in 0.0153862849984s: {}
[2015-08-07 16:50:40,205: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[f7371090-aa05-4194-a327-cb41d1165b7e]
[2015-08-07 16:50:40,220: INFO/MainProcess] Task feeds.transformers.rss_atom.by[2ad9294a-7553-468a-a3dc-73a8f2cea188] succeeded in 0.0158518639946s: {}
[2015-08-07 16:50:40,222: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[6d35c0b2-9c5a-425f-9405-9f7e1fb3aa41]
[2015-08-07 16:50:40,236: INFO/MainProcess] Task feeds.transformers.rss_atom.by[f7371090-aa05-4194-a327-cb41d1165b7e] succeeded in 0.00751440098975s: {}
[2015-08-07 16:50:40,238: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[ed664157-a065-4b15-9bbe-633edf96d230]
[2015-08-07 16:50:40,252: INFO/MainProcess] Task feeds.transformers.rss_atom.by[6d35c0b2-9c5a-425f-9405-9f7e1fb3aa41] succeeded in 0.00709322700277s: {}
[2015-08-07 16:50:40,254: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[683bc593-44c1-4145-b698-1f2ba66a43bd]
[2015-08-07 16:50:40,260: INFO/MainProcess] Task feeds.transformers.rss_atom.by[ed664157-a065-4b15-9bbe-633edf96d230] succeeded in 0.015573162993s: {}
[2015-08-07 16:50:40,275: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[d8018f2b-a1f0-4112-97ba-335cd597be1c]
[2015-08-07 16:50:40,282: INFO/MainProcess] Task feeds.transformers.rss_atom.by[683bc593-44c1-4145-b698-1f2ba66a43bd] succeeded in 0.0205264859978s: {}
[2015-08-07 16:50:40,292: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[92f938ce-894a-49f4-8c89-a090c37b71c8]
[2015-08-07 16:50:40,299: INFO/MainProcess] Task feeds.transformers.rss_atom.by[d8018f2b-a1f0-4112-97ba-335cd597be1c] succeeded in 0.016343981988s: {}
[2015-08-07 16:50:40,302: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[ff12882d-61b8-403e-97ac-b096580de5f0]
[2015-08-07 16:50:40,318: INFO/MainProcess] Task feeds.transformers.rss_atom.by[92f938ce-894a-49f4-8c89-a090c37b71c8] succeeded in 0.0184662840038s: {}
[2015-08-07 16:50:40,330: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[3e0ff326-cd83-4d88-8dee-f9c167a44f6a]
[2015-08-07 16:50:40,338: INFO/MainProcess] Task feeds.transformers.rss_atom.by[ff12882d-61b8-403e-97ac-b096580de5f0] succeeded in 0.0187683639961s: {}
[2015-08-07 16:50:40,341: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[f12efd44-b2be-42fd-8872-5c979421bea3]
[2015-08-07 16:50:40,357: INFO/MainProcess] Task feeds.transformers.rss_atom.by[3e0ff326-cd83-4d88-8dee-f9c167a44f6a] succeeded in 0.0182138609962s: {}
[2015-08-07 16:50:40,359: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[57d8ba02-db1f-40d4-88f9-1d3d83939c2a]
[2015-08-07 16:50:40,374: INFO/MainProcess] Task feeds.transformers.rss_atom.by[f12efd44-b2be-42fd-8872-5c979421bea3] succeeded in 0.0165290409932s: {}
[2015-08-07 16:50:40,385: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[8ae76799-d19d-4acf-b2b4-cfe9d77e3000]
[2015-08-07 16:50:40,393: INFO/MainProcess] Task feeds.transformers.rss_atom.by[57d8ba02-db1f-40d4-88f9-1d3d83939c2a] succeeded in 0.0185826079978s: {}
[2015-08-07 16:50:40,405: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[ca5e9d23-f660-4f88-b7d1-d30b91750727]
[2015-08-07 16:50:40,414: INFO/MainProcess] Task feeds.transformers.rss_atom.by[8ae76799-d19d-4acf-b2b4-cfe9d77e3000] succeeded in 0.0205218030023s: {}
[2015-08-07 16:50:40,417: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[5cfdbbe8-3da1-45b5-b83e-599303ad02eb]
[2015-08-07 16:50:40,433: INFO/MainProcess] Task feeds.transformers.rss_atom.by[ca5e9d23-f660-4f88-b7d1-d30b91750727] succeeded in 0.0175381449953s: {}
[2015-08-07 16:50:40,436: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[cb864c28-b3c5-4def-a5de-8c15049c6d29]
[2015-08-07 16:50:40,453: INFO/MainProcess] Task feeds.transformers.rss_atom.by[5cfdbbe8-3da1-45b5-b83e-599303ad02eb] succeeded in 0.0190771400084s: {}
[2015-08-07 16:50:40,456: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[cc85e444-7969-45ed-98a4-f9ab074db260]
[2015-08-07 16:50:40,473: INFO/MainProcess] Task feeds.transformers.rss_atom.by[cb864c28-b3c5-4def-a5de-8c15049c6d29] succeeded in 0.0191195910011s: {}
[2015-08-07 16:50:40,476: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[4696c784-819d-4278-87fd-b74c2aab4c57]
[2015-08-07 16:50:40,491: INFO/MainProcess] Task feeds.transformers.rss_atom.by[cc85e444-7969-45ed-98a4-f9ab074db260] succeeded in 0.0098425810138s: {}
[2015-08-07 16:50:40,494: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[bce5ad3e-dd4a-4bbc-bb69-9585597ae010]
[2015-08-07 16:50:40,501: INFO/MainProcess] Task feeds.transformers.rss_atom.by[4696c784-819d-4278-87fd-b74c2aab4c57] succeeded in 0.0174191809929s: {}
[2015-08-07 16:50:40,512: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[cfefb0bb-399c-423e-9032-add27dabd6df]
[2015-08-07 16:50:40,526: INFO/MainProcess] Task feeds.transformers.rss_atom.by[bce5ad3e-dd4a-4bbc-bb69-9585597ae010] succeeded in 0.0162074130058s: {}
[2015-08-07 16:50:40,528: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[51f11154-3dbc-448a-a3a4-00c2fe7ab782]
[2015-08-07 16:50:40,543: INFO/MainProcess] Task feeds.transformers.rss_atom.by[cfefb0bb-399c-423e-9032-add27dabd6df] succeeded in 0.0163563999959s: {}
[2015-08-07 16:50:40,545: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[fb900a0c-403f-4941-aa6a-f242312e5d85]
[2015-08-07 16:50:40,560: INFO/MainProcess] Task feeds.transformers.rss_atom.by[51f11154-3dbc-448a-a3a4-00c2fe7ab782] succeeded in 0.0162344239943s: {}
[2015-08-07 16:50:40,563: INFO/MainProcess] Received task: feeds.transformers.rss_atom.by[330fff18-71e0-4d9e-9ad1-0111d44f7e03]

لا استخدام وحدة المعالجة المركزية واستخدام الذاكرة (الإخراج من الأعلى):

31059 celery    20   0  517176  64388   3456 S  0.0  1.7   0:14.86 celery                                                                                                                                                                                   
31058 celery    20   0  517204  64308   3456 S  0.0  1.7   0:14.32 celery                                                                                                                                                                                   
31062 celery    20   0  517044  64308   3456 S  0.0  1.7   0:14.88 celery                                                                                                                                                                                   
31061 celery    20   0  516912  63508   3064 S  0.0  1.7   0:14.32 celery                                                                                                                                                                                   
31046 celery    20   0  369344  63396   6964 S  0.0  1.7   1:09.70 celery                                                                                                                                                                                   
16967 celery    20   0  366648  57396   7612 S  0.0  1.6   0:04.04 celery        

سيحاول تعيين BROKER_TRANSPORT_OPTIONS = {'socket_timeout': 10} ومعرفة ما إذا كان ذلك مفيدًا.

domenkozar هل ساعدت؟

راجع https://github.com/andymccurdy/redis-py/issues/306

ربما لا:

[root@ip-172-30-0-183 ec2-user]# lsof -p 9253|grep 6379
celery  9253 celery   10u     IPv4            2738405       0t0      TCP ip-172-30-0-183.ec2.internal:37155->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  9253 celery   23u     IPv4            2737905       0t0      TCP ip-172-30-0-183.ec2.internal:37090->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  9253 celery   33u     IPv4            2737956       0t0      TCP ip-172-30-0-183.ec2.internal:37098->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  9253 celery   36u     IPv4            2737990       0t0      TCP ip-172-30-0-183.ec2.internal:37105->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  9253 celery   46u     IPv4            2739860       0t0      TCP ip-172-30-0-183.ec2.internal:37297->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
[root@ip-172-30-0-183 ec2-user]# lsof -p 9253|grep CLOSE_WAIT
celery  9253 celery   11u     IPv4            2739163       0t0      TCP ip-172-30-0-183.ec2.internal:45206->wordpress.com:http (CLOSE_WAIT)
celery  9253 celery   16u     IPv4            2737802       0t0      TCP ip-172-30-0-183.ec2.internal:53865->205.251.242.33:https (CLOSE_WAIT)
celery  9253 celery   32u     IPv4            2764510       0t0      TCP ip-172-30-0-183.ec2.internal:48242->ec2-52-2-102-195.compute-1.amazonaws.com:http (CLOSE_WAIT)
celery  9253 celery   37u     IPv4            2739073       0t0      TCP ip-172-30-0-183.ec2.internal:45198->wordpress.com:http (CLOSE_WAIT)
celery  9253 celery   38u     IPv4            2738052       0t0      TCP ip-172-30-0-183.ec2.internal:36962->230-156-220-74-available.ilandcloud.com:http (CLOSE_WAIT)
celery  9253 celery   39u     IPv4            2738313       0t0      TCP ip-172-30-0-183.ec2.internal:46067->qb-in-f118.1e100.net:http (CLOSE_WAIT)
celery  9253 celery   40u     IPv4            2739202       0t0      TCP ip-172-30-0-183.ec2.internal:43252->r2.ycpi.vip.dcb.yahoo.net:http (CLOSE_WAIT)
celery  9253 celery   42u     IPv4            2739382       0t0      TCP ip-172-30-0-183.ec2.internal:45228->wordpress.com:http (CLOSE_WAIT)
celery  9253 celery   43u     IPv4            2739488       0t0      TCP ip-172-30-0-183.ec2.internal:38920->wordpress.com:http (CLOSE_WAIT)
celery  9253 celery   45u     IPv4            2739667       0t0      TCP ip-172-30-0-183.ec2.internal:57721->ec2-54-165-198-100.compute-1.amazonaws.com:https (CLOSE_WAIT)

تُظهر Flower جميع العمال على أنهم غير متصلون بالإنترنت ، ويبدو أن العمال ينتظرون فقط مهمة ما.

فرضية جديدة: أعتقد أن السبب الرئيسي وراء ذلك هو أن ذاكرة redis نفدت (هناك بعض آثار OOM) ، وأن السيد غير قادر على إرسال مهام جديدة إلى العاملين.

تبدو الدعامة التي تراها طبيعية بالنسبة لي ، ألا تنتظر فقط المزيد من المهام؟ أعتقد أنه من المحتمل أنه تم إرسال بيانات غير كاملة (مع ملاحظة وجود شيء ما في المخزن المؤقت)

نعم ، يبدو أن العمال ينتظرون المزيد من المهام ، لذلك هناك شيء ما يحدث مع عملية الكرفس الرئيسية. تحتوي قائمة انتظار المهام على 100 ألف عنصر.

لذلك قمت بمسح قائمة انتظار redis celery ونبض الكرفس في العملية الرئيسية لا يقوم بجدولة مهام جديدة. بالنظر إلى gdb ، فإنه يفعل ما يجب عليه:

(gdb) py-list
 115            buf.seek(self.bytes_written)
 116            marker = 0
 117
 118            try:
 119                while True:
>120                    data = self._sock.recv(socket_read_size)
 121                    # an empty string indicates the server shutdown the socket
 122                    if isinstance(data, bytes) and len(data) == 0:
 123                        raise socket.error(SERVER_CLOSED_CONNECTION_ERROR)
 124                    buf.write(data)
 125                    data_length = len(data)

Aha ، وجدت أي اتصال كان هو المشكلة ، من CLIENT LIST :

id=497 addr=172.30.0.183:45591 fd=20 name= age=1142 idle=1142 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL

من المثير للاهتمام أنه يرسل cmd=NULL وأن الاتصال يأتي من عامل الكرفس الرئيسي. @ اسأل أي أفكار؟

لذا بالطريقة التي أراها ، تجمع اتصالات redis يتم تحفيزها. إذا قمت بقتل بعض الاتصال العشوائي على جانب redis ، فسيذهبون إلى CLOSE_WAIT state ، لكن عملية الكرفس الرئيسية تبقيهم مفتوحين

لدينا العديد من المهام الصغيرة ، لذلك يتم انتقاء المهام بسرعة كبيرة.

يمكنك أن ترى أن هناك 11 اتصالًا وقد قُتل اثنان منهم من جانب redis باستخدام الأمر CLIENT KILL :

[root@ip-172-30-0-183 ec2-user]# lsof -p 24747|grep TCP
celery  24747 celery   10u     IPv4            3619402       0t0      TCP ip-172-30-0-183.ec2.internal:45535->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   11u     IPv4            3619425       0t0      TCP ip-172-30-0-183.ec2.internal:45544->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   16u     sock                0,6       0t0  3113866 protocol: TCP
celery  24747 celery   34u     IPv4            3619406       0t0      TCP ip-172-30-0-183.ec2.internal:45537->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   35u     IPv4            3619421       0t0      TCP ip-172-30-0-183.ec2.internal:45543->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   36u     IPv4            3619417       0t0      TCP ip-172-30-0-183.ec2.internal:45542->ip-172-30-3-169.ec2.internal:6379 (CLOSE_WAIT)
celery  24747 celery   37u     IPv4            3619431       0t0      TCP ip-172-30-0-183.ec2.internal:45545->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   38u     IPv4            3619435       0t0      TCP ip-172-30-0-183.ec2.internal:45546->ip-172-30-3-169.ec2.internal:6379 (CLOSE_WAIT)
celery  24747 celery   39u     IPv4            3619437       0t0      TCP ip-172-30-0-183.ec2.internal:45547->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   40u     IPv4            3703870       0t0      TCP ip-172-30-0-183.ec2.internal:46884->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   41u     IPv4            3619441       0t0      TCP ip-172-30-0-183.ec2.internal:45549->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)
celery  24747 celery   42u     IPv4            3619443       0t0      TCP ip-172-30-0-183.ec2.internal:45550->ip-172-30-3-169.ec2.internal:6379 (ESTABLISHED)

لذا فهي أيضًا ليست مجموعة اتصالات يتم تضخيمها. لقد زدته إلى 20 وحاليًا تعطلت مع 8 اتصالات.

هذا هو التتبع الذي يحدث عندما أقوم بقتل اتصال cmd=NULL :

[2015-09-06 11:34:44,336: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
  File "/opt/cmgd/venv/lib/python2.7/site-packages/celery/worker/consumer.py", line 278, in start
    blueprint.start(self)
  File "/opt/cmgd/venv/lib/python2.7/site-packages/celery/bootsteps.py", line 123, in start
    step.start(parent)
  File "/opt/cmgd/venv/lib/python2.7/site-packages/celery/worker/consumer.py", line 821, in start
    c.loop(*c.loop_args())
  File "/opt/cmgd/venv/lib/python2.7/site-packages/celery/worker/loops.py", line 70, in asynloop
    next(loop)
  File "/opt/cmgd/venv/lib/python2.7/site-packages/kombu/async/hub.py", line 267, in create_loop
    tick_callback()
  File "/opt/cmgd/venv/lib/python2.7/site-packages/kombu/transport/redis.py", line 942, in on_poll_start
    [add_reader(fd, on_readable, fd) for fd in cycle.fds]
  File "/opt/cmgd/venv/lib/python2.7/site-packages/kombu/async/hub.py", line 201, in add_reader
    return self.add(fds, callback, READ | ERR, args)
  File "/opt/cmgd/venv/lib/python2.7/site-packages/kombu/async/hub.py", line 152, in add
    self.poller.register(fd, flags)
  File "/opt/cmgd/venv/lib/python2.7/site-packages/kombu/utils/eventio.py", line 78, in register
    self._epoll.register(fd, events)
IOError: [Errno 9] Bad file descriptor
[2015-09-06 11:34:44,339: WARNING/MainProcess] Restoring 1 unacknowledged message(s).
[2015-09-06 11:34:44,398: INFO/MainProcess] Connected to redis://mas-re-13j3y6r7dd9ui.vfavzi.0001.use1.cache.am

أعتقد أنني وجدت طريقة للجميع لإعادة إنتاج هذا ، وجدولة بضعة آلاف من المهام الوهمية التي لا تفعل أي شيء.

يقوم 4 عمال بمعالجة حوالي 170 مهمة / ثانية ثم يتعثرون.

والرسوم البيانية للزهور تظهر تعليق http://i.imgur.com/1q0A8DN.png

نحن نصدر نفس المشاكل هنا.
يقوم RabbitMQ بالمهمة في الوقت الحالي تمامًا.
نحن نفضل redis بسبب مشاكل الأداء.

يتوقف عمالنا بعد فترة قصيرة مع redis ، وليس رسائل خطأ أو أي شيء يبدو مريبًا.
تعيين socket_timeout لم يحل المشكلة.

domenkozar ما التكوين الذي تستخدمه؟ أقوم بتنفيذ 100 ألف مهمة باستخدام redis غالبًا مع مجموعة اختبارات التحمل.

إذا كانت تستهلك قدرًا كبيرًا من الذاكرة ، فهل لديك خيارات النقل fanout_prefix و fanout_patterns معيَّنة؟ http://docs.celeryproject.org/en/latest/getting-started/brokers/redis.html#caveats

ask للأسف لا يمكنني الوصول إلى هذه البيئة بعد الآن ، لكننا لم نغير إعدادات fanout_*

في حالتي ، أرى العملية الرئيسية للعامل في حلقة ضيقة عند وحدة المعالجة المركزية بنسبة 100٪ بينما تجلس عملية أداء العمل بهدوء لا تفعل شيئًا.

يشير strace إلى أن fd = 3 (دائمًا نفس fd) يتم استقصائه باستمرار ، ويعود الاستطلاع POLLIN | POLLHUP .

strace -p 9988

poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLOUT|POLLHUP}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])

lsof :

celeryd:   9988   sentry    3u     sock        0,6      0t0  566337941 can't identify protocol

لقد قرأت في مكان ما هذا مؤشر على اتصال مقبس نصف مغلق.

لكن هذا بقدر ما حصلت عليه. تمنحني قراءة هذا الموضوع مزيدًا من التلميحات للاهتمام بها في المرة القادمة التي تبدأ فيها المشكلة.

أنا في نفس المشروع الذي كان يعمل domenkozar عليه ، ونرى هذه المشكلة مرة أخرى. يُظهر strace عمليات العامل معلقة في قراءة () syscall.

ومن المثير للاهتمام ، أن التوقفات قد اختفت لأشهر ولم تبدأ في التكرار إلا مؤخرًا عندما أضفنا المزيد من العمل إلى النظام من خلال معالجة المزيد من المهام ، لذلك بطريقة ما تعتمد على التوقيت أو الحمل.

إصدارات الحزمة: amqp-1.4.9 ، البلياردو -3.3.0.23 ، kombu-3.0.35 ، الكرفس 3-1.23.

كيف يجب أن أقوم بتصحيح هذا؟ هل يجب أن أحاول إجراء عمليات التجويف في لعبة البلياردو أم في الكومبو أم في الكرفس؟

akuchling ، هل يمكنك استخدام redis-cli ونشر ناتج CLIENT LIST ؟

أيضًا ، يجب أن أتحقق مرة أخرى من أن جميع الخوادم تستخدم kombu-3.0.35

الإصدار رقم من kombu هو في الواقع 3.0.35. تعرض "قائمة العميل" ما يلي: http://dpaste.com/2GGCECS (عناوين IP منقحة قليلاً).

مثير للإعجاب! في هذا dpaste ، لا يوجد عميل مدرج حيث cmd = null ، لذلك ربما يكون هذا وضع فشل جديد. لا يبدو لي أننا نملأ ذاكرة ريديس في الوقت الحالي ؛ تبلغ بياناتنا حوالي 3 جيجابايت على جهاز AWS بسعة 6 جيجابايت.

لدينا socket_timeout مضبوطًا على 10 ، لكن هذا لا يحل المشكلة. بدلاً من ذلك ، ينتهي الكرفس ببعض المهام كل 10 ثوانٍ ثم يتجمد مرة أخرى. لاحظ كيف أن رقم الثواني يتزايد: 37 ، 47 ، 57 في هذا dpaste: http://dpaste.com/2AZYEH4

لقد وجدت نفسي أنظر إلى on_stop_not_started () في الكرفس / المتزامن / asyncpool.py لأنه ظهر في GDB stacktrace ، وكان في حيرة من استخدام انتظار _remove_fd.

يتم إعطاءه في البداية قيمة مجموعة فارغة. ثم الكود يفعل: for fd in outqueues: self._flush_outqueue(fd, pending_remove_fd.discard, ...) ويزيل محتويات waiting_remove_fd من outqueues.

خطأ: المجموعة فارغة في البداية ، و _flush_outqueues () تستدعي pending_remove_fd.discard() . إذن كيف يتم ملء مجموعة pending_remove_fd ؟ هل كان من المفترض أن تتم تهيئته كـ = set(outqueues) لعمل نسخة من مجموعة البداية من fds؟ أو أخطأت في قراءة شيء ما؟

akuchling ، أعتقد أنه يجب أن يكون pending_remove_fds.add بدلاً من pending_remove_fds.discard هناك

لذلك في نهاية هذه الحلقة ، ستزيل العناصر الخارجية المتدفقة عندما تفعل outqueues.difference_update(pending_remove_fd)

شكرا! هل يجب الالتزام بهذا التغيير أيضًا في الفرع 3.1 (وهو ما قمت به في مفترق حتى يمكنني اختباره)؟

لسوء الحظ ، فإن التصحيح المعلق في انتظار المراجعة لا يصلح كل شيء معلق بالنسبة لنا ، على الرغم من أنه لا يبدو أنه يسبب أي مشاكل. مع التصحيح ، حصلت أيضًا على عامل / رئيسي معلق: يقوم السيد بقراءة () من العامل ، والعامل في قراءة () في Billiard_conn_recv () ، يتم استدعاؤه من pickle.load (). أي اقتراحات لما قد يكون هذا؟

إغلاق هذا ، لأننا لا نملك الموارد لإكمال هذه المهمة.

يمكن إصلاحه بشكل رئيسي ، دعنا نرى ما إذا كان سيعود بعد الإصدار 4.0.

akuchlingdomenkozar - تم مناقشة هذه المسألة استمر في أي مكان / لم تجد أي قرار؟

من خلال البحث في قائمة المشكلات ، يوجد الكثير من "شيء ما معطل" ولكن يبدو أن هذا هو الأقرب إلى المشكلات التي نراها.

للأسف لم يعد أحد منا يعمل في الشركة حيث كان هذا يحدث في الإنتاج.

akuchling تولى جهودي السابقة ، ربما يمكنه الإبلاغ عن التحديث الأخير إذا تم إصلاح هذا الخطأ بالفعل أم لا.

JonPeel : لا أتذكر ما إذا كنا قد توصلنا إلى حل. لتلخيص التغييرات التي طبقناها:

• في BROKER_TRANSPORT_OPTIONS في settings.py ، أضفنا:

 'socket_timeout': 10,                # timeout in case of network errors
 'fanout_prefix': True,
 'fanout_patterns': True,

• استخدمنا شوكة من الكرفس 3.1 مع الالتزام 320777611a0e349f08f4bb3ca2d36c9036eda330 (خطأ on_stop_not_started () الذي وجدته أعلاه).

JonPeel الآن أنا أقوم بتشغيل 4.0.22 (وأخطط للتحديث إلى 4.1). لم أجد هذه المشكلة بعد الآن.

أجد من الوقت عاملًا واحدًا لديه -c1 (للتسلسل) لا يستجيب بعد الوصول إلى الحد الأقصى من الوظائف (2000). يبدو أنه عند محاولة قتل الطفل العامل وإعادة إنجابه ، فإنه يعلق. لكنني لم أستكشف بعمق: من الغريب أن إعادة تشغيل العامل تجعله يعمل بشكل جيد: حتى إعادة تدوير الطفل العامل بعد الوصول إلى 2000 وظيفة أخرى. لذلك لا أعتقد أنه مرتبط بالكرفس ولكن بتطبيقنا.

شكرا على الردود؛ سيفتح تذكرة جديدة إذا تكررت مشكلاتنا (للمرجع: Celery 4.1 ، وسيط Redis وخلفية النتيجة: 2.10.5 redis-py ، و Redis 3.2.0 ، وتم تمكين SSL).

من خلال ما رأيته ، نجعل العمال عالقين في الاستماع إلى الاتصالات التي لا تفعل شيئًا (CLOSE_WAIT) واستئناف العمل كالمعتاد.

من ذلك ، يبدو https://github.com/andymccurdy/redis-py/issues/306 أكثر صلة بنا مما كان أعلاه. إذا كان الأمر كذلك ، فهي أ) مشكلة في redis-py وليس الكرفس و b) يبدو أنها تتأثر بشكل إيجابي بـ socket_timeout في BROKER_TRANSPORT_OPTIONS كما هو مقترح أعلاه. كانت إعادة التشغيل مطلوبة كل 24 ساعة أو نحو ذلك ، ولم يعد يبدو أن هناك مشكلة.

أنا أواجه هذه المشكلة في

الكرفس 4.1.0
redis-py 2.10.6.0 تحديث

الكرفس معلق على redis-py connection.py

return sock.recv(*args, **kwargs)

هنا المكدس

 [2017-11-24 04:11:08,423: WARNING/MainProcess] File "/usr/bin/celery", line 11, in <module>
     sys.exit(main())
 [2017-11-24 04:11:08,423: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/__main__.py", line 14, in main
     _main()
 [2017-11-24 04:11:08,423: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/celery.py", line 326, in main
     cmd.execute_from_commandline(argv)
 [2017-11-24 04:11:08,424: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/celery.py", line 488, in execute_from_commandline
     super(CeleryCommand, self).execute_from_commandline(argv)))
 [2017-11-24 04:11:08,425: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/base.py", line 281, in execute_from_commandline
     return self.handle_argv(self.prog_name, argv[1:])
 [2017-11-24 04:11:08,425: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/celery.py", line 480, in handle_argv
     return self.execute(command, argv)
 [2017-11-24 04:11:08,425: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/celery.py", line 412, in execute
     ).run_from_argv(self.prog_name, argv[1:], command=argv[0])
 [2017-11-24 04:11:08,426: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/worker.py", line 221, in run_from_argv
     return self(*args, **options)
 [2017-11-24 04:11:08,426: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/base.py", line 244, in __call__
     ret = self.run(*args, **kwargs)
 [2017-11-24 04:11:08,427: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bin/worker.py", line 256, in run
     worker.start()
 [2017-11-24 04:11:08,427: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/worker/worker.py", line 203, in start
     self.blueprint.start(self)
 [2017-11-24 04:11:08,428: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bootsteps.py", line 119, in start
     step.start(parent)
 [2017-11-24 04:11:08,428: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bootsteps.py", line 370, in start
     return self.obj.start()
 [2017-11-24 04:11:08,429: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/worker/consumer/consumer.py", line 320, in start
     blueprint.start(self)
 [2017-11-24 04:11:08,429: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/bootsteps.py", line 119, in start
     step.start(parent)
 [2017-11-24 04:11:08,429: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/worker/consumer/consumer.py", line 596, in start
     c.loop(*c.loop_args())
 [2017-11-24 04:11:08,430: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/celery/worker/loops.py", line 88, in asynloop
     next(loop)
 [2017-11-24 04:11:08,430: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/kombu/async/hub.py", line 354, in create_loop
     cb(*cbargs)
 [2017-11-24 04:11:08,431: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/kombu/transport/redis.py", line 1040, in on_readable
     self.cycle.on_readable(fileno)
 [2017-11-24 04:11:08,431: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/kombu/transport/redis.py", line 337, in on_readable
     chan.handlers[type]()
 [2017-11-24 04:11:08,431: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/kombu/transport/redis.py", line 667, in _receive
     ret.append(self._receive_one(c))
 [2017-11-24 04:11:08,432: WARNING/MainProcess] File "/usr/lib/python3.6/site-packages/kombu/transport/redis.py", line 678, in _receive_one
     response = c.parse_response()
 [2017-11-24 04:11:08,432: WARNING/MainProcess] File "/usr/local/cedar/utils/redis/client.py", line 2448, in parse_response
     return self._execute(connection, connection.read_response)
 [2017-11-24 04:11:08,432: WARNING/MainProcess] File "/usr/local/cedar/utils/redis/client.py", line 2437, in _execute
     return command(*args)
 [2017-11-24 04:11:08,433: WARNING/MainProcess] File "/usr/local/cedar/utils/redis/connection.py", line 604, in read_response
     response = self._parser.read_response()
 [2017-11-24 04:11:08,433: WARNING/MainProcess] File "/usr/local/cedar/utils/redis/connection.py", line 259, in read_response
     response = self._buffer.readline()
 [2017-11-24 04:11:08,434: WARNING/MainProcess] File "/usr/local/cedar/utils/redis/connection.py", line 185, in readline
     traceback.print_stack()

يحدث هذا عندما تتم إعادة تعيين الاتصال قبل انتهاء المهلة (موازن التحميل في حالتي). يتم إرسال حدث خطأ على المقبس ، ولكن بعد ذلك يحاول الكرفس القراءة من المقبس. نظرًا لأن المقبس مغلق ، لا توجد بيانات متاحة ويتوقف إلى الأبد. يحدث هذا على وجه التحديد على اتصال pubsub redis في الكرفس ، نظرًا لأن هذا اتصال طويل الأمد.

ستعمل المعلمة socket_timeout حل مشكلة الحظر وستظهر خطأ بعد انتهاء المهلة ، ولكن هناك مشكلة أساسية يجب ألا يقرأها الكرفس من مقبس مغلق.

كان الإصلاح غير الكامل الذي قمت به هو استخدام هذا التصحيح في redis-py.
https://github.com/andymccurdy/redis-py/pull/886

بالإضافة إلى هذا الإصلاح المخصص للحانة
https://github.com/cedar-team/redis-py/compare/f9348968dec581830a32e8469228c74ce443bd88...cedar- فريق : 6aae12c96b733ad0b6e896001f0cf576fa26280a

+1. ضرب هذه المشكلة أيضًا:

• لا يزال الكرفس قيد التشغيل ، ولكنه لا يعالج المهام
• يظهر strace أنه محظور على recvfrom
• رؤية cmd=NULL في Redis للاتصال

ericholscher إذا كنت تستخدم hiredis ، فحاول بدونه. انظر # 4321 و # 3898.

mvaled نحن - سأحاول بدونها. شكرا.

إعادة الإبلاغ ، يبدو أن إزالة hiredis قد أصلحت المشكلة. شكرا! 👍

شكرا ايريك