كيفية ضبط حدود ذاكرة SAP HANA على خادم SUSE Linux Enterprise

يعمل نظام التحكم في ذاكرة SAP HANA على خادم SUSE Linux Enterprise Server بكفاءة عالية عند فصل مهمتين رئيسيتين: الأولى هي تحديد ما يمكن لـ HANA تخصيصه من الذاكرة، والثانية هي حماية أحمال عمل SAP عندما يكون مضيف Linux تحت ضغط على الذاكرة. يتولى SAP HANA المهمة الأولى باستخدام معلمات قاعدة البيانات مثل ` global_allocation_limitand` و`and` statement_memory_limit. أما المهمة الثانية، فتتولى حماية ذاكرة أحمال العمل من SUSE، القائمة على systemd/cgroup، باستخدام ` MemoryLowon` SAP.slice. تُكمل هاتان الآليتان بعضهما البعض، لكنهما ليستا قابلتين للتبادل.

يستند هذا الدليل إلى وثائق منصة SAP HANA 2.0 SPS 08 وإرشادات SUSE Linux Enterprise Server لتطبيقات SAP الحالية، والمتوفرة في أكتوبر 2026. قبل إجراء أي تغييرات على نظام الإنتاج، يُرجى التأكد من دعم إصدار HANA وحزمة خدمة SLES المُستخدمين. يُشير دليل تثبيت SAP إلى ملاحظة SAP رقم 2235581 لأنظمة التشغيل المدعومة: دليل تثبيت وتحديث خادم SAP HANA .

أي نوع من أنواع التحكم في الذاكرة يجب أن تستخدمه؟

تُقاس مستندات SAP global_allocation_limitبالميغابايت. عند ترك المعامل على قيمته الافتراضية 0، يحسب HANA حدًا تلقائيًا بناءً على الذاكرة الفعلية المتاحة؛ ويصف دليل إدارة SAP HANA 2.0 SPS 08 الصيغة الحالية بأنها 90% من أول 64 غيغابايت بالإضافة إلى 97% من كل غيغابايت إضافي، مع مراعاة خاصة للأنظمة الصغيرة جدًا. ويشير الدليل نفسه إلى أن تغيير المعامل لا يتطلب إعادة تشغيل النظام. راجع دليل إدارة SAP HANA 2.0 SPS 08 .

الخطوة 1: قياس ذاكرة المضيف قبل تحديد الحد

ابدأ على نظام SLES بفحص ذاكرة الوصول العشوائي الفعلية، والذاكرة المتاحة، ونشاط التبديل، وما إذا كانت عمليات SAP مجمعة بالفعل SAP.slice. هذا يمنحك الشروط الحدية قبل أن تقرر مقدار الذاكرة التي قد يستخدمها HANA.

free -h
grep MemTotal /proc/meminfo
systemctl status SAP.slice

لا تحدد حدًا لذاكرة HANA بمجرد طرح عدد ثابت من الجيجابايت من ذاكرة الوصول العشوائي (RAM) المثبتة. خصص ذاكرة لنواة لينكس، وبرنامج SAP Host Agent، وبرامج المراقبة، وأدوات النسخ الاحتياطي، ومكونات المجموعة، وأي خوادم تطبيقات موجودة على نفس الخادم. إذا كان ABAP وHANA يشتركان في نفس الخادم، فإن SAP تشترط صراحةً أن يتناسب حجم كلا النظامين مع الذاكرة الفعلية، وتوصي بتنسيق حد التخصيص العام لذاكرة HANA مع PHYS_MEMSIZEإعدادات ABAP: SAP Configuring Memory Settings .

الخطوة 2: قراءة معلمات ذاكرة HANA الموجودة

قبل إجراء أي تغييرات، سجّل الإعدادات الحالية. يمكنك الاطلاع عليها M_INIFILE_CONTENTSمن خلال مستكشف قاعدة بيانات SAP HANA، أو وحدة تحكم SQL في Cockpit، أو أي عميل SQL معتمد آخر.

SELECT FILE_NAME, SECTION, KEY, VALUE, LAYER_NAME
FROM M_INIFILE_CONTENTS
WHERE FILE_NAME = 'global.ini'
  AND SECTION = 'memorymanager'
  AND KEY IN ('global_allocation_limit',
              'statement_memory_limit',
              'statement_memory_limit_threshold')
ORDER BY KEY, LAYER_NAME;

تُعدّ الطبقة مهمة. في الأنظمة متعددة المستأجرين، قد تختلف نطاقات إعدادات مستوى النظام عن إعدادات مستوى قاعدة البيانات. لا تنسخ أي أمر من مثال حاوية واحدة قبل التحقق مما إذا كنت متصلاً بقاعدة بيانات النظام (SYSTEMDB) أو قاعدة بيانات مستأجر، وتحديد الطبقة التي تنوي تغييرها.

الخطوة 3: تحديد حد تخصيص HANA العالمي

يُستخدم هذا global_allocation_limitالخيار عندما يكون الهدف هو تحديد الحد الأقصى لتخصيص الذاكرة لـ HANA. قيمة مثل 180000 تعني 180,000 ميجابايت؛ وهي مجرد مثال، وليست توصية عامة. يجب تحديد الرقم الصحيح بناءً على حجم النظام، وسجل أحمال العمل، ومتطلبات التوافر العالي، والذاكرة التي يجب أن تظل متاحة لنظام التشغيل والعمليات الأخرى.

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('memorymanager', 'global_allocation_limit') = '180000'
WITH RECONFIGURE;

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

الخطوة الرابعة: تحديد ما إذا كان سيتم تقييد عبارات SQL الفردية

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

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('memorymanager', 'statement_memory_limit') = '5'
WITH RECONFIGURE;

المقايضة واضحة: فالحد الأقصى الصارم يحمي التزامن، ولكنه قد يُلغي تنفيذ عبارات تستهلك ذاكرة كبيرة، حتى وإن كانت ضرورية لعملك. تُشير SAP إلى أن بلوغ هذا الحد يُلغي تنفيذ العبارة، وقد يُنتج ملف تفريغ ذاكرة compositelimit_oom. لمزيد من التفاصيل، راجع قسم إدارة الذاكرة في دليل استكشاف الأخطاء وإصلاحها وتحليل الأداء لـ SAP HANA .

الخطوة 5: استخدم حدودًا خاصة بالمستخدم عندما تكون إحدى القيم العامة واسعة جدًا.

يُعدّ تحديد حدّ واحد للكشف المالي أمرًا بسيطًا، ولكنه يُعامل حساب ETL الليلي معاملة حساب مستخدم التقارير التفاعلية. يدعم SAP حدًا خاصًا بالمستخدم STATEMENT MEMORY LIMITله الأولوية على الحدّ العام للكشف المالي لهذا المستخدم.

ALTER USER REPORT_USER
SET PARAMETER STATEMENT MEMORY LIMIT = '2';

غالبًا ما يكون هذا النهج أفضل من خفض الحد الأقصى العام للجميع. على سبيل المثال، يمكنك تقييد التقارير المخصصة مع منح حسابات الدفعات أو الحسابات الإدارية هامشًا أكبر. أما الجانب السلبي فهو الحوكمة: إذ يجب توثيق الاستثناءات ومراجعتها وإزالتها عند انتفاء الحاجة إليها. كما توثق SAP القيود المفروضة على الاستعلامات عبر قواعد البيانات وبعض سيناريوهات XS Classic، حيث قد تكون فئات أحمال العمل أكثر ملاءمة. راجع قسم " إعداد معلمات المستخدم لأحمال العمل" في SAP .

الخطوة 6: حماية ذاكرة SAP على نظام SUSE باستخدام MemoryLow، وليس باستخدام حد أقصى ثابت ثانٍ.

في نظام SLES لتطبيقات SAP، توصي SUSE بحماية ذاكرة أحمال العمل من خلال systemd و cgroup v2. يتم وضع مثيلات SAP في SAP.slice، وتقول SUSE أنه بالنسبة لـ SAP HANA، يمكن استخدام حد التخصيص العالمي لـ HANA كأساس لـ MemoryLow.

sudo systemctl set-property SAP.slice MemoryLow=180G
systemctl show SAP.slice -p MemoryLow

MemoryLowيمثل هذا حدًا للحماية: ففي ظل ضغط الذاكرة، تحاول النواة حماية هذا المقدار لمجموعة التحكم (cgroup). وهو يختلف عن MemoryMaxمُخصِّص الذاكرة الخاص بنظام HANA، ولا يحل محله. هذا التمييز مهم لأن الحد الأقصى الصارم على مستوى نظام التشغيل قد يُسبب نمط فشل مختلفًا عن آليات التحكم الداخلية في تخصيص الذاكرة في HANA.

كما تحذر SUSE من ضبط MemoryLowالذاكرة الفعلية على قيمة قريبة من أو أعلى من إجمالي الذاكرة الفعلية، لأن خدمات النظام والبرامج الأخرى المثبتة تحتاج إلى ذاكرة أيضًا. تتوفر الإرشادات الحالية في SUSE Workload Memory Protection for SLES for SAP 15 SP6 .

الخطوة 7: تأكد من أنك لم تقم بإضافة غطاء cgroup متعارض عن طريق الخطأ

بعد ضبط الإعدادات MemoryLow، افحص خصائص systemd ذات الصلة. إذا لم يكن تصميمك يستخدم هذه الخصائص عمدًا MemoryHigh، MemoryMaxفتأكد من أنها لم تُضَف بواسطة إضافة محلية، أو نظام أتمتة، أو سياسة ضبط غير ذات صلة.

systemctl show SAP.slice | grep -E 'MemoryLow|MemoryHigh|MemoryMax'

يُعدّ هذا الأمر بالغ الأهمية، لا سيما على الخوادم المشتركة المُدارة بواسطة أتمتة التكوين. صُممت ميزة حماية ذاكرة أحمال العمل من SUSE لحماية SAP من ضغط أحمال العمل خارج مجموعة التحكم المحمية (cgroup)؛ إلا أنها لا تستطيع حماية أنظمة SAP أو مثيلات SAP من بعضها البعض عندما تشترك جميعها في نفس الذاكرة SAP.slice. وهذا يعني أن تحديد حجم الذاكرة على مستوى التطبيق يظل مهمًا حتى عند تفعيل حماية مجموعة التحكم.

الخطوة 8: تحقق من إعدادات HANA وراقب السلوك تحت ضغط العمل الفعلي

أعد الاستعلام M_INIFILE_CONTENTSبعد التغيير وتأكد من الطبقة والقيم المطلوبة. ثم راقب النظام أثناء الاستخدام العادي وأثناء ذروة العمل. لا يُعتبر التكوين ناجحًا لمجرد أن عبارة SQL نُفذت بدون خطأ.

SELECT FILE_NAME, SECTION, KEY, VALUE
FROM M_INIFILE_CONTENTS
WHERE FILE_NAME = 'global.ini'
  AND SECTION = 'memorymanager'
ORDER BY KEY;

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

اختيار سياسة لأنماط النشر الشائعة

مضيف HANA مخصص للإنتاج

فضّل استخدام نظام إدارة تخصيص الذاكرة العالمي الخاص بـ HANA، واترك مساحة كافية لنظام التشغيل بناءً على حجم SAP. أضف حدًا لعدد العبارات فقط إذا أظهر سجل أحمال العمل أن عبارات معينة تُهدد التزامن. استخدم SUSE MemoryLowعندما تريد حماية أحمال عمل SAP من ضغط الذاكرة غير التابع لـ SAP على المضيف.

خادم تطبيقات HANA بالإضافة إلى خادم التطبيقات على مضيف واحد

استخدم ميزانيات محددة بوضوح. نسّق بين HANA global_allocation_limitوإعدادات ذاكرة خادم التطبيقات، مثل PHYS_MEMSIZE... هذا أقل مرونة من السماح لكلا الجانبين بالنمو بحرية، ولكنه يقلل من خطر استهلاك أحد المكونات للذاكرة التي يحتاجها الآخر.

تحليلات مختلطة مع استعلامات مخصصة غير متوقعة

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

أنظمة HANA عالية التوفر أو أنظمة HANA المجمعة

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

أخطاء شائعة يجب تجنبها

• يتم التعامل مع قيمة MemoryLow كحد أقصى ثابت. فهي تحمي الذاكرة؛ ولا تحد من قدرة HANA على الوصول إلى تلك القيمة.
• يتم تحديد قيمة MemoryMax لأنها تبدو مكافئة لحدود تخصيص الذاكرة في HANA. لكن المعنى مختلف، وقد يتعارض الحد الأقصى الثابت لنظام التشغيل مع إدارة الذاكرة الخاصة بـ HANA.
• استخدام نفس حدّ البيانات لكل مستخدم دون وجود دليل على حجم العمل. قد تختلف احتياجات الذاكرة المشروعة لاستعلام إعداد التقارير عن احتياجات الذاكرة المشروعة لعملية الصيانة اختلافًا كبيرًا.
• تجاهل طبقة التكوين في أنظمة MDC. تأكد مما إذا كنت تقوم بتغيير نطاق النظام أو المضيف أو قاعدة البيانات، وما هي قاعدة البيانات التي تستهدفها جلسة SQL الخاصة بك.
• نسخ الأرقام النموذجية إلى بيئة الإنتاج. القيمتان 180 جيجابايت و5 جيجابايت الموضحتان هنا هما قيم توضيحية، وليستا توصيات لتحديد الحجم.
• لا يترك ذلك أي هامش لشركة SUSE والخدمات الداعمة لها. ولا يُعدّ نظام HANA المستهلك الوحيد لذاكرة الوصول العشوائي الفعلية.

التوصية النهائية

استخدم global_allocation_limitحدود ذاكرة SAP HANA كحد أقصى أساسي، ولا تُضِف حدودًا إضافية statement_memory_limitإلا عند الحاجة للتحكم في مخاطر الاستعلامات الفردية، واستخدم سياسات خاصة بالمستخدم أو بفئة أحمال العمل عندما تتطلب أحمال العمل المختلفة حدودًا مختلفة. على خادم SUSE Linux Enterprise Server لتطبيقات SAP، استخدم هذه الحدود SAP.slice MemoryLowلحماية أحمال عمل SAP من ضغط مستوى المضيف بدلاً من محاولة تكرار حد HANA باستخدام حد أقصى ثابت لمجموعة التحكم (cgroup).

تتمثل أهم المفاضلات في الموازنة بين أقصى سعة تخزين مؤقت/استعلام لـ HANA ومساحة كافية على المضيف للحفاظ على سلامة نظام التشغيل والخدمات الموجودة في نفس الموقع. اعتمد الأرقام النهائية على حجم SAP وذروات الإنتاج الملحوظة، ثم تحقق من كل من HANA وSLES بعد التغيير.