نشاط أعلى لعملية الخمول بعد الترقية

الدعم تثبيت
1

مرحباً،
بعد ترقية Discourse إلى الإصدار v2.5.0.beta4-399-gbf8085e436 (من إصدار 2.4 تقريباً، باستخدام التمهيد عبر سطر الأوامر من مستودع discourse_docker على Git، قبل عمليات الترقية الخاصة بـ Postgres 12)، لوحظ زيادة ملحوظة في استهلاك وحدة المعالجة المركزية على الخادم (حتى في حال عدم وجود أي مستخدم متصل).

يُظهر أمر “top” أن عدة عمليات “ruby” نشطة بشكل متكرر. وقد فهمت أن هذه هي عمال Unicorn Sidekiq. وعند تشغيل أمر redis-cli monitor، أرى أنها تُصدر طلبات BRPOP حاصرة بمهلة زمنية مقدارها 2 ثانية للتحقق من وجود عمل يجب إنجازه. وبالتالي، فإن هذا يؤدي إلى تنفيذ نحو اثني عشر أمراً لـ Redis في الثانية. كما يتم تحديث الإحصائيات كل 5 ثوانٍ. ويُظهر أمر redis-cli info stats أن هناك في المتوسط 15-20 أمراً تتم معالجته في الثانية.

لا أعرف ما إذا كان هذا النشاط يمكن أن يتراكم ليصل إلى استهلاك وحدة المعالجة المركزية بنسبة 2-4% الذي نلاحظه. فمع الإصدار القديم، كان الاستهلاك أقل من 0.5%. ولم أقم بمراجعة إحصائيات redis-cli نفسها في ذلك الوقت.

أود أن أجرب تجربة مهلة زمنية أطول لأرى ما إذا كان ذلك سيساعد، لكنني لم أتمكن حتى الآن من معرفة كيفية القيام بذلك.

2

هل هذا مرتبط بعملك يا @eviltrout؟

3

أي عمل كنت تفكر فيه؟ لا أعتقد أن أي شيء عملت عليه مؤخرًا قد يتسبب في ذلك.

4

خطئي، كنت أفكّر في ember-cli

5

تحقق من forum.example.com/sidekiq - قد تكون هناك بعض مهام المعالجة الخلفية قيد التنفيذ بعد الترقية.

6

من غير المرجح جدًا أن يكون قد تلامس مع Redis. لن أقول أبدًا

7

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

ربما يكون هذا خارج نطاق الموضوع، لكن من المثير للاهتمام أيضًا مخطط “المعالجة” على مدى 6 أشهر، حيث يبدو أنه يحتوي على مستويين ثابتين (أحدهما أعلى بمرتين من الآخر) يتنقل بينهما مع فترات أسابيع بينهما. ولا يرتبط ذلك بإعادة التشغيل (ولم نقم بتحديث هذه العناصر خلال تلك الفترة أيضًا).

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

9

هذه هي الأشياء التي أراها أحيانًا في top:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                     
   1024 discour+  20   0  333584 202888  21660 S   1.3   2.5   3:35.81 ruby                                                                        
   1156 discour+  20   0  715904 249416  24532 S   1.3   3.1   3:26.50 ruby                                                                        
   1178 discour+  20   0  726664 251468  24564 S   1.3   3.1   3:26.11 ruby                                                                        
   1189 discour+  20   0  714368 247912  24444 S   1.3   3.1   3:24.56 ruby                                                                        
   1200 discour+  20   0  709760 249708  24632 S   1.3   3.1   3:22.96 ruby                                                                        
   1234 discour+  20   0  713344 250288  24636 S   1.3   3.1   3:30.24 ruby                                                                        
   1167 discour+  20   0  712832 247928  24436 S   1.0   3.1   3:24.75 ruby                                                                        
 188658 me        20   0   10424   4240   3576 R   0.7   0.1   0:00.36 top                                                                         
    448 root      20   0 1748444  84900  45884 S   0.3   1.1   6:09.98 dockerd

دون أي اتصال…

الوقت المتراكم للمعالج البالغ 3.5 دقائق لكل عملية يأتي بعد 35 ساعة من التشغيل، مع نشاط مستخدم ضئيل جدًا.

كما حاولت استخدام rbtrace، لكنه يشتكي:
(pid is not listening for messages, did you require “rbtrace”)
هل أحتاج إلى إعادة بناء الصورة لإصلاح ذلك؟ أم يمكنني مجرد تعديل أو إعادة بناء شيء ما داخل الحاوية؟