الذاكرة: كم نخصص ولماذا ليس كلها

مخطط الذاكرة في لوحة التحكم يخيف القادمين الجدد: فهو دائمًا ما يكون مرتفعًا تقريبًا. هذا سلوك طبيعي في Java.

كيف تقرأه

تحجز Java الذاكرة مسبقًا ولا تحرّرها إلا أثناء جمع القمامة. النمط المسنّن على المخطط — ارتفاع الاستخدام ثم انخفاض حاد بعد الجمع — علامة على خادم سليم.

المشكلة تبدو مختلفة: الخط ملتصق بالسقف ولا ينخفض بعد الانخفاضات. هذا يعني أن القمامة لا تُحرَّر — إما أن الذاكرة منخفضة فعلًا، أو أن هناك تسريبًا.

علامات النقص

• OutOfMemoryError في السجل — تحليل.
• تجمّد لعدة ثوانٍ يزداد مع مدة التشغيل.
• يعمل الخادم جيدًا بعد إعادة التشغيل ثم يتدهور بحلول المساء.

التسريب

إذا كان الاستهلاك ينمو خطيًا ولا ينخفض، فابحث عن المتسبب:

spark heapsummary

عادةً ما يكون إضافة تتراكم البيانات، أو مودًا مع محمّلات القطع (chunk loaders) — Spark.

الإجراء المؤقت هو إعادة التشغيل التلقائي مرة واحدة يوميًا. الحل الدائم هو العثور على المتسبب وتحديثه.

لا تخصص كل الذاكرة

إلى جانب الكومة (heap)، يحتاج العملية إلى ذاكرة للبيانات الوصفية والخيوط والمخازن المؤقتة، ويحتاج الحاوية إلى ذاكرة للنظام. تراعي لوحة تحكم Millida ذلك تلقائيًا عبر ضبط حدود الكومة وفقًا للخطة — لا حاجة لتعديلها يدويًا.

متى تغيّر خطتك

عندما يلامس الاستهلاك الأقصى الحد باستمرار أثناء التشغيل العادي ولا يُظهر الملف الشخصي وجود تسريب — تغيير خطتك.