خطأ: '768 worker_connections ليست كافية'

الدعم تثبيت
1

مرحبًا!

منذ إعادة البناء اليوم، نواجه عددًا كبيرًا من أخطاء الخادم. يبدو أن المشكلة تتعلق باتصال nginx؛ ففي ملف nginx/error.log، أرى أحيانًا دفقات من رسائل 768 worker_connections are not enough مثل هذه الرسالة:

2021/06/02 10:42:21 [alert] 1143#1143: *28468 1768 worker_connections are not enough while connecting to upstream, client: (IP removed), server: _, request: "POST /message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/convert-multiple-objects-to-single-mesh-with-vertex-grouping/489173/2"

هل لديكم أي أفكار حول كيفية معالجة هذه المشكلة؟ لدينا موارد كافية من وحدة المعالجة المركزية والذاكرة - هل يمكننا زيادة عدد ‘worker connections’؟

2

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

## أي أوامر مخصصة للتشغيل بعد البناء
run:
  - exec: echo "Beginning of custom commands"

  - replace:
      filename: "/etc/nginx/letsencrypt.conf"
      from: "worker_connections 768" 
      to: "worker_connections 1768"
3

من المثير للاهتمام أن هذا حدث بعد إعادة البناء، هل قمت مؤخرًا بأي إجراءات جماعية؟ أود التحقق من سجلات Sidekiq ورؤية ما إذا كان هناك عدد كبير من الوظائف هناك أيضًا.

4

لقد قمت ببعض الإجراءات الجماعية مؤخرًا عند الانتقال إلى معاينة الصورة المصغرة TC، لكن لا يوجد شيء في طابور Sidekiq، لذا يمكنني استبعاد ذلك بالتأكيد.

5

قمنا بترقية إصدار nginx قبل يومين، لذا دعنا نراقبه. هل يتجاوز عدد الزوار المتزامنين على موقعك 500؟

كما أن موقعك بالكامل خلف خدمة Cloudflare، لذا قد تختلف الأمور بسبب ذلك.

6

لا أدري - ربما؟ هل لديك أي أفكار حول كيفية التحقق من ذلك؟

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

7

هاها، عادةً ما يستخدم الناس Google Analytics أو ما شابه ذلك لمعرفة هذه المعلومات. يحتوي لوحة تحكم Discourse على عدد صفحات الزيارات اليومية وزيارات المستخدمين التي يمكن استخدامها أيضًا للتقرب من ذلك.

ليس صحيحًا، حيث يتم تقديم موقعك بالكامل عبر Cloudflare:

curl -I https://blenderartists.org/                                                                                                                                         
HTTP/2 200 
cf-cache-status: DYNAMIC
cf-request-id: 0a6ef945b3000002fe272b2000000001
server: cloudflare
cf-ray: 6591c4b5ec5902fe-MIA
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400

لكن قد لا يكون ذلك مرتبطًا تمامًا، حيث أن nginx يشتكي من اتصالات upstream بدلاً من اتصالات downstream، مما يعني أنه ينفد من الاتصال بين nginx ⟷ unicorn.

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

زيادة worker_processes و worker_connections آمنة وتبدو منطقية في حالتك. نحن نحدد افتراضيًا worker_processes بناءً على عدد أنوية المعالج لديك. كم عدد أنوية المعالج التي تمتلكها؟

8

صحيح :slight_smile: لقد توقفنا عن ذلك منذ فترة طويلة.. لدينا حوالي 250 ألف مشاهدة للصفحة يوميًا (بما في ذلك الروبوتات)، لذا فإن 500 لا تبدو غير عادية. هل تتبع زيارات المستخدمين فقط الزيارات المسجلة الدخول؟

صحيح - نحن نضطر إلى تمرير طلباتنا عبر CF، لكننا لا نسمح لهم بالوصول إلى ملفات JavaScript الخاصة بنا وما إلى ذلك.

لدينا 12 نواة، وذاكرة عشوائية 64 جيجابايت. الحمل النموذجي هو حوالي 2، ونستخدم 50% من ذاكرتنا العشوائية.

9

يا إلهي، هذا غريب جدًا!

صيغة الاتصالات هي worker_processes * worker_connections، مما يعني 12 * 768، أي (كليك كلاك) 9216. لكن سجلاتك تشير إلى 1768…

جرّب هذا في ملف app.yml الخاص بك:

## أي أوامر مخصصة للتشغيل بعد البناء
run:
  - exec: echo "Beginning of custom commands"

  - replace:
      filename: "/etc/nginx/nginx.conf"
      from: "worker_connections 768" 
      to: "worker_connections 2000"
  - replace:
      filename: "/etc/nginx/nginx.conf"
      from: "worker_processes auto" 
      to: "worker_processes 10"

انتبه إلى أن حجبك في المنشور 2 يعمل على الملف الخاطئ!

10

:facepalm: لقد ألصقت الكود الخاطئ - لقد جربت قالب letsencrypt أولاً، لكنني انتهيت بتغيير nginx.conf إلى 1768 اتصال عامل.

سأجرب القيم التي اقترحتها - سأعود لأبلغ عن النتيجة.

11

ما زلتُ أواجهها، للأسف:

2021/06/02 17:40:03 [تنبيه] 2102#2102: *262491 عدد 2000 اتصال عامل غير كافٍ أثناء الاتصال بالخادم العلوي، العميل: <تم إزالة عنوان IP>، الخادم: _، الطلب: "POST /message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t HTTP/1.1"، الخادم العلوي: "http://127.0.0.1:3000/message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t"، المضيف: "blenderartists.org"، المراجع: "https://blenderartists.org/t/weight-paint-not-painting/551282"
12

لقد قمت بزيادة worker_connections إلى 4000، والأمر يبدو جيدًا حتى الآن :crossed_fingers:

13

لقد جعلنا التجاوز أسهل الآن:

14

رائع! إذن سنفعل شيئًا مثل

params:
  nginx_worker_connections: 4000

في app.yml/web_only.yml؟

15

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

16

هل يجب أن أزيل أيضًا زيادة عدد وحدات المعالجة المركزية إلى الضعف لعمليات العامل على أحد المواقع؟