هل يلاحظ أحد آخر نفس الشيء؟ إنه منتدى متواضع نسبيًا من حيث الحجم وحركة المرور. هناك أربعة عمليات عاملة لـ Pitchfork، ويبدو أن واحدة منها تتعامل مع الغالبية العظمى من الطلبات الواردة وتستهلك ذاكرة أكثر من غيرها. هناك الكثير من الذاكرة الافتراضية (Swap) قيد الاستخدام، وعند إعادة إنشاء Pitchfork عمدًا، ينخفض هذا الاستخدام بشكل كبير. لذلك أستنتج أن عمليات Pitchfork تحتوي حاليًا على العديد من الصفحات الباردة التي تم تبديلها إلى الذاكرة الافتراضية.
هذا بعد 20 يومًا من التشغيل، على جهاز بذاكرة عشوائية (RAM) سعتها 4 غيغابايت وذاكرة افتراضية سعتها 4 غيغابايت.
لن يكون من الجيد نفاد الذاكرة الافتراضية. ولن يكون من الجيد أيضًا أن نجد كل تلك الذاكرة الافتراضية تُعاد إلى الذاكرة الرئيسية (Paged back in)، وهو ما قد يحدث عندما يقوم Pitchfork في النهاية بجمع القمامة (Garbage Collection).
هل يلاحظ أي شخص آخر شيئًا مشابهًا؟ يرجى مشاركة تكوين الجهاز!
على نحوٍ أكثر جدية، هل من الطبيعي أن يكون العامل الذي يقوم بكل العمل أعلى بـ 100 ميغابايت فقط من متوسط الذاكرة (RSS)؟ يبدو الأمر طبيعياً لي، أم أنني أغفل شيئاً؟
من الطبيعي أن يتولى عميل واحد من عملاء Pitchfork معظم الحمل - حيث يتم اختيار العملاء الآخرين فقط عندما يكون العميل الأول مشغولًا. كما أنه من الطبيعي أن يتزايد حجم الذاكرة بمرور الوقت. على الرغم من أنه يجب أن يصل في النهاية إلى حالة مستقرة، بعد أن يتم تسخين كل شيء مثل ذاكرة التخزين المؤقت / ruby-JIT.
إليك رسم بياني من أحد عناقيد الإنتاج لدينا، على مدى فترة 7 أيام. يتتبع هذا الرسم العملية الواحدة التي لديها أعلى استخدام للذاكرة. تشير الخطوط الخضراء المنقطة إلى عمليات النشر (أي عمليات البدء الجديدة لـ Pitchfork):
لذا يمكنك أن ترى أنه يتزايد بعد الإطلاق الأولي، ثم يستقر عند أقل بقليل من 1.4 جيجابايت. يقوم هذا العنقود بخدمة مئات المواقع، لذا ربما لا يكون هذا أفضل مقارنة من حيث الأرقام… لكنني أتمنى أن يكون تصور النمو مفيدًا.
البحث في أرقام RSS لكل عملية لا يخبرك بالقصة كاملة. Pitchfork هو “خادم ويب يعتمد على التفرع”. لذا فهو يشغل عملية ‘القالب’، ثم يتم تفرع جميع العمال منها بنمط ذاكرة الكتابة عند التفرع (copy-on-write). لذا، بينما قد تظهر RSS 500 ميجابايت للعامل [0]، فإن حوالي 200 ميجابايت منها مشتركة مع القالب وجميع العمال الآخرين.
في المستقبل القريب، نأمل في تمكين ميزة “إعادة التفرع” في Pitchfork. تقوم هذه الميزة بقتل العمال دوريًا، وإعادة تفرعهم من عامل دافئ بالفعل، بحيث يتشاركون أكبر قدر ممكن من الذاكرة بمرور الوقت. ومع ذلك، هناك حاجة إلى بعض العمل للتأكد من أن جميع أكوادنا متوافقة مع هذا النوع من النمط
تصويرة مفيدة، شكرًا. لن أقول إن الأمر قد استقر تمامًا، لكن معدل النمو ليس مرتفعًا كما كان من قبل.
إعادة التفرّع الدورية تبدو أمرًا رائعًا لإدراجه — إن أمكن، يُرجى الإشارة إلى ذلك هنا عندما يتم تنفيذه.
هل يمكنك إلقاء الضوء على الخطوط الخضراء؟ أنا مهتم بمعرفة متى (إن حدث ذلك أصلًا) تقوم عمليات التفرّع بجمع القمامة، وما الذي يسببها، وما تأثيرها أثناء حدوثها.
الخطوط الخضراء تشير إلى مواعيد نشر التحديثات. بشكل أساسي: ./launcher rebuild app.
تقوم لغتا Ruby (وJS، التي نُشغّلها داخل عمليات Ruby عبر MiniRacer/v8) باستمرار بجمع القمامة أثناء التشغيل، واستجابةً للإشارات القادمة من نظام التشغيل. لذا، لا أعتقد أن هناك أي فائدة كبيرة يمكن تحقيقها من خلال القيام بأي إجراء يدوي.
شكرًا. سأكون مهتمًا برؤية كيف تسير الأمور على المدى الطويل، وهو ما لن يكون واضحًا على خادم يتم تحديثه بشكل متكرر نسبيًا. في حالتي، كان لدي 20 يومًا، ثم اخترت استخدام pitchfork لإعادة التشغيل، وهو ما أبلغني بشيء ما، لكنه أعاد ضبط العداد أيضًا.
