أعمل على موقع ذي حجم مرتفع نسبيًا (>150 ألف مشاهدة صفحة/يوم). أواجه بعض أخطاء 429، معظمها على الأقل على ناقل الرسائل. كان لدي سابقًا بعض المشاكل بسبب سوء تكوين set_real_ip_from، لكن تم حلها. كما قمت بإزالة (ربما مؤقتًا؟) قالب تحديد المعدل.
ما زلت ألاحظ حوالي 0.5 خطأ 429 في الثانية.
لدي 5 عمال Unicorn مع معالج من 2 نواة/4 خيوط. ذاكرة وصول عشوائي 16 جيجابايت. قاعدة بيانات Postgres على مضيف منفصل. تظل وحدات المعالجة المركزية خاملة بنسبة تزيد عن 50%.
قمت بإزالة قالب تحديد المعدل ورفع عدد عمال Unicorn إلى 5 حوالي الساعة 8:20.
هذا أمر طبيعي تمامًا، حيث سيتوقف مؤقتًا (backoff) نظام الرسائل (message-bus) مع رمز الاستجابة 429 لأن وحدات المعالجة (unicorns) الخاصة بك تحت ضغط كبير وتعمل على طابور انتظار قليلاً.
إن نسبة 4 أنوية مع 16 جيجابايت من الذاكرة العشوائية غريبة جدًا إذا لم يكن العقدة تشغّل قاعدة البيانات. على سبيل المثال، ستكون النسبة 8/8 أفضل.
عظيم! شكرًا لك. لا يزال المعالج المركزي (CPU) تحت ضغط كبير بسبب معالجة الصور، وهو ما أتمنى أن يتم إنجازه خلال يوم أو يومين.
صحيح تمامًا. لكن الجهاز المادي (bare metal) يحتوي على نواتين/4 خيوط معالجة. من السهل إضافة ذاكرة عشوائية، لكن ليس الأنوية (لدي جهاز آخر في المنزل بذاكرة 32 جيجابايت!). قمت بفصل قاعدة البيانات عن الويب إلى جهازين للحصول على مزيد من قوة المعالجة. لدي نصف دزينة من قواعد البيانات الأخرى لمواقع ذات حركة مرور منخفضة على خادم قاعدة البيانات نفسه (الويب على مضيف مختلف). هل تعتقد أنه من الأفضل تشغيل قاعدة البيانات والويب على نفس الجهاز؟ سأفقد بعض قوة المعالجة لكنني سأحسن زمن الاستجابة، على ما أظن.
إذا كانت لديك إمكانية موازنة التحميل هنا، فقد تُجرّب تشغيل عمال الويب على كلا الجهازين لموقعك عالي الحمل، مع تشغيل عدد أقل على الجهاز الذي يحتوي على قاعدة البيانات، ربما 5+2؟
إذا كان حل المشكلة عن طريق الإنفاق خيارًا متاحًا، فكل ما عليك هو الحصول على مضيف آخر بمعدل أفضل بين وحدة المعالجة المركزية والذاكرة العشوائية.
حسنًا، هذه الآلات التي حصلت عليها مجانًا تبدأ في التقدم في السن، لذا أبدأ في التوفيق مع ذلك—مع أن أداء المعالج الواحد لا يزال يبدو أفضل من Droplet من DigitalOcean. إذا كان حل المشكلة بالمال في المدى القصير خيارًا متاحًا، فلن أكون على الأرجح مع هذا العميل المحدد الذي يريد أداءً مؤسسيًا بأسعار تجارية.
لكنني ألاحظ أيضًا أنني قمت بتعيين عدد unicorns بشكل ثابت في مكان آخر من السلسلة، لذا لا يزال لدي 3 فقط قيد التشغيل.
للأسف، تكويني الحالي يتحدث فقط مع Docker على المضيف الواحد. ربما يجب أن أقضي وقتًا أطول قليلًا لأرى ما إذا كان بإمكاني إضافة بضع unicorns إلى الجهاز الآخر أيضًا. ربما حان الوقت للنظر في HAproxy مرة أخرى، لكن لدي مشروع آخر أود إطلاقه أولًا.
شكرًا جزيلاً على رؤيتك القيمة.
تعديل: وعندما انتقلت أخيرًا إلى 5 unicorns بدلاً من 3، بدت رسوم الأداء المرسومة متشابهة (ربما أبطأ قليلًا؟)، لكن أخطاء 429 انخفضت بشكل ملحوظ. يبدو أنه بمجرد الانتهاء من معالجة الصور، سيعمل هذا النظام بشكل ممتاز.
وفي اليوم التالي فقط، انخفضت أخطاء 429 إلى ما يقرب من الصفر، لذا فإن نصيحة رافائيل «لا تقلق ببساطة» كانت نصيحة رائعة! شكرًا مرة أخرى، كين ورافائيل. لا يمكنني المبالغة في تقدير مدى تقديري لمساعدتكم.
