Supervisor: استخدام وحدة المعالجة المركزية بنسبة 100٪ (ربما بسبب تنفيذ استطلاع جديد؟)

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

شهد hathawsh أيضًا

عند القراءة من الاستقامة ، نلاحظ وجود مكالمات مفرطة لكل من "gettimeofday" و "استطلاع" ، لذلك بعد ذلك ، علينا أن نختار خفض رتبة المشرف إلى 3.2.3.

من المحتمل أن تكون هذه هي الحلقة الرئيسية التي تدور لأن poller.poll() يقوم بـ poll وأدناه tick() يقوم بـ gettimeofday .

هل يمكنك تشغيل 3.3.0 بـ loglevel=blat ؟ سيؤدي ذلك إلى إنتاج أكبر قدر ممكن من معلومات التصحيح. ربما سيكون لديها بعض القرائن على سبب حدوث ذلك.

وربما بسبب نواتج السجل في وقت واحد؟

لم تكن هناك أي تغييرات على التسجيل بين 3.2.3 و 3.3.0. نظرًا لأنك قلت أن 3.2.3 تعمل من أجلك ، فلن أشك في تسجيل الدخول.

مرحبا!
اليوم اكتشفت المشكلة مرة أخرى ، هنا سجل strace gz'd (المدة ~ 1 ثانية):
strace.log.tar.gz
وهنا fds:

0 -> /dev/null
1 -> /dev/null
10 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
100 -> pipe:[32356299]
101 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
102 -> pipe:[32356298]
103 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
104 -> pipe:[32356300]
105 -> /data/supervisor_log/bg_task_00-stderr.log
106 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
107 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
108 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
109 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
11 -> pipe:[3024]
110 -> /data/supervisor_log/bg_task_00-stdout.log
111 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
112 -> /data/supervisor_log/bg_task_00-stderr.log
113 -> pipe:[32356302]
114 -> pipe:[32356301]
115 -> pipe:[32356303]
116 -> /data/supervisor_log/bg_task_00-stdout.log.1
117 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
118 -> /data/supervisor_log/bg_task_00-stderr.log
119 -> /data/supervisor_log/bg_task_00-stdout.log.8
12 -> pipe:[17721748]
121 -> pipe:[32356304]
124 -> /data/supervisor_log/bg_task_00-stderr.log
13 -> pipe:[17721749]
14 -> pipe:[11775]
15 -> pipe:[3025]
16 -> pipe:[11776]
17 -> /data/supervisor_log/bg_task_02-stdout.log
18 -> /data/supervisor_log/bg_task_02-stderr.log
19 -> pipe:[17721751]
2 -> /dev/null
20 -> pipe:[11777]
21 -> pipe:[17721750]
22 -> /data/supervisor_log/bg_task_03-stdout.log
23 -> /data/supervisor_log/bg_task_03-stderr.log
24 -> pipe:[11827]
25 -> pipe:[17721752]
26 -> pipe:[11828]
27 -> /data/supervisor_log/bg_task_01-stdout.log.1
28 -> /data/supervisor_log/bg_task_01-stderr.log.2
29 -> pipe:[17721754]
3 -> /data/supervisor_log/supervisord.log
30 -> pipe:[11829]
31 -> pipe:[17721753]
32 -> /data/supervisor_log/bg_task_04-stdout.log
33 -> /data/supervisor_log/bg_task_04-stderr.log
34 -> pipe:[17721755]
35 -> /data/supervisor_log/bg_task_01-stdout.log
36 -> /data/supervisor_log/bg_task_01-stderr.log.1
37 -> pipe:[17721757]
38 -> pipe:[17721756]
39 -> pipe:[17721758]
4 -> socket:[13073]
40 -> /data/supervisor_log/bg_task_01-stdout.log.3
41 -> /data/supervisor_log/bg_task_01-stderr.log
42 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
43 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
44 -> pipe:[17721759]
45 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
46 -> pipe:[17719642]
47 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
48 -> pipe:[17719643]
49 -> /data/supervisor_log/bg_task_01-stdout.log.2
5 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
50 -> pipe:[17719644]
51 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
52 -> /data/supervisor_log/bg_task_01-stderr.log.3
53 -> /data/supervisor_log/bg_task_05-stdout.log
54 -> /data/supervisor_log/bg_task_05-stderr.log
55 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
56 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
57 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
58 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
59 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
6 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
60 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
61 -> pipe:[30456289]
62 -> pipe:[30456290]
63 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
64 -> /data/supervisor_log/node_exporter.log
65 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
66 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
67 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
68 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
69 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
7 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
70 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
71 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
72 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
73 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
74 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
75 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
76 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
77 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
78 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
79 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
8 -> /data/supervisor_log/bg_task_01-stdout.log.10 (deleted)
80 -> /data/supervisor_log/bg_task_00-stderr.log
81 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
82 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
83 -> /data/supervisor_log/bg_task_00-stderr.log
84 -> /data/supervisor_log/bg_task_00-stdout.log.2
85 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
86 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
87 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
88 -> /data/supervisor_log/bg_task_00-stderr.log
89 -> /data/supervisor_log/bg_task_00-stderr.log
9 -> pipe:[3023]
90 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
91 -> /data/supervisor_log/bg_task_00-stdout.log.10 (deleted)
92 -> /data/supervisor_log/bg_task_00-stdout.log.8
93 -> pipe:[32356293]
94 -> pipe:[32356294]
95 -> pipe:[32356296]
96 -> pipe:[32356295]
97 -> pipe:[32356297]
98 -> /data/supervisor_log/bg_task_00-stdout.log.3
99 -> /data/supervisor_log/bg_task_00-stderr.log

لم أفتح المستوى blather حتى الآن ، سأحاول ذلك الآن ، وسأرى ما يحدث.

مرحبًا ، أنا مرة أخرى ، هذا هو سجل المشرف مع تمكين مستوى Blather:
المشرف .log.tar.gz

أنا أيضًا ، في كل مرة عندما أقوم بتسجيل الدخول باستخدام http وإعادة تشغيل أحد البرامج ، تنتقل وحدة المعالجة المركزية لخادمي على الفور إلى 100٪.
لقد ضيعت الكثير من الوقت في هذا الخطأ!
لقد استخدمته لإدارة قائمة انتظار Laravel الخاصة بي. أنا أكره ذلك ، لكن ليس لديّ خيار!

هذا قابل لإعادة الإنتاج بنسبة 100٪ على 3.3.1 (حزمة الأناكوندا على OSX).
-بدء مشرف مع خادم http على المضيف المحلي
-فتح وحدة تحكم ipython جديدة واستيراد xmlrpclib واكتبه
server = xmlrpclib.Server ('http: // localhost: 9001')
- الآن قم بتشغيل أي server.getMethod ووحدة المعالجة المركزية على الفور تذهب إلى 100٪ وتبقى هناك
-del (الخادم) ووحدة المعالجة المركزية يعودان إلى طبيعتهما.

المشكله ... هذا سدادة عرض لما أحتاجه. اسمحوا لي أن أعرف إذا كانت هناك حاجة إلى أي معلومات أخرى. سأضطر إلى الرجوع إلى إصدار أقدم ومعرفة ما إذا كان الإصدار الأقدم لا يظهر هذا السلوك.

تحديث: لقد رجعت إلى الإصدار 3.1.3 وهذا السلوك غير موجود. حدث شيء ما بالتأكيد بين هذين الإصدارين ، لكن ليس لدي أي من فروع 3.2.x المتاحة للاختبار بسهولة.

أستطيع أن أؤكد هذا. محبط جدا 😞

igorsobreira أبلغ عدد من المستخدمين عن استخدام عالٍ لوحدة المعالجة المركزية من المشرف ويعتقدون أنه تم تقديمه بواسطة التصحيح الخاص بك في رقم 129. تم العثور على حالة أخرى من الاستخدام العالي لوحدة المعالجة المركزية في الرقم 589 وتأكد أن سببها التصحيح. هل يمكنك النظر في هذا من فضلك؟ توجد تعليمات إعادة الإنتاج أعلاه في https://github.com/Supervisor/supervisor/issues/807#issuecomment -269161194.

أريد أن أضيف أنه من بين 76 خادمًا لديّ مشرفًا يديرها ، كان علي إيقاف / بدء تشغيل المشرف على سبعة منهم في الأيام الأربعة الماضية بسبب هذا الخطأ.

الآن الثامنة. مزيد من التفاصيل الآن. أنا أشغل المشرف 3.3.0. لقد قمت بتثبيته في مايو الماضي بمجرد ظهوره لأنه يحتوي على التصحيح الخاص بي الذي أردته حقًا. لقد أعدت تشغيل المشرف على جميع المضيفين للحصول على الإصدار الجديد وكان يسير على ما يرام. في الأسبوع الماضي ، قمت بتغيير التكوين العام. لقد غيرت minfds إلى 100000 (لأن عملية معينة أرادت ذلك) وقمت بتعيين childlogdir الذي لم يتم تعيينه من قبل. لقد قمت بتثبيت هذا التكوين الجديد على جميع مضيفي وقمت بإعادة تشغيل المشرف. الآن يذهب المضيفون إلى حلقة الدوران هذه بشكل عشوائي. هذا هو سجل الدعامة. هذه تدور كالمجانين ، وتستهلك وحدة معالجة مركزية كاملة.

poll([{fd=4, events=POLLIN|POLLPRI|POLLHUP}, {fd=8, events=POLLIN|POLLPRI|POLLHUP}, {fd=10, events=POLLIN|POLLPRI|POLLHUP}, {fd=11, events=POLLIN|POLLPRI|POLLHUP}, {fd=15, events=POLLIN|POLLPRI|POLLHUP}, {fd=16, events=POLLIN|POLLPRI|POLLHUP}, {fd=20, events=POLLIN|POLLPRI|POLLHUP}, {fd=21, events=POLLIN|POLLPRI|POLLHUP}, {fd=22, events=POLLIN|POLLPRI|POLLHUP}, {fd=25, events=POLLIN|POLLPRI|POLLHUP}, {fd=26, events=POLLIN|POLLPRI|POLLHUP}, {fd=30, events=POLLIN|POLLPRI|POLLHUP}, {fd=31, events=POLLIN|POLLPRI|POLLHUP}, {fd=35, events=POLLIN|POLLPRI|POLLHUP}, {fd=36, events=POLLIN|POLLPRI|POLLHUP}, {fd=40, events=POLLIN|POLLPRI|POLLHUP}, {fd=41, events=POLLIN|POLLPRI|POLLHUP}, {fd=45, events=POLLIN|POLLPRI|POLLHUP}], 18, 1000) = 1 ([{fd=20, revents=POLLIN}])
gettimeofday({1492359703, 190995}, NULL) = 0
gettimeofday({1492359703, 191062}, NULL) = 0
gettimeofday({1492359703, 194873}, NULL) = 0
gettimeofday({1492359703, 194973}, NULL) = 0
gettimeofday({1492359703, 195072}, NULL) = 0
gettimeofday({1492359703, 195108}, NULL) = 0
gettimeofday({1492359703, 195153}, NULL) = 0
gettimeofday({1492359703, 195224}, NULL) = 0
gettimeofday({1492359703, 195254}, NULL) = 0
gettimeofday({1492359703, 195299}, NULL) = 0
gettimeofday({1492359703, 195327}, NULL) = 0
gettimeofday({1492359703, 195378}, NULL) = 0
gettimeofday({1492359703, 195446}, NULL) = 0
wait4(-1, 0x7ffea7758d04, WNOHANG, NULL) = 0
gettimeofday({1492359703, 195526}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLHUP}, {fd=8, events=POLLIN|POLLPRI|POLLHUP}, {fd=10, events=POLLIN|POLLPRI|POLLHUP}, {fd=11, events=POLLIN|POLLPRI|POLLHUP}, {fd=15, events=POLLIN|POLLPRI|POLLHUP}, {fd=16, events=POLLIN|POLLPRI|POLLHUP}, {fd=20, events=POLLIN|POLLPRI|POLLHUP}, {fd=21, events=POLLIN|POLLPRI|POLLHUP}, {fd=22, events=POLLIN|POLLPRI|POLLHUP}, {fd=25, events=POLLIN|POLLPRI|POLLHUP}, {fd=26, events=POLLIN|POLLPRI|POLLHUP}, {fd=30, events=POLLIN|POLLPRI|POLLHUP}, {fd=31, events=POLLIN|POLLPRI|POLLHUP}, {fd=35, events=POLLIN|POLLPRI|POLLHUP}, {fd=36, events=POLLIN|POLLPRI|POLLHUP}, {fd=40, events=POLLIN|POLLPRI|POLLHUP}, {fd=41, events=POLLIN|POLLPRI|POLLHUP}, {fd=45, events=POLLIN|POLLPRI|POLLHUP}], 18, 1000) = 1 ([{fd=20, revents=POLLIN}])
gettimeofday({1492359703, 195874}, NULL) = 0
gettimeofday({1492359703, 195936}, NULL) = 0
gettimeofday({1492359703, 196000}, NULL) = 0
gettimeofday({1492359703, 196092}, NULL) = 0
gettimeofday({1492359703, 196166}, NULL) = 0
gettimeofday({1492359703, 196256}, NULL) = 0
gettimeofday({1492359703, 196336}, NULL) = 0
gettimeofday({1492359703, 196380}, NULL) = 0
gettimeofday({1492359703, 196520}, NULL) = 0
gettimeofday({1492359703, 196557}, NULL) = 0
gettimeofday({1492359703, 196599}, NULL) = 0
gettimeofday({1492359703, 196643}, NULL) = 0
gettimeofday({1492359703, 196689}, NULL) = 0
wait4(-1, 0x7ffea7758d04, WNOHANG, NULL) = 0
gettimeofday({1492359703, 196787}, NULL) = 0

على المضيف على وجه الخصوص الذي يتعطل الآن ، هذه هي fds:

total 0
lr-x------ 1 root root 64 Apr 11 15:42 0 -> /dev/null
lrwx------ 1 root root 64 Apr 11 15:42 1 -> socket:[74731265]
lr-x------ 1 root root 64 Apr 11 15:42 10 -> pipe:[74731311]
lr-x------ 1 root root 64 Apr 11 15:42 11 -> pipe:[74731313]
l-wx------ 1 root root 64 Apr 11 15:42 12 -> /data/logs/supervisor/supermon.log
l-wx------ 1 root root 64 Apr 11 15:42 14 -> pipe:[77877459]
lr-x------ 1 root root 64 Apr 11 15:42 15 -> pipe:[74731314]
lr-x------ 1 root root 64 Apr 11 15:42 16 -> pipe:[77877460]
l-wx------ 1 root root 64 Apr 11 15:42 17 -> /data/logs/supervisor/supercron.log
l-wx------ 1 root root 64 Apr 11 15:42 18 -> /data/logs/supervisor/supercron.err
l-wx------ 1 root root 64 Apr 11 15:42 19 -> pipe:[74731318]
lrwx------ 1 root root 64 Apr 11 15:42 2 -> socket:[74731265]
l-wx------ 1 root root 64 Apr 11 15:42 20 -> /data/logs/supervisor/dart-agent.err
lr-x------ 1 root root 64 Apr 11 15:42 21 -> pipe:[74731319]
lr-x------ 1 root root 64 Apr 11 15:42 22 -> pipe:[77877461]
l-wx------ 1 root root 64 Apr 11 15:42 24 -> pipe:[74731321]
lr-x------ 1 root root 64 Apr 11 15:42 25 -> pipe:[74731320]
lr-x------ 1 root root 64 Apr 11 15:42 26 -> pipe:[74731322]
l-wx------ 1 root root 64 Apr 11 15:42 27 -> /data/logs/supervisor/statsd.log
l-wx------ 1 root root 64 Apr 11 15:42 28 -> /data/logs/supervisor/statsd.err
l-wx------ 1 root root 64 Apr 16 09:27 29 -> pipe:[74731324]
l-wx------ 1 root root 64 Apr 11 15:42 3 -> /data/logs/supervisord.log
lr-x------ 1 root root 64 Apr 16 09:27 30 -> pipe:[74731323]
lr-x------ 1 root root 64 Apr 16 09:27 31 -> pipe:[74731325]
l-wx------ 1 root root 64 Apr 16 09:27 32 -> /data/logs/supervisor/redis.log
l-wx------ 1 root root 64 Apr 16 09:27 33 -> /data/logs/supervisor/redis.err
l-wx------ 1 root root 64 Apr 16 09:27 34 -> pipe:[74731327]
lr-x------ 1 root root 64 Apr 16 09:27 35 -> pipe:[74731326]
lr-x------ 1 root root 64 Apr 16 09:27 36 -> pipe:[74731328]
l-wx------ 1 root root 64 Apr 11 15:42 37 -> /data/logs/supervisor/dmca-admin-web.log
l-wx------ 1 root root 64 Apr 11 15:42 38 -> /data/logs/supervisor/dmca-admin-web.err
l-wx------ 1 root root 64 Apr 16 09:27 39 -> pipe:[74731330]
lrwx------ 1 root root 64 Apr 11 15:42 4 -> socket:[74731287]
lr-x------ 1 root root 64 Apr 16 09:27 40 -> pipe:[74731329]
lr-x------ 1 root root 64 Apr 11 15:42 41 -> pipe:[74731331]
l-wx------ 1 root root 64 Apr 11 15:42 42 -> /data/logs/supervisor/pgcheck.log
l-wx------ 1 root root 64 Apr 11 15:42 43 -> /data/logs/supervisor/pgcheck.err
l-wx------ 1 root root 64 Apr 11 15:42 44 -> /data/logs/supervisor/dart-agent.log
lr-x------ 1 root root 64 Apr 11 15:42 45 -> pipe:[74731332]
l-wx------ 1 root root 64 Apr 11 15:42 47 -> /data/logs/supervisor/pgwatch.log
l-wx------ 1 root root 64 Apr 11 15:42 48 -> /data/logs/supervisor/pgwatch.err
l-wx------ 1 root root 64 Apr 11 15:42 5 -> /data/logs/supervisor/supermon.err
l-wx------ 1 root root 64 Apr 11 15:42 6 -> pipe:[74731309]
lr-x------ 1 root root 64 Apr 11 15:42 7 -> /dev/urandom
lr-x------ 1 root root 64 Apr 11 15:42 8 -> pipe:[74731310]
l-wx------ 1 root root 64 Apr 11 15:42 9 -> pipe:[74731312]

plockaby نحن

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

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

poll([{fd=4, events=POLLIN|POLLPRI|POLLHUP}, {fd=5, events=POLLIN|POLLPRI|POLLHUP}, {fd=8, events=POLLIN|POLLPRI|POLLHUP}, {fd=10, events=POLLIN|POLLPRI|POLLHUP}, {fd=11, events=POLLIN|POLLPRI|POLLHUP}, {fd=15, events=POLLIN|POLLPRI|POLLHUP}, {fd=16, events=POLLIN|POLLPRI|POLLHUP}, {fd=20, events=POLLIN|POLLPRI|POLLHUP}, {fd=21, events=POLLIN|POLLPRI|POLLHUP}, {fd=25, events=POLLIN|POLLPRI|POLLHUP}, {fd=26, events=POLLIN|POLLPRI|POLLHUP}, {fd=30, events=POLLIN|POLLPRI|POLLHUP}], 12, 1000) = 1 ([{fd=5, revents=POLLIN}])
gettimeofday({1492367896, 593446}, NULL) = 0
gettimeofday({1492367896, 593515}, NULL) = 0
gettimeofday({1492367896, 593584}, NULL) = 0
gettimeofday({1492367896, 593637}, NULL) = 0
gettimeofday({1492367896, 593719}, NULL) = 0
gettimeofday({1492367896, 593788}, NULL) = 0
gettimeofday({1492367896, 593826}, NULL) = 0
gettimeofday({1492367896, 593863}, NULL) = 0
gettimeofday({1492367896, 593886}, NULL) = 0
gettimeofday({1492367896, 593906}, NULL) = 0
gettimeofday({1492367896, 593948}, NULL) = 0
gettimeofday({1492367896, 593987}, NULL) = 0
gettimeofday({1492367896, 594031}, NULL) = 0
wait4(-1, 0x7ffe0f36f7e4, WNOHANG, NULL) = 0
gettimeofday({1492367896, 594103}, NULL) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLHUP}, {fd=5, events=POLLIN|POLLPRI|POLLHUP}, {fd=8, events=POLLIN|POLLPRI|POLLHUP}, {fd=10, events=POLLIN|POLLPRI|POLLHUP}, {fd=11, events=POLLIN|POLLPRI|POLLHUP}, {fd=15, events=POLLIN|POLLPRI|POLLHUP}, {fd=16, events=POLLIN|POLLPRI|POLLHUP}, {fd=20, events=POLLIN|POLLPRI|POLLHUP}, {fd=21, events=POLLIN|POLLPRI|POLLHUP}, {fd=25, events=POLLIN|POLLPRI|POLLHUP}, {fd=26, events=POLLIN|POLLPRI|POLLHUP}, {fd=30, events=POLLIN|POLLPRI|POLLHUP}], 12, 1000) = 1 ([{fd=5, revents=POLLIN}])
gettimeofday({1492367896, 594331}, NULL) = 0
gettimeofday({1492367896, 594415}, NULL) = 0
gettimeofday({1492367896, 594491}, NULL) = 0
gettimeofday({1492367896, 594561}, NULL) = 0
gettimeofday({1492367896, 594642}, NULL) = 0
gettimeofday({1492367896, 594663}, NULL) = 0
gettimeofday({1492367896, 594699}, NULL) = 0
gettimeofday({1492367896, 594739}, NULL) = 0
gettimeofday({1492367896, 594769}, NULL) = 0
gettimeofday({1492367896, 594808}, NULL) = 0
gettimeofday({1492367896, 594836}, NULL) = 0
gettimeofday({1492367896, 594887}, NULL) = 0
gettimeofday({1492367896, 594934}, NULL) = 0
wait4(-1, 0x7ffe0f36f7e4, WNOHANG, NULL) = 0
gettimeofday({1492367896, 595005}, NULL) = 0

lr-x------ 1 root root 64 Apr 16 10:37 0 -> /dev/null
lrwx------ 1 root root 64 Apr 16 10:37 1 -> socket:[36606016]
lr-x------ 1 root root 64 Apr 16 10:37 10 -> pipe:[36606043]
lr-x------ 1 root root 64 Apr 16 10:37 11 -> pipe:[36606045]
l-wx------ 1 root root 64 Apr 16 10:37 12 -> /data/logs/supervisor/supermon.log
l-wx------ 1 root root 64 Apr 16 10:37 13 -> /data/logs/supervisor/supermon.err
l-wx------ 1 root root 64 Apr 16 10:37 14 -> pipe:[36606047]
lr-x------ 1 root root 64 Apr 16 10:37 15 -> pipe:[36606046]
lr-x------ 1 root root 64 Apr 16 10:37 16 -> pipe:[36606048]
l-wx------ 1 root root 64 Apr 16 10:37 17 -> /data/logs/supervisor/supercron.log
l-wx------ 1 root root 64 Apr 16 10:37 18 -> /data/logs/supervisor/supercron.err
l-wx------ 1 root root 64 Apr 16 10:37 19 -> pipe:[36606050]
lrwx------ 1 root root 64 Apr 16 10:37 2 -> socket:[36606016]
lr-x------ 1 root root 64 Apr 16 10:37 20 -> pipe:[36606049]
lr-x------ 1 root root 64 Apr 16 10:37 21 -> pipe:[36606051]
l-wx------ 1 root root 64 Apr 16 10:37 22 -> /data/logs/supervisor/dart-agent.log
l-wx------ 1 root root 64 Apr 16 10:37 24 -> pipe:[36606053]
lr-x------ 1 root root 64 Apr 16 10:37 25 -> pipe:[36606052]
lr-x------ 1 root root 64 Apr 16 10:37 26 -> pipe:[36606054]
l-wx------ 1 root root 64 Apr 16 10:37 27 -> /data/logs/supervisor/pgcheck.log
l-wx------ 1 root root 64 Apr 16 10:37 28 -> /data/logs/supervisor/pgcheck.err
l-wx------ 1 root root 64 Apr 16 10:37 3 -> /data/logs/supervisord.log
lr-x------ 1 root root 64 Apr 16 10:37 30 -> pipe:[36606055]
l-wx------ 1 root root 64 Apr 16 10:37 32 -> /data/logs/supervisor/pgwatch.log
l-wx------ 1 root root 64 Apr 16 10:37 33 -> /data/logs/supervisor/pgwatch.err
lrwx------ 1 root root 64 Apr 16 10:37 4 -> socket:[36606038]
l-wx------ 1 root root 64 Apr 16 10:37 5 -> /data/logs/supervisor/dart-agent.err
l-wx------ 1 root root 64 Apr 16 10:37 6 -> pipe:[36606041]
lr-x------ 1 root root 64 Apr 16 10:37 7 -> /dev/urandom
lr-x------ 1 root root 64 Apr 16 10:37 8 -> pipe:[36606042]
l-wx------ 1 root root 64 Apr 16 10:37 9 -> pipe:[36606044]

plockaby لقد نشرت هذا في # 875. هل يمكنك العمل معنا هناك للتكاثر؟

يقدر على. سأنتقل إلى التعليق هناك بدلاً من ذلك.

أكره أن أعزف على هذا ولكن # 875 لم يحل مشكلتي وما زلت أعيد تشغيل المشرف كل بضعة أيام على مضيفين عشوائيين. أردت فقط أن أفهم أن هذا ما زال يحدث.

plockaby ، أقترح أن تحاول استخدام systemd بدلاً من supervisor !

أكره أن أعزف على هذا ولكن # 875 لم يحل مشكلتي وما زلت أعيد تشغيل المشرف كل بضعة أيام على مضيفين عشوائيين.

plockaby لقد تمكنت من إعادة إنتاج سبب واحد لوحدة المعالجة المركزية المرتفعة ولاحظت أن # 875 قد

تم إصدار المشرف 3.3.2 إلى PyPI ويتضمن إصلاحات المستفيد (# 875 ، # 885).

تم إصلاح مشكلة CPU العالية الوحيدة التي تمكنت من إعادة إنتاجها من خلال هذا الإصدار.

إذا كنت تواجه مشكلة كبيرة في وحدة المعالجة المركزية في Supervisor 3.3.2 ، فيرجى فتح مشكلة جديدة وتضمين التعليمات لإعادة إنتاجها.

لقد كنت في إجازة لذا سأصل إلى هذا الآن.

لقد جربت 3.3.2 ولم تحل ارتفاعات وحدة المعالجة المركزية. لقد قمت بالفعل بإعادة جميع مضيفي إلى 3.2.3 على افتراض أنها كانت مشكلة في رمز الاقتراع الجديد. ما زلت أعاني من دخول مشرف في حلقات الاقتراع التي تستخدم وحدة المعالجة المركزية بنسبة 100٪.

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

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

هل تمانع إذا واصلت نشر معلومات حول وقت مواجهة المشكلة؟

بالطبع لا. من فضلك افعل هذا.

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

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

لقد لاحظت أيضًا أنه لا يحدث على مضيفي Centos7. لم يحدث ذلك حتى الآن إلا مع مضيفي Centos6. لسوء الحظ ، لا يزال معظم مضيفي على Centos6. :)

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

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

كنت سأكتب وصفًا طويلًا كبيرًا مع اقتباسات من دعامي ولكني أعتقد أنني اكتشفت المشكلة. تحدث المشكلة عندما يتم تدوير سجل مستمع الحدث الخاص بي. نظرًا لأنه مستمع للأحداث ولا يهمني حقًا stdout لمستمعي الأحداث ، فإن التكوين الخاص بي مثل هذا:

stdout_logfile = /data/logs/supervisor/dart-agent.log
stdout_logfile_maxbytes = 1MB
stdout_logfile_backups = 0

عندما تقول الدعامة أن برنامجي بدأ بالجنون ، يظهر هذا في الدعامة:

open("/data/logs/supervisor/dart-agent.log", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0

هذا هو ملف السجل الخاص بمستمع الأحداث و "5" هو واصف الملف لملف السجل الذي أقوم بتدويره حاليًا عند الاقتراع:

poll([{fd=4, events=POLLIN|POLLPRI|POLLHUP}, {fd=5, events=POLLIN|POLLPRI|POLLHUP}, {fd=8, events=POLLIN|POLLPRI|POLLHUP}, {fd=11, events=POLLIN|POLLPRI|POLLHUP}, {fd=12, events=POLLIN|POLLPRI|POLLHUP}, {fd=15, events=POLLIN|POLLPRI|POLLHUP}, {fd=16, events=POLLIN|POLLPRI|POLLHUP}, {fd=20, events=POLLIN|POLLPRI|POLLHUP}, {fd=21, events=POLLIN|POLLPRI|POLLHUP}, {fd=25, events=POLLIN|POLLPRI|POLLHUP}, {fd=26, events=POLLIN|POLLPRI|POLLHUP}, {fd=30, events=POLLIN|POLLPRI|POLLHUP}, {fd=31, events=POLLIN|POLLPRI|POLLHUP}, {fd=35, events=POLLIN|POLLPRI|POLLHUP}], 14, 1000) = 1 ([{fd=5, revents=POLLIN}])
gettimeofday({1498848417, 352015}, NULL) = 0
gettimeofday({1498848417, 352079}, NULL) = 0
gettimeofday({1498848417, 352141}, NULL) = 0
gettimeofday({1498848417, 352204}, NULL) = 0
gettimeofday({1498848417, 352268}, NULL) = 0
gettimeofday({1498848417, 352331}, NULL) = 0
gettimeofday({1498848417, 352483}, NULL) = 0
gettimeofday({1498848417, 352590}, NULL) = 0
gettimeofday({1498848417, 352769}, NULL) = 0
gettimeofday({1498848417, 352858}, NULL) = 0
wait4(-1, 0x7fff3600b334, WNOHANG, NULL) = 0
gettimeofday({1498848417, 352992}, NULL) = 0

آمل أن يكون هذا كافيا للاستمرار؟

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

لقد حذفت ذات مرة بعض ملفات السجل وعلقت وحدة المعالجة المركزية بنسبة 100٪. هل هي ذات صلة؟

حصلت على نفس المشكلة أيضًا في Centos7 مع 3.3.1
هل تم التأكيد على أن 3.3.2 يمكنها حل هذه المشكلة？

FWIW أردت تقديم تحديث. هذا لا يزال يمثل مشكلة. إنه خاص بمستمعي الأحداث ويحدث في 3.2 و 3.3. (لم أختبر 3.1 أو على المستوى الرئيسي.) المشكلة المحددة تتعلق بوقت تدوير ملف سجل stdout. لقد عملت على حلها من خلال تعطيل ملف سجل stdout تمامًا عن طريق كتابة stdout_logfile = NONE في تكوين مستمع الحدث الخاص بي. نظرًا لأن المستمعين في الحدث غير مفيد في الغالب ، لم تكن هذه خسارة كبيرة. بالإضافة إلى ذلك ، لقد حلت مشكلتي تمامًا لذا ها أنت ذا.

FWIW يمكنني أن أؤكد أنني واجهت نفس المشكلة تقريبًا كما وصفهاplockaby

• عدد كبير من الخوادم السحابية التي تعمل بنظام Ubuntu 16.04 والمشرف-> Python
• تنتقل الأجهزة المختلفة بشكل عشوائي إلى وحدة المعالجة المركزية بنسبة 100٪ ، وتؤدي إعادة التشغيل إلى إصلاحها
• يؤدي تعيين stdout_logfile = NONE اختفاء المشكلة
• أعتقد أيضًا أن هذا مرتبط بالتناوب stdout_logfile

الحل الذي جعلني أقوم بإعداد stdout_logfile = NONE لا يحل المشكلة تمامًا. الآن يدور بنسبة 100٪ إلى POLLIN ملف سجل stderr عند الدوران. لا أحتاج إلى إعادة تشغيل المضيف ، رغم ذلك. أقوم فقط بإعادة تشغيل مستمع الحدث وتختفي المشكلة حتى يتم تدوير السجل في المرة التالية. أفترض أنني لم أتمكن من الاحتفاظ بأي سجلات من مستمعي الحدث الخاص بي؟

أعتقد أن سبب الألغام هو redirect stderr
في صندوق واحد ~ 120 وظيفة يشاهدها المشرف. وكان استخدام وحدة المعالجة المركزية للمشرف حوالي 99٪

# supervisorctl version
3.3.4

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:    14.04
Codename:   trusty



md5-d13ddf88929d7befef385bd07ead4a5e



find /etc/supervisor/conf.d -name "*.conf" -exec sh -c 'echo "redirect_stderr=true" >> "$0" ' {} \;

انخفض الآن إلى أقل من 2٪

مرحبا! كانت لدي تجربة مماثلة مع المشرف 3.3.4

lsb_release -a
لا توجد وحدات LSB متوفرة.
معرف الموزع: أوبونتو
الوصف: Ubuntu 16.04.4 LTS
الإصدار: 16.04.2007
الاسم الرمزي: زينيل

strace -p

يعرض عشرات الرسائل في الثانية كما يلي:

استطلاع ([{fd = 4، events = POLLIN | POLLPRI | POLLHUP}، {fd = 5، events = POLLIN | POLLPRI | POLLHUP}، {fd = 9، events = POLLIN | POLLPRI | POLLHUP}، {fd = 11، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 12 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 18 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 19 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 21 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 28 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 32 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 38 ، الأحداث = POLLPRI | POLLPRI | POLLHUP} ، {fd = 39 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 40 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 47 ، الأحداث = POLLIN | POLLPRI | POLLHUP} ، { fd = 54 ، أحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 55 ، أحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 61 ، أحداث = POLLIN | POLLPRI | POLLHUP} ، {fd = 65 ، أحداث = POLLIN | POLLPRI | POLLHUP}] ، 18 ، 1000) = 0 (المهلة)

تم تشغيل المشرف لمدة 1.5 شهر تقريبًا ويقوم بإدارة 10 عمليات.

وضع المشرف ctl جميع

يعرض نفس معرفات العملية (لا توجد عملية يتم إعادة تشغيلها باستمرار ، إلخ).

بعد قراءة التعليقات أعلاه ، قررت إجراء تجربة صغيرة. لذلك بدأت بإيقاف إدارة مشرف الخدمات واحدًا تلو الآخر ، من خلال واجهة الويب.

لذا من بين العمليات المخصصة التي أقوم بتشغيلها ، لديّ crashmailbatch و fatalmailbatch من حزمة superlance.

لذلك كنت أشاهد نفس التواتر لاستطلاعات الرأي حتى أوقفت fatalmailbatch.

يحتوي Fatalmailbatch على التكوين التالي:

[حتى tlistener: fatalmailbatch ]
الأمر = fatalmailbatch --toEmail =--من البريد الإلكتروني =- smtpHost =--userName = ... - كلمة المرور = ... --subject = "تنبيه - MYDOMAIN تعطل العمليات!" - الفاصل الزمني = 5.0
الأحداث = PROCESS_STATE ، TICK_60
تشغيل تلقائي = صحيح
autorestart = صحيح

كانت العملية مستمرة طالما كان المشرف يعمل دون توقف.

آمل أن يساعد بطريقة ما.

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

إذا كان بإمكان المشرف أن يعطيني بعض المؤشرات حول كيفية المساعدة في الحصول على هذا العنوان ، فسأكون ممتنًا.

أنا أحد الأشخاص الذين لديهم حق الوصول إلى هذا المستودع ، لكنني لم أشارك في أي من الكود المعني. أنا لست مألوفًا جدًا بهذا الرمز المعين. يبدو أن المشكلة قد تم تقديمها بواسطة # 129 ، والتي كتبها igorsobreira ودمجت بواسطةmcdonc. حاولت الاتصال بـ igorsobreira بعد الإبلاغ عن مشاكل لكنه لم يرد. قام مساهم آخر ، jaredsuttles ، ببذل بعض الجهد في مشكلة CPU العالية وقدم # 875 ، الذي قمت بدمجه. أقدر كل متابعاتك ،

في حالتي ، بدأ الأمر يحدث قبل أيام قليلة. الآن يتعين علي إعادة تشغيل المشرف مرة واحدة كل يوم وإلا فسيحدث ذلك ارتفاعات غير عادية. أنا أستخدم المشرف 3.2.0 وما زالت المشكلة قائمة. بأي طريقة يمكننا حل هذه المشكلة بشكل دائم؟ لم أقم بتثبيته من مستودع git.

@ p01ymath : لقد كان هذا الخطأ خادعًا لأننا لا نعرف كيفية إعادة إنتاجه ، ولكن يبدو أنك

تقوم بعض أنواع العمليات الفرعية بأشياء غير عادية مثل إغلاق واصف ملف stdout. يمكن أن تؤثر السلوكيات غير العادية على عمل المشرف وتكشف عن المشكلات.

لقد واجهت ذلك مرتين حتى الآن ويحدث ذلك في أوقات عشوائية. أقوم بتشغيل عمال طابور Laravel باستخدام المشرف. في المرة الأولى التي واجهت فيها هذه المشكلة ، أوقفت التسجيل تمامًا وأعدت تشغيل المشرف. لقد نجحت لذلك اعتقدت أنها كانت مسألة قطع الأشجار.

بعد 2-3 أيام ، حدث ذلك مرة أخرى. وهذه المرة تم إيقاف تشغيل السجلات بالفعل. لذلك لم أعد تشغيل المشرف مباشرة. من htop ، اكتشفت العامل الذي كان يستخدم غالبية وحدة المعالجة المركزية الخاصة بي. لذلك ، قمت للتو بإيقاف هذه العملية الفردية. ومع ذلك ، كان استخدام وحدة المعالجة المركزية (CPU) الخاص بي 100٪ ، لذا قمت بفحص htop مرة أخرى واكتشفت أن العامل / العملية الأخرى في نفس البرنامج بدأت باستخدام 100٪ من وحدة المعالجة المركزية. ثم قمت بإيقاف تشغيل مجموعة العملية بأكملها واكتشفت أن العامل الآخر في مجموعة العمليات الأخرى بدأ في استخدام كل وحدة المعالجة المركزية.

ثم أعدت تشغيل المشرف وعمل. حدث هذا منذ حوالي 3 أيام ولكني لم أواجه أي مشكلة منذ ذلك الحين. أنا أستخدم المشرف 3.2.0 ولدي 5 برامج مع 12 عامل طابور.

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

هناك أداة جديدة متاحة تسمى py-spy وأعتقد أنها ستساعد بشكل كبير أي شخص يعاني من استخدام CPU عالي في Supervisor أو أي عملية Python أخرى. إذا كنت تستخدم Virtualenv ، فقم بتثبيته باستخدام "bin / pip install py-spy" وتشغيله باستخدام sudo bin / py-spy --pid PID حيث يكون PID هو PID لعملية المشرف. سيُظهر انهيارًا يشبه "الجزء العلوي" لما تقوم به العملية. استخدم ctrl-S لإيقاف الإخراج مؤقتًا (للنسخ / اللصق) و ctrl-Q للاستئناف.

أواجه أيضًا عبء استخدام وحدة المعالجة المركزية بنسبة 100٪ عندما تأخذ العمليات الخاضعة للإشراف وحدة المعالجة المركزية بنسبة 100٪ أيضًا. إليك (أعلى) ناتج Py-Spy:

 50.50%  50.50%    3.14s     3.14s   select (dist-packages/supervisor/options.py:1156)
  4.50%   9.50%   0.185s    0.355s   get_process_map (dist-packages/supervisor/supervisord.py:138)
  4.00%   5.00%   0.250s    0.305s   runforever (dist-packages/supervisor/supervisord.py:212)
  3.50%  11.00%   0.335s    0.655s   runforever (dist-packages/supervisor/supervisord.py:192)
  3.00%   3.00%   0.150s    0.150s   get_dispatchers (dist-packages/supervisor/process.py:691)
  3.00%   4.00%   0.225s    0.255s   runforever (dist-packages/supervisor/supervisord.py:214)
  3.00%   3.00%   0.140s    0.140s   get_dispatchers (dist-packages/supervisor/process.py:692)
  2.50%   3.00%   0.080s    0.105s   runforever (dist-packages/supervisor/supervisord.py:211)
  1.50%   1.50%   0.035s    0.035s   transition (dist-packages/supervisor/process.py:522)

يأخذ المشرف وحدة معالجة مركزية ثابتة بنسبة 80 ~ 100٪ على مضيفي ، وهو يدير حوالي 30 عملية NodeJS ، على جهاز 32 نواة.

(أنا أستخدم V3.3.4)

أي فكرة عما يأتي أو ما إذا كان متوقعًا؟

لقد قمت مؤخرًا بنشر v3.3.4 عبر 6 خوادم تعمل بنظام Ubuntu 18.04. يشرف كل خادم على أقل من 5 عمليات وما يصل إلى أكثر من 70 عملية.

بعد حوالي بضعة أيام ، أظهرت جميع الخوادم تقريبًا مشكلات عالية في استخدام وحدة المعالجة المركزية. لا تساعد إعادة التشغيل / إعادة التشغيل ، حيث تتكرر المشكلة على الفور. لا يزال الخادم الذي يحتوي على 5 عمليات فرعية خاضعة للإشراف يواجه وحدة معالجة مركزية بنسبة 100٪ ؛ نفسه مع 70 عملية الخادم.

لقد خفضت مستوى كل هذه الخوادم إلى v3.1.0 واختفت المشكلة!
في الوقت الحالي ، مر أسبوعان دون أي مشاكل على الإطلاق.

أظن أن المشكلة تتعلق بمعالجة stdout / stderr للعمليات الخاضعة للإشراف ؛ نظرًا لأن استخدام وحدة المعالجة المركزية ينخفض ​​إذا قمت بتعطيل / تقليل إخراج stdout / stderr.

أقرأ الكثير من التعليقات بخصوص: تنفيذ الاختيار / الاستطلاع وأقول أن هذا يسير على الطريق الصحيح.

اشتعلت إحدى مثيلات المشرف الخاصة بي وهي تقوم بأمر POLL باستخدام 100٪ لوحدة المعالجة المركزية.
كانت سجلات العمليات فارغة - لم يتم تسجيل أي عملية في ذلك الوقت.
في المواجهات السابقة مع هذا الخطأ ، حاولت دون جدوى ما يلي:

• تعطيل التسجيل
• تشغيل عمليات أقل
• تشغيل عمليات تتطلب وحدة المعالجة المركزية أقل
• إعادة تشغيل عملية واحدة أو أكثر
• إعادة تشغيل الإضافات superlance

هذه المرة عندما اكتشفت أن هناك ارتفاعًا في وحدة المعالجة المركزية (CPU) ، بدأت في التثبيت وفتحت للتو

توقف الاستقصاء المستمر وأصبح استخدام وحدة المعالجة المركزية طبيعيًا مرة أخرى.

هذا ليس دليلاً بالطبع لكنه جعلني أفكر.

أدلة عظيمة يا رفاق. اجعلهم يأتون إذا استطعت.

لدي 3 خوادم بمواصفات متطابقة تعمل بأعداد مختلفة لنفس قائمة العمليات.

لنفترض أن الخوادم هي s1 و s2 و s3 ،
يتم عرض العمليات A و B و C و D و E وعدد العمليات الجارية في الجدول التالي

| | أ | ب | ج | د |
| --- | --- | --- | --- | --- |
| s1 | 5 | 2 | 1 | 4 |
| s2 | 2 | 2 | 4 | 4 |
| s3 | 3 | 3 | 3 | 3 |

تم تعطيل تسجيل المشرف (يقوم بتسجيل الدخول إلى ملفات السجل المنفصلة الخاصة بهم) في جميع العمليات.
تحتوي جميع الخوادم على نفس الحزم والتحديثات (ubuntu 16.04).
تستخدم جميع العمليات نفس إصدار بايثون.

لم يواجه الخادم s1 أي مشاكل مع الاستخدام العالي لوحدة المعالجة المركزية من المشرف.
تواجه الخوادم s2 و s3 مشكلة الاستخدام العالي لوحدة المعالجة المركزية بسبب الاستقصاء المستمر (كما هو موضح بواسطة strace -p pid_of_supervisord).
عادةً ما أقوم بإعادة تشغيل العمليات واحدة تلو الأخرى أثناء فحص الاستقامة حتى النقطة التي يظهر فيها strace أن الاستقصاء المستمر يتوقف. في بعض الأحيان ، تؤدي العملية الأولى التي يتم إعادة تشغيلها إلى حل المشكلة. في بعض الأحيان يتم إعادة تشغيل العمليات بعد 4-5.
ليست دائمًا نفس العملية التي توقف الاقتراع من خلال إعادة التشغيل.
إنه ليس دائمًا نفس الوقت الذي كانت فيه العملية تعمل حتى النقطة التي تؤدي فيها إعادة تشغيلها إلى إيقاف الاقتراع.
أخيرًا وليس آخرًا ، لا تشترك العمليات في أي شيء فيما يتعلق بما تفعله ، والمكتبات غير المضمنة التي تستخدمها وما إلى ذلك. الشيء الشائع الوحيد بينها هو أنها كُتبت جميعها في python3 وتعمل تحت python 3.5.x.

تتم عمليات إعادة التشغيل التي أذكرها من خلال واجهة مستخدم الويب.

تؤثر علينا على الإشراف 3.3.5

(gdb) py-bt
Traceback (أحدث مكالمة أولاً):
ملف "/usr/lib/python2.7/site-packages/supervisor/poller.py" ، السطر 91 ، في register_readable
self._poller.register (fd ، self. read)
ملف "/usr/lib/python2.7/site-packages/supervisor/supervisord.py" ، السطر 208 ، قيد التشغيل
self.options.poller.register_readable (fd)
ملف "/usr/lib/python2.7/site-packages/supervisor/supervisord.py" ، السطر 94 ، قيد التشغيل
self.runforever ()
ملف "/usr/lib/python2.7/site-packages/supervisor/supervisord.py" ، السطر 77 ، بشكل رئيسي
self.run ()
ملف "/usr/lib/python2.7/site-packages/supervisor/supervisord.py" ، السطر 371 ، قيد التشغيل
d.main ()

تدور باستمرار تفعل هذا
wait4 (-1 ، 0x7ffc8bb32e94 ، WNOHANG ، NULL) = 0
استطلاع ([تم استبعاد العديد من FDs هنا ...] ، {fd = 114 ، الأحداث = POLLIN | POLLPRI | POLLHUP}] ، 42 ، 1000) = 1 ([{fd = 114 ، revents = POLLIN}])

يعرض البيانات المتاحة للقراءة ، ولكن لا تقرأ في الواقع () ، بدلاً من ذلك على الفور استقصاء () مرة أخرى والتي لا تزال تعرض (نفس) البيانات المتاحة للقراءة.

$ sudo ls -l / proc / 1134 / fd / 114
l-wx ------. 1 جذر الجذر 64 مارس 21 09:53 / proc / 1134 / fd / 114 -> /home/rina-main/server/log/log.watch_rinaenm1

هذا ملف سجل stdout (مع redirect_stderr = true) ، مرتبط بهذه العملية:
alarms_ watchers: watch_rinaenm1 RUNNING pid 32005 ، وقت التشغيل 2:10:49

أنا قادر على تصميمه بشكل جيد ، وإظهار البيانات الحديثة:
TelsaSupervisor> الذيل -44 منبهات_المراقبون : watch_rinaenm1
(2019-03-21 09: 57: 20.992811) 0: 00: 04.332918

لقد "أشرت" إلى أن العملية والمشكلة قد تم حلها في الوقت الحالي.

تحرير: حدث لي للتو: لماذا يتم استقصاء ملف السجل للقراءة ، على أي حال؟

تحرير ، حدث مرة أخرى. هذه المرة ، يتم الحصول على POLLOUT بدلاً من POLLIN ، ولكن لا يزال على ملف سجل stdout ، وآخر FD في مجموعة الاستطلاع. هذه المرة لم تكن العملية قد كتبت أي شيء أبدًا (لكن ملف السجل هو 36 ميغا بايت تقريبًا من أمر سابق كان يكتبه DID).
استطلاع ([... {fd = 62، أحداث = POLLOUT}]، 22، 1000) = 1 ([{fd = 62، revents = POLLOUT}])
l-wx ------. 1 جذر الجذر 64 مارس 24 00:40 / proc / 77842 / fd / 62 -> /home/telsa-inet/server/log/log.eric_eutran

[ pryzbyj @ appserver ~] $ sudo lsof -n -p 77842 | grep 62
المشرف 77842 الجذر 62w REG 253،1 37056758 454849 /home/telsa-inet/server/log/log.eric_eutran

-rw-r - r--. 1 جذر جذر 36M 26 فبراير 13:25 / home/telsa-inet/server/log/log.eric_eutran

هل لك أن تعرف ما الذي يمكننا تقديمه أيضًا للمساعدة في حل سوء السلوك؟

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

أنا قادر على إعادة إنتاج هذا الجزء من المشكلة باستخدام 9 عمليات والإشارة إلى اثنين منها بشكل مختلف: إشارة hup c4 c5. قد يستغرق ذلك بضع محاولات للتشغيل ، ولكن مع إضافة تناسق جيد إلى "r" أو "w" ، قم بإدراج FD سابقًا في socket_map للعميل Supervisorctl (أقوم بالاتصال عبر مقبس unix) ولكن تم استخدامه لاحقًا كملف سجل stdout (ولكن لم يتم إزالته من قائمة FDs التي سيتم استطلاعها).

[البرنامج: c1]
stdout_logfile = تسجيل / تسجيل.٪ (اسم البرنامج) s
redirect_stderr = صحيح
autorestart = صحيح
startretries = 999999999
الأمر = sh -c 'echo ؛ ينام 9 تاريخ'

يمكنني تجنب المشكلة بهذا التغيير:
إذا كان قناع الحدث & (select.POLLNVAL | select.POLLHUP):

سؤال واحد مفتوح في ذهني ، هو ما إذا كان من الممكن أن يحدث فقدان للخريطة المدمجة بشكل مشروع أو إذا كانت المفاتيح المفقودة ناتجة فقط عن أخطاء ويجب بدلاً من ذلك تأكيدها (أو السماح لها بالتعطل).
إذا كان fd في خريطة مجمعة:

igorsobreira ، هل يمكنك التعليق؟

مرحبًا hathawsh أي تحديث من فريقك حول هذه المشكلة؟ واجهت نفس المشكلة: عالق في حلقة الاقتراع عند بدء عمليات فرعية متعددة. لقد حدث ذلك بجانبي بعد الترقية من 3.2.3 إلى أحدث إصدار. يمكن أن يؤدي الحل البديل لتعطيل عملية تسجيل الطفل إلى إعادة استخدام وحدة المعالجة المركزية للمشرف إلى الوضع الطبيعي. ولكن من الأفضل إعطاء الأولوية لهذه المشكلة أو إذا كان قد تم تحديدها بالفعل ، فمن الجيد الحصول على بعض المشاركة حول العملية. شكرا!

BR
روبي

أنا أستخدم المشرف على إصدار Ubuntu 18.04. من وقت لآخر ، أرى أن استخدام وحدة المعالجة المركزية وصل إلى 100٪ و htop يوضح أن هذا هو supervisord الذي يأخذ كل وحدة المعالجة المركزية.

في السابق كان لدي نفس المشكلة مع 3.3.0 واكتشفت أن هناك إصلاحًا في 3.3.2 فيما يتعلق باستخدام وحدة المعالجة المركزية عالية. لذلك قمت بالتحديث إلى 4.2.0 وحصلت اليوم على نفس الشيء على إحدى العقد الخاصة بي.

يظهر strace نفس الشيء الذي ظهر في 3.3.0:

poll([{fd=4, events=POLLIN|POLLPRI|POLLHUP}, {fd=8, events=POLLIN|POLLPRI|POLLHUP}, {fd=9, events=POLLIN|POLLPRI|POLLHUP}, {fd=10, events=POLLIN|POLLPRI|POLLHUP}, {fd=12, events=POLLIN|POLLPRI|POLLHUP}, {fd=15, events=POLLIN|POLLPRI|POLLHUP}, {fd=18, events=POLLIN|POLLPRI|POLLHUP}, {fd=21, events=POLLIN|POLLPRI|POLLHUP}, {fd=24, events=POLLIN|POLLPRI|POLLHUP}, {fd=27, events=POLLIN|POLLPRI|POLLHUP}, {fd=30, events=POLLIN|POLLPRI|POLLHUP}, {fd=33, events=POLLIN|POLLPRI|POLLHUP}, {fd=36, events=POLLIN|POLLPRI|POLLHUP}, {fd=39, events=POLLIN|POLLPRI|POLLHUP}, {fd=42, events=POLLIN|POLLPRI|POLLHUP}, {fd=45, events=POLLIN|POLLPRI|POLLHUP}, {fd=48, events=POLLIN|POLLPRI|POLLHUP}, {fd=51, events=POLLIN|POLLPRI|POLLHUP}, {fd=54, events=POLLIN|POLLPRI|POLLHUP}, {fd=57, events=POLLIN|POLLPRI|POLLHUP}, {fd=60, events=POLLIN|POLLPRI|POLLHUP}, {fd=63, events=POLLIN|POLLPRI|POLLHUP}, {fd=66, events=POLLIN|POLLPRI|POLLHUP}, {fd=69, events=POLLIN|POLLPRI|POLLHUP}, {fd=72, events=POLLIN|POLLPRI|POLLHUP}, {fd=75, events=POLLIN|POLLPRI|POLLHUP}, {fd=78, events=POLLIN|POLLPRI|POLLHUP}, {fd=81, events=POLLIN|POLLPRI|POLLHUP}, {fd=84, events=POLLIN|POLLPRI|POLLHUP}, {fd=87, events=POLLIN|POLLPRI|POLLHUP}, {fd=90, events=POLLIN|POLLPRI|POLLHUP}, {fd=93, events=POLLIN|POLLPRI|POLLHUP}, ...], 46, 1000) = 1 ([{fd=12, revents=POLLIN}])

الإصدار:

supervisord --version
4.2.0

إخراج htop:

تكوين المشرف:

[program:queue-dedicated]
process_name=%(program_name)s_%(process_num)02d
command=php /home/pinger/pinger/artisan queue:work redis-dedicated --queue=toronto --sleep=3 --tries=3
autostart=true
autorestart=true
user=pinger
numprocs=2
redirect_stderr=true
stdout_logfile=/home/pinger/pinger/worker.log
stopwaitsecs=30

[program:queue-local]
process_name=%(program_name)s_%(process_num)02d
command=php /home/pinger/pinger/artisan queue:work redis-local --sleep=3 --tries=3
autostart=true
autorestart=true
user=pinger
numprocs=40
redirect_stderr=true
stdout_logfile=/home/pinger/pinger/worker.log

[program:checks-push]
process_name=%(program_name)s_%(process_num)02d
command=php /home/pinger/pinger/artisan checks:push
autostart=true
autorestart=true
user=pinger
numprocs=1
redirect_stderr=true
stdout_logfile=/home/pinger/pinger/checksPushErrors.log

هل لدى أي شخص نفس الشيء؟ ربما أخطأت في تكوين شيء ما.

أي خطة مع هذه القضية؟