حل مشكلة توقف العمليات التي تستنفد الذاكرة

لقد أصدرنا مؤخرًا برنامج كاشف الأعطال من IBM Instana™، الذي يكتشف تلقائيًا حالات التوقف غير الطبيعية للعمليات على جميع أجهزة Linux® التي تعمل بنظام Linux ذي 4.8 أنوية فما فوق، ويبلغ عنها. تستخدم منصة IBM Instana وظائف مرشح حزم بيركلي الممتد (eBPF) في أنوية نظام Linux للاتصال بالنواة نفسها وبدء رصد حالات توقف العمليات. تُرسل أي حالات توقف غير طبيعية إلى الوكيل المضيف، والذي يفحصها مقابل العمليات التي يراقبها لتجنب مشاكل العمليات غير ذات الصلة، ثم يُعيد المعلومات إلى الواجهة الخلفية من IBM Instana . وقد ثبت أن هذه الوظيفة كانت بمثابة نقطة تحول لعملائنا في أثناء محاولتهم استكشاف الحوادث وإصلاحها.

من خلال برنامج كاشف الأعطال، توفر برمجيات IBM Instana البيانات المهمة للعديد من المشكلات التي تؤثر في أداء تطبيقات عملائنا. نحن نعمل الآن على تحسين هذه الوظيفة عن طريق إضافة حالات توقف العمليات التي تستنفد الذاكرة (OOM killer) إلى برنامج كاشف الأعطال، وهي إضافة قيمة مذهلة نظرًا لأهميتها لتطبيقات الحاويات.

قد تجعل السحابة الأمر يبدو وكأنك إذا كان لديك ميزانية كافية، فلديك قدرة حاسوبية غير محدودة بين يديك. إلا إن القدرة الحاسوبية هذه تأتي على أجزاء. المضيفون (الماديون والافتراضيون على حد سواء)، والحاويات والوظائف – جمعيهم لهم قيود على مقدار الذاكرة التي يمكنك تخصيصها.

عملية توقف العمليات التي تستنفد الذاكرة على نظام Linux هي عملية مسؤولة عن منع العمليات الأخرى من استنزاف ذاكرة المضيف كلها. عندما تحاول إحدى العمليات تخصيص ذاكرة أكبر مما هو متاح، فإن العملية الأسوأ بشكل عام — من حيث، مثلاً، مدى زيادة مقدار الذاكرة التي تخصصها عما هو مسموح به — ستتلقى إشارة توقف العمليات التي تستنفد الذاكرة (OOM). وهذا يعني في الأساس أنك: "تجاوزت الحد المسموح به. توقف عن العمل أو اجعل بعضًا من عملياتك الصغيرة تتوقف، وإلا فستتوقف الخدمة".

لاحظ أن العملية التي تتسبب في توقف العمليات التي تستنفد الذاكرة قد لا تكون هي نفسها العملية التي تتلقى إشارة OOM. قد تُرسل إشارة OOM فجأة إلى تطبيق لم يرفع استخدام ذاكرته مؤخرًا نظرًا إلى بدء تشغيل العديد من التطبيقات الأخرى على المضيف نفسه.

تبدو آليات إشارة OOM صارمة، لكنها في الواقع آلية فعالة للغاية لتجنب استنفاد الذاكرة على المضيفين، خاصةً في حال عدم تناسب حجم التطبيقات أو تشغيل العديد من التطبيقات بالتوازي (أي، لا يتم تحديد حجم المضيفين بشكل يتناسب مع عبء العمل).

بالنسبة إلى منصات الحاويات مثل Kubernetes وCloud Foundry وNomad، فإن استخدام الذاكرة - سواءً من حيث تحديد حجم التطبيقات بشكل مناسب وعدد التطبيقات المسموح بتشغيلها في وقت واحد على المضيف - يُعد أكثر أهمية. بشكل عام، أنت لا تحدد بالتفصيل التطبيقات التي تعمل وعلى أي واحدة من العقد. وفي العديد من الإعدادات، سيخصص المنظم الحاويات وفقًا لبعض القواعد المنطقية. يُعد تطبيق الحد الأقصى لاستهلاك الذاكرة أمرًا بالغ الأهمية بالنسبة إلى الحاويات ومجموعات التحكم (cgroups)، وهي الأساس لكل تقنيات الحاويات تقريبًا على Linux. وهي تستخدم أيضًا نظام توقف العمليات التي تستنفد الذاكرة للتأكد من أن العمليات التي تعمل في المجموعة (أي الحاوية) نفسها لا تخصص ذاكرة أكبر من المسموح بها. عندما تحاول العمليات في حاوياتك تخصيص ذاكرة أكبر من المسموح بها، فسيتوقف بعضها، ما يؤدي غالبًا إلى إيقاف حاوياتها معها.

ويصبح كل شيء أصعب على نطاق واسع، بما في ذلك تحديد الحجم. كلما زاد عدد الحاويات التي تشغلها في بيئاتك، كان من الصعب معرفة وقت وكيفية وسبب توقف بعضها. يمكن أن يتسبب توقف العمليات التي تستنفد الذاكرة في حدوث مواقف ضارة بتطبيقاتك حيث يتعطل شيء ما دائمًا في مكان ما ثم يُعاد تشغيله، ما يؤدي إلى وجود قدر ثابت من الأخطاء لدى المستخدمين النهائيين ويضر بأهداف مستوى الخدمة (SLOs) لديك ويجعل من الصعب حقًا استكشاف الأخطاء وإصلاحها.

يعتمد اكتشاف سبب إيقاف نظام توقف العمليات التي تستنفد الذاكرة لأي عملية على التقنيات التي تستخدمها إلى حد كبير. ستسجلها بعض مجموعات البرمجيات في سجلاتها الخاصة. أو قد ينتهي بك الأمر إلى تشغيل بعض الأوامر مثل ما يلي على مضيفيك - على كل منهم:

     #CentOS
     grep -i "out of memory" /var/log/messages
     #Debian / Ubuntu
     grep -i "out of memory" /var/log/kern.log

تبدو بسيطة، لكنها بالتأكيد ليست من المهام التي تريد تشغيلها عبر أسطول الإنتاج لديك لمحاولة معرفة سبب تعطل MySQL مجددًا في الساعة 3 صباحًا. وخاصة عندما يكون الأمر مبنيًا على حدس، حيث لا يبدو أن هناك شيئًا آخر يفسر سبب توقف عملية قاعدة البيانات.

بمعنى آخر، نظام توقف العمليات التي تستنفد الذاكرة هو نظام ذو أهمية وفعالية لا شك فيها للموثوقية التي تفشل في توفير إمكانيات المراقبة الكافية. ولكن منصة IBM Instana موجودة هنا لإصلاح هذه المشكلة من أجلك.

استنادًا إلى أساس مرشح حزم بيركلي الممتد (eBPF) الذي يقوم عليه برنامج كاشف الأعطال، يأتي برنامج IBM Instana الآن مزودًا بكاشف حالات التوقف غير الطبيعية للعمليات التي تستنفد الذاكرة. عند مراقبة عملياتك باستخدام برنامج IBM Instana، فإنها تتلقى إشارة OOM في الوقت الفعلي. ليس فقط إشارة بالتوقف، بل أيضًا كيف جرى حل الموقف (أي ما العملية التي توقفت).

على غرار معظم مزايا IBM Instana، كل ما عليك فعله هو تثبيت وكيل مضيف IBM Instana ومشاهدة نظام توقف العمليات التي تستنفد الذاكرة وهو يقوم بعمله الصارم. وهو يوضح لك أيضًا مقدار الذاكرة التي خصصتها العملية المتوقفة في أثناء الحدث، حتى تتمكن من فهم سبب تصنيف نظام توقف العمليات التي تستنفد الذاكرة لها على أنها "سيئة".

قد يستغرق تحديد كيفية وسبب توقف العملية أو سبب إيقاف نظام توقف العمليات التي تستنفد الذاكرة لها ساعات، إن لم يكن أيامًا، لمعرفة ذلك من دون وجود الأدوات المناسبة. بفضل برنامج كاشف الأعطال من IBM Instana، يتمكن المستخدمون الآن من معرفة السبب الأساسي وراء كل حالة توقف غير طبيعية للعمليات وكل عملية نجح نظام توقف العمليات التي تستنفد الذاكرة في إيقافها على الفور.

هل تريد معرفة سبب توقف الحاويات؟ لا توجد مشكلة. باستخدام نظام توقف العمليات التي تستنفد الذاكرة ببرنامج كاشف الأعطال من IBM Instana، ستعرف أنه ربما خصصت آلة جافا الافتراضية (JVM) لديك، التي تشغل دفعة وظائف مهمة للغاية، مواردًا أكثر مما كان مسموحًا به. أو ربما تحتاج إلى تحديد سبب وجود العديد من حالات فشل طلبات المعالج الأولي للنص التشعبي (PHP) أو سبب اختفاء قاعدة بياناتك. مرة أخرى، بفضل نظام توقف العمليات التي تستنفد الذاكرة ببرنامج كاشف الأعطال من IBM Instana، ستتمكن من الوصول الفوري إلى السبب الأساسي وراء هذه المشكلات.

للبدء في توفير وقتك ووقت فريق تطوير العمليات لديك المستغرق في استكشاف حالات توقف العمليات التي تستنفد الذاكرة ومعالجتها، ما عليك سوى تثبيت وكيل IBM Instana على نظام التشغيل Linux لديك اليوم. إذا لم يكن لديك بالفعل مثيل لمنصة IBM Instana، فيمكنك الاطلاع على كيفية عمل كاشف الأعطال من IBM Instana باستخدام كاشف حالات توقف العمليات التي تستنفد الذاكرة من خلال استخدام النسخة التجريبية المجانية.