خطأ 502 على nginx

مرحبًا،

لقد قمت للتو بتشغيل ./launcher rebuild app دون ظهور أي أخطاء واضحة. ولكن عند محاولة فتح الموقع، أحصل على خطأ 502.

يُظهر سجل أخطاء nginx (shared/standalone/log/var-log/nginx/error.log) ما يلي:

2020/08/12 05:47:43 [error] 653#653: *7 connect() failed (111: Connection refused) while connecting to upstream, client: [...], server: _, request: "GET / HTTP/2.0", upstream: "http://127.0.0.1:3000/", host: "[...]"

لقد تفحصت جميع المواضيع التي وجدتُها حول أخطاء 502 في discourse و nginx، لكن لم أستطع العثور على شيء أو فهم أي شيء منطقي ينطبق على حالتي.

قد يكون هذا ذا صلة، عند التشغيل من داخل الحاوية:

# netstat -plant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      644/nginx: master p 
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      644/nginx: master p 
tcp6       0      0 :::6379                 :::*                    LISTEN      -                   
tcp6       0      0 :::5432                 :::*                    LISTEN      -

هل هناك شيء يجب أن يعمل على المنفذ 3000؟

هل يمكنك توجيهي إلى أين أبحث للحصول على مزيد من المعلومات لتصحيح هذه المشكلة؟

pura vida :slight_smile:

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

3 إعجابات

شكرًا لك @itsbhanusharma.

نفذت الأمر ./launcher restart app ورصدت الحمل باستخدام top، وهو أقل بكثير من 10%.

أعتقد أن المعالج يجب أن يكون كافيًا للتعامل مع الحمل:

$ cat /proc/cpuinfo  | grep 'name' | uniq
model name      : Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
$ cat /proc/cpuinfo  | grep process | wc -l
4

هل توجد طريقة أفضل لتصحيح أخطاء بدء تشغيل الحاوية؟
أي أفكار أخرى؟

إعجاب واحد (1)

ما هي الإضافات المثبتة؟ هل هذا الخادم يعمل على قرص SSD؟

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

الخادم ليس من نوع SSD.

مرحبًا @elopio

ربما يمكنك نشر ملف ‘yml’ الخاص بك دون أي معلومات حساسة؟

بالتأكيد، هو هنا:

يتطلب Discourse أقراص SSD، لأن الأقراص التقليدية ذات الأذرع الدوارة لا توفر عدد عمليات الإدخال/الإخراج (IOPS) الكافي.

وهل هذا هو سبب خطأ 502؟ أم أنه بدون محرك أقراص حالة صلبة (SSD) يجب أن أرى الموقع يعمل، ولكن ببطء شديد؟

استخدام قرص صلب تقليدي مقابل قرص SSD لا ينبغي أن يتسبب في حدوث خطأ 502. هذا غير مرجح حقًا، كما يشير سؤالك @elopio.

إليك ملخص صغير قد يكون مفيدًا:

أفضل ما يمكن فعله، في رأيي، هو فتح بعض النوافذ الطرفية وتشغيل tail -f على ملفات سجل Rails و nginx الخاصة بك، بما في ذلك سجلات الأخطاء وسجلات الوصول؛ ثم حاول الوصول وتأكد من أنك عندما ترى خطأ 502، فإن عينيك تراقبان نهاية ملفات السجل.

هل تعرف أين توجد ملفات السجل هذه وكيف يمكنك تشغيل أوامر tail -f عليها في النوافذ الطرفية؟


ملاحظة، لقد سئلت سابقًا:

يعمل Rails على المنفذ 3000 داخل حاوية Docker، وهذا المنفذ غير مكشوف خارج الحاوية. هذا هو السبب في أنك لا ترى المنفذ 3000 خارج الحاوية عند تشغيل netstat خارج الحاوية.

أرجو أن يكون ذلك مفيدًا

بناءً على الخبرة، فإن الإدخال/الإخراج البطيء (slow IO) يمكن بالتأكيد ويسبب فعليًا فترات انتظار وانتهاء مهلة (timeouts) تؤدي إلى خطأ 502.

معدلات IOPS على مستوى SSD هي شرط إلزامي.

ووو، عند النظر إلى سجلات Rails، وجدت أن سجل Unicorn كان ضخمًا، يشكو من بعض أخطاء الأذونات. قمت بحذف rm -rf tmp/cache/bootsnap-compile-cache/، والآن أرى شاشة التهنئة!!!

شكرًا لكم يا أصدقائي. سأجرب هذا قليلًا قبل أن أقرر إعادة إنشائه على خادم SSD.

4 إعجابات

على الرحب والسعة @elopio

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

نتمنى لك مستقبلًا مليئًا بالنجاح!

إعجاب واحد (1)

حسنًا، هذا يعمل بامتياز. أود أن أظهر ما نقوم به:

https://bunqueer.jaquerespeis.org/

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

إعجابَين (2)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.