من الطبيعي أن يتولى عميل واحد من عملاء Pitchfork معظم الحمل - حيث يتم اختيار العملاء الآخرين فقط عندما يكون العميل الأول مشغولًا. كما أنه من الطبيعي أن يتزايد حجم الذاكرة بمرور الوقت. على الرغم من أنه يجب أن يصل في النهاية إلى حالة مستقرة، بعد أن يتم تسخين كل شيء مثل ذاكرة التخزين المؤقت / ruby-JIT.
إليك رسم بياني من أحد عناقيد الإنتاج لدينا، على مدى فترة 7 أيام. يتتبع هذا الرسم العملية الواحدة التي لديها أعلى استخدام للذاكرة. تشير الخطوط الخضراء المنقطة إلى عمليات النشر (أي عمليات البدء الجديدة لـ Pitchfork):
لذا يمكنك أن ترى أنه يتزايد بعد الإطلاق الأولي، ثم يستقر عند أقل بقليل من 1.4 جيجابايت. يقوم هذا العنقود بخدمة مئات المواقع، لذا ربما لا يكون هذا أفضل مقارنة من حيث الأرقام… لكنني أتمنى أن يكون تصور النمو مفيدًا.
البحث في أرقام RSS لكل عملية لا يخبرك بالقصة كاملة. Pitchfork هو “خادم ويب يعتمد على التفرع”. لذا فهو يشغل عملية ‘القالب’، ثم يتم تفرع جميع العمال منها بنمط ذاكرة الكتابة عند التفرع (copy-on-write). لذا، بينما قد تظهر RSS 500 ميجابايت للعامل [0]، فإن حوالي 200 ميجابايت منها مشتركة مع القالب وجميع العمال الآخرين.
في المستقبل القريب، نأمل في تمكين ميزة “إعادة التفرع” في Pitchfork. تقوم هذه الميزة بقتل العمال دوريًا، وإعادة تفرعهم من عامل دافئ بالفعل، بحيث يتشاركون أكبر قدر ممكن من الذاكرة بمرور الوقت. ومع ذلك، هناك حاجة إلى بعض العمل للتأكد من أن جميع أكوادنا متوافقة مع هذا النوع من النمط 