يواجه الخادم مشاكل مع summary.json لبعض المستخدمين العشوائيين ويعيد رمز 502. ربما بدأ بعد التحديث الأخير، لكنني لست متأكدًا.
أنا لست على دراية بمكدس discourse ولدي صعوبة في البحث عن السجلات. تم التعديل لإخفاء اسم المستخدم وعنوان IP، قد يختلف الوقت ولكن في الغالب هو نفس طلب صفحة الملف الشخصي مكرر عدة مرات.
/shared/log/rails/production_errors.log فارغ، و /shared/log/rails/production.log يحتوي فقط على
Started GET "/u/user/summary.json" for *.*.*.* at 2024-05-24 20:26:56 +0000
Processing by UsersController#summary as JSON
Parameters: {"username"=>"user"}
بدون “Completed 200 OK” لطلبات مماثلة.
يبدو أنه لا توجد سجلات ذات صلة في unicorn (فقط أخطاء الاتصال بـ redis عند بدء التشغيل، ولكن يبدو أنها ناجحة في النهاية وليست ذات صلة).
ولكن هناك طلب واحد مشبوه مع وقت مدة طويل من /var/log/postgres/current:
2024-05-24 20:49:12.727 UTC [2919] discourse@discourse LOG: duration: 95288.368 ms execute <unnamed>: SELECT replies.user_id, COUNT(*) FROM "posts" INNER JOIN "topics" "topics_posts" ON "topics_posts". "deleted_at" IS NULL AND "topics_posts". "id" = "posts". "topic_id" JOIN posts replies ON posts.topic_id = replies.topic_id AND posts.reply_to_post_number = replies.post_number JOIN topics ON replies.topic_id = topics.id AND topics.archetype <> 'private_message' AND replies.post_type IN (1) WHERE "posts". "deleted_at" IS NULL AND (posts.post_type IN (1,4)) AND "topics". "deleted_at" IS NULL AND (topics.archetype <> 'private_message') AND "topics". "visible" = TRUE AND (topics.category_id IS NULL OR topics.category_id IN (SELECT id FROM categories WHERE NOT read_restricted OR id IN (4,8,20,46,55,60,62,67))) AND "posts". "user_id" = 5318 AND (replies.user_id <> posts.user_id) GROUP BY "replies". "user_id" ORDER BY COUNT(*) DESC LIMIT 6
2024-05-24 20:49:12.728 UTC [2919] discourse@discourse LOG: could not send data to client: Broken pipe
2024-05-24 20:49:12.729 UTC [2919] discourse@discourse FATAL: connection to client lost
لست خبيراً، لكن ديسكورس (Discourse) يميل إلى أن يتطلب المزيد من ذاكرة الوصول العشوائي (RAM) هذه الأيام، اعتماداً على إعداداتك (2 جيجابايت على الأقل). هل لديك مساحة تبديل (swap) مهيأة؟
نعم، 4 جيجا بايت من التبديل. وفي /logs بعض التحذيرات مثل إشعارات الإهمال أو شيء عن geolite.
2024-05-24 20:49:12.727 UTC [2919] discourse@discourse LOG: duration: 95288.368 ms execute «unnamed»: SELECT replies.user_id, COUNT(*) FROM "posts" INNER JOIN "topics" "topics_posts" ON "topics_posts". "deleted_at" IS NULL AND "topics_posts". "id" = "posts". "topic_id" JOIN posts replies ON posts.topic_id = replies.topic_id AND posts.reply_to_post_number = replies.post_number JOIN topics ON replies.topic_id = topics.id AND topics.archetype <> 'private_message' AND replies.post_type IN (1) WHERE "posts". "deleted_at" IS NULL AND (posts.post_type IN (1,4)) AND "topics". "deleted_at" IS NULL AND (topics.archetype <> 'private_message') AND "topics". "visible" = TRUE AND (topics.category_id IS NULL OR topics.category_id IN (SELECT id FROM categories WHERE NOT read_restricted OR id IN (4,8,20,46,55,60,62,67))) AND "posts". "user_id" = 5318 AND (replies.user_id <> posts.user_id) GROUP BY "replies". "user_id" ORDER BY COUNT(*) DESC LIMIT 6
قد يكون من المفيد تشغيل vmstat 5
على الخادم (في اتصال ssh) أثناء قيامك بذلك، لمعرفة ما قد يحدث مع الترحيل. (يمكن استخدام top ولكنه أقل فائدة بكثير هنا)
يبدو أن PostgreSQL يقوم ببعض التحسينات/التخزين المؤقت، لذا لا يستغرق الأمر وقتًا طويلاً في بعض الأحيان، لذلك أحتاج إلى البحث عن مستخدمين جدد لاختبار الطلبات.
شكرًا على إخراج vmstat. بالنسبة لي، هذا يعني أن الذاكرة ليست مفرطة الالتزام - لينكس لا يقوم بالتبديل - ولكن قاعدة البيانات لم تتمكن من تخصيص ذاكرة وصول عشوائي كافية - فهي تقوم بالكثير من عمليات الإدخال/الإخراج على القرص.
لذلك أعتقد أن هذه ستكون حالة الحاجة إلى المزيد من ذاكرة الوصول العشوائي، وإضافة مساحة مبادلة لن تساعد كثيرًا.
إذًا لقد قمت أيضًا بالتراجع عن التغيير ووجدت أن الأداء عاد إلى طبيعته؟
ربما تكون مشكلة في وحدة المعالجة المركزية أيضاً. ولكن باستثناء عندما كان discourse يقوم ببعض مهام الصيانة، لم نواجه تقريباً أي مشاكل في الأداء من قبل. فقط الآن مع صفحة الملف الشخصي، لذلك كنت أفكر في آخر تحديث.
لكن يجب أن أقول أنه قبل محاولة التراجع، قمت أيضاً بتعديل app.yml:
لسبب ما كان لدينا db_shared_buffers: \"128MB\"، أقل بأربع مرات من الموصى به، ربما شيء موروث من الوقت الذي كنت فيه أقوم بإعداد المنتدى لأول مرة. لقد علقت هذا، حتى يتمكن discourse من إعداده بنفسه بناءً على ذاكرة الوصول العشوائي للمضيف.
لقد قمت أيضاً بإلغاء التعليق على db_work_mem: \"40MB\"
لكنني قمت بإعادة بناء سليمة واختبرت هذا أولاً، ولم يساعدنا. فقط بعد التراجع أصبح الوضع أفضل.
لقد اختبرت للتو مرة أخرى بدون تراجع فقط في حالة، ويمكنني رؤية 502 على الملفات الشخصية مرة أخرى.
إذا لزم الأمر، يمكنني إجراء المزيد من الاختبارات مع/بدون التصحيح.
ربما، ولكن بالنظر إلى الوقت المستغرق في الانتظار، أعتقد أن الأمر يتعلق في الغالب بالإدخال/الإخراج. بمجرد حل عنق زجاجة الإدخال/الإخراج، يمكن لـ vmstat إظهار ما إذا كانت وحدة المعالجة المركزية قد وصلت إلى أقصى حد لها.
الخلاصة هنا، أعتقد، هي أن طلب السحب المقبول، والذي كان يهدف إلى تسريع الأمور، قد أبطأها في الواقع، أو حتى كسرها، في المواقع ذات ذاكرة الوصول العشوائي (RAM) المحدودة؟
هل يمكننا التراجع عن طلب السحب هذا حتى يتم فهم ذلك؟
شكرًا لملاحظتك هذا، لقد تم تضليلي بواسطة التعليق حينها. أشعر أن ضبط هذا على 512 ميجابايت يدويًا قد ساعد قليلاً، لكن الأداء في صفحات الملف الشخصي لا يزال غير جيد بما فيه الكفاية ويستغرق أحيانًا نصف دقيقة للتحميل.
