مشاركة عبر

مشكلات إعادة تشغيل التطبيق بسبب مشكلات نفاد الذاكرة

  • مقالة

إشعار

يعد Azure Spring Apps هو الاسم الجديد لخدمة Azure Spring Cloud. رغم أن الخدمة تحمل اسماً جديداً، سترى الاسم القديم في بعض الأماكن لفترة من الوقت بينما نعمل على تحديث الأصول مثل لقطات الشاشة، ومقاطع الفيديو، والرسوم التخطيطية.

تنطبق هذه المقالة على: ✔️ Basic/Standard ✔️ Enterprise

توضح هذه المقالة مشكلات نفاد الذاكرة (OOM) لتطبيقات Java في Azure Spring Apps.

أنواع مشكلات نفاد الذاكرة

هناك نوعان من مشكلات نفاد الذاكرة: OOM الحاوية وJVM OOM.

  • يحدث OOM الحاوية، الذي يسمى أيضا اسم OOM للنظام، عند نفاد ذاكرة التطبيق المتوفرة. تتسبب مشكلة OOM في الحاوية في أحداث إعادة تشغيل التطبيق، والتي تم الإبلاغ عنها في قسم Resource Health في مدخل Microsoft Azure. عادة ما يحدث OOM للحاوية بسبب تكوينات حجم الذاكرة غير الصحيحة.

  • يحدث JVM OOM عندما يصل مقدار الذاكرة المستخدمة إلى الحد الأقصى للحجم المحدد في خيارات JVM. لن يتسبب JVM OOM في إعادة تشغيل التطبيق. عادة ما يكون JVM OOM نتيجة للتعليمات البرمجية السيئة، والتي يمكنك العثور عليها من خلال البحث عن java.lang.OutOfMemoryError استثناءات في سجل التطبيق. JVM OOM له تأثير سلبي على التطبيق وأدوات Java Profiling، مثل Java Flight Recorder.

تركز هذه المقالة على كيفية إصلاح مشكلات OOM للحاوية. لإصلاح مشكلات JVM OOM، تحقق من أدوات مثل تفريغ كومة الذاكرة المؤقتة وتفريغ مؤشر الترابط ومسجل Java Flight Recorder. لمزيد من المعلومات، راجع التقاط تفريغ كومة الذاكرة المؤقتة وتفريغ مؤشر الترابط يدويا واستخدم مسجل Java Flight Recorder في Azure Spring Apps.

إصلاح مشكلات إعادة تشغيل التطبيق بسبب OOM

تصف الأقسام التالية الأدوات والمقاييس وخيارات JVM التي يمكنك استخدامها لتشخيص مشكلات OOM للحاوية وإصلاحها.

عرض التنبيهات في صفحة صحة الموارد

تعرض صفحة Resource health في مدخل Microsoft Azure أحداث إعادة تشغيل التطبيق بسبب OOM الحاوية، كما هو موضح في لقطة الشاشة التالية:

Screenshot of Azure portal showing Azure Spring Apps Resource Health page with OOM message highlighted.

تكوين حجم الذاكرة

مقاييس استخدام ذاكرة التطبيق، jvm.memory.used، وتوفر jvm.memory.committed طريقة عرض لاستخدام الذاكرة. لمزيد من المعلومات، راجع قسم المقاييس في أدوات لاستكشاف مشكلات الذاكرة وإصلاحها. قم بتكوين الحد الأقصى لأحجام الذاكرة في خيارات JVM للتأكد من أن الذاكرة تحت الحد.

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

ابحث عن توازن عند تعيين الحد الأقصى لحجم الذاكرة. عند تعيين الحد الأقصى لحجم الذاكرة مرتفع جدا، هناك خطر من OOM للحاوية. عند تعيين الحد الأقصى لحجم الذاكرة منخفض جدا، هناك خطر من OOM JVM، وسوف تكون مجموعة البيانات المهملة من وسوف تبطئ التطبيق.

التحكم في ذاكرة كومة الذاكرة المؤقتة

يمكنك تعيين الحد الأقصى لحجم كومة الذاكرة المؤقتة -Xmsباستخدام خيارات و -XX:InitialRAMPercentage-Xmxو و -XX:MaxRAMPercentage JVM.

قد تحتاج إلى ضبط الحد الأقصى لإعدادات حجم كومة الذاكرة المؤقتة عندما تكون قيمة jvm.memory.used عالية جدا في المقاييس. لمزيد من المعلومات، راجع قسم jvm.memory.used/committed/max من الأدوات لاستكشاف مشكلات الذاكرة وإصلاحها.

التحكم في الذاكرة المباشرة

من المهم تعيين -XX:MaxDirectMemorySize خيار JVM للأسباب التالية:

  • قد لا تلاحظ عندما تستخدم أطر العمل مثل nio وgzip الذاكرة المباشرة.
  • يتم التعامل مع جمع البيانات المهملة للذاكرة المباشرة فقط أثناء تجميع البيانات المهملة الكاملة، ولا تحدث مجموعة البيانات المهملة الكاملة إلا عندما تكون كومة الذاكرة المؤقتة قريبة من ممتلئة.

عادة، يمكنك تعيين MaxDirectMemorySize إلى قيمة أقل من حجم ذاكرة التطبيق مطروحا منها ذاكرة كومة الذاكرة المؤقتة مطروحا منها الذاكرة غير كومة الذاكرة المؤقتة.

التحكم في مساحة التعريف

يمكنك تعيين الحد الأقصى لحجم مساحة التعريف عن طريق تعيين -XX:MaxMetaspaceSize خيار JVM. يعين -XX:MetaspaceSize الخيار قيمة الحد لتشغيل تجميع البيانات المهملة الكامل.

عادة ما تكون ذاكرة Metaspace مستقرة.

(راجع أيضًا )