لقد قمنا للتو بالتحديث من الإصدار 3.0.6 إلى 3.1.2 وأرى العديد من أخطاء 503 في 3 نقاط رئيسية:
تفشل العديد من الصور الرمزية في التحميل
تحميل الصور يعمل فقط في بعض الأحيان
أرى أيضًا العديد من الأخطاء لـ topics/timings
لقد نظرت في سجلات الخادم، ومعظم أخطاء 503 لا تظهر حتى في production.log، ولكن nginx مليء بها. بالتفكير في أن nginx قد يكون يحد من المعدل، حاولت عدم استخدام templates/web.ratelimited.template.yml ولكن يبدو أن ذلك لم يساعد. ما زلت أرى عددًا كبيرًا من الطلبات التي تم الرد عليها بـ 503، ومعظمها user_avatars/show ومن خلال ما فهمته، يبدو أن production.log لا يراها على الإطلاق.
لا ألاحظ أي شيء خاطئ في sidekiq. ومع ذلك، كان /logs يحتوي على أخطاء مع،
'hijack user_avatars show ' لا يزال قيد التشغيل بعد 90 ثانية على قاعدة البيانات الافتراضية، قد تحتاج هذه العملية إلى إعادة التشغيل!
ولكن هذه كانت قبل بضع ساعات وأعدت بناء المثيل عدة مرات منذ ذلك الحين ولم تظهر مرة أخرى.
يستخدم هذا المثيل SSO، لذا تأتي الصور الرمزية (url) من هناك. نحن نستخدم S3 للصور.
أنا في حيرة من أمري بشأن ما يسبب هذا وقد نفدت أفكاري.
الخادم يحتوي على 16 جيجابايت ويعمل بشكل جيد لعدة أشهر قبل التحديث.
إنها نسخة AWS وتم بدء تشغيل هذه النسخة اليوم، قبل وقت قصير من التحديث (بيانات Discourse موجودة على وحدات تخزين EBS) لتغيير بعض المعلمات غير ذات الصلة.
زادت حركة مرور الشبكة (الواردة والصادرة) بشكل كبير بعد التحديث: تبدو الصور الرمزية تعمل بعد ثوانٍ قليلة من الخطأ 503 الأولي، لذا أخمن أن هناك بعض العمليات التي تعمل في المرة الأولى التي يتم فيها طلبها.
ومع ذلك، لا أعرف سبب فشل تحميل الصور بشكل عشوائي، وكذلك نقطة النهاية topics/timings.
هل يمكن أن تكون عملية تحديث خلفية الصور الرمزية هذه تصل إلى حد المعدل 3500 طلب PUT/ثانية على AWS، مما يتسبب في فشل التحميلات العادية أثناء تحديث الصور الرمزية؟ /cc @sam
تم التحديث في صباح يوم 21. يبدو أن حركة مرور الشبكة الواردة تعود إلى طبيعتها الآن. لا تزال الصادرة أعلى من المعتاد، لكنني أفترض أن ذلك أثناء تخزين الصور الرمزية مؤقتًا. كمية 503 إلى user_avatars/show أقل بكثير الآن. أتوقع أن يتم فرز هذه الأمور ببطء بمرور الوقت مع معالجة المزيد من الصور الرمزية.
ومع ذلك، لا نزال نرى العديد من أخطاء 503 في السجلات لنقطتي نهاية أخريين بشكل أساسي:
POST /topics/timings
لا تزال هناك العديد من أخطاء 503 لهذه النقطة النهائية ويبلغ بعض المستخدمين عن عدم تمييز المواضيع التي تمت زيارتها على أنها مقروءة. لم أجد أي معلومات حول ذلك حيث لا يبدو أن الطلب مسجل في production.log على الإطلاق. لا تظهر سجلات /logs أي شيء متعلق.
أين يمكن للمرء البدء في تصحيح أخطاء هذه الأخطاء 503؟ هل هناك أي سجلات أخرى لا أعرفها، أم أن هناك طريقة لجعل السجلات أكثر تفصيلاً ربما (على نظام إنتاج)؟
POST /uploads.json?client_id=....
كل ما أجده في production.log لهذه الأخطاء 503 هو على هذا النحو:
Extract from production.log
Started POST “/uploads.json?client_id=X” for x.x.x.x at 2023-10-24 10:24:55 +0000
Processing by UploadsController#create as JSON
Parameters: {“upload_type”=>“composer”, “relativePath”=>“null”, “name”=>“Screenshot 2023-10-24 at 11.22.32.png”, “type”=>“image/png”, “sha1_checksum”=>“d1f11731320437724003c3840c5dcc5f934ba25a”, “file”=>#<ActionDispatch::Http::UploadedFile:0x00007f3c5e3c9898 @tempfile=#Tempfile:/tmp/RackMultipart20231024-1991-b30vit.png, @content_type=“image/png”, @original_filename=“Screenshot 2023-10-24 at 11.22.32.png”, @headers=“Content-Disposition: form-data; name="file"; filename="Screenshot 2023-10-24 at 11.22.32.png"\r\nContent-Type: image/png\r\n”>, “client_id”=>“X”}
Rendered text template (Duration: 0.0ms | Allocations: 1) Completed 503 Service Unavailable in 10ms (Views: 0.4ms | ActiveRecord: 0.0ms | Allocations: 5007)
يبلغ مستخدمونا أنهم يعيدون المحاولة عدة مرات حتى يعمل الأمر… أنا قادر على تكرار الخطأ بشكل ثابت تقريبًا إذا حاولت تحميل ملف (آخر) إذا كان هناك ملف آخر قيد التحميل بالفعل. يبدو تحميلها واحدًا تلو الآخر أقل عرضة لذلك لسبب ما.
# free -h
total used free shared buff/cache available
Mem: 15Gi 3.8Gi 621Mi 1.1Gi 10Gi 10Gi
# lscpu --parse=core | egrep -v # | sort -u | wc -l
2
