كيفية الحد من استخدام وحدة المعالجة المركزية وذاكرة الوصول العشوائي لعملية ما باستخدام مجموعات التحكم (Cgroups) على نظام أوبونتو

في أوبونتو، الطريقة الأكثر أمانًا لتقييد حجم العمل باستخدام مجموعات التحكم (cgroups) هي السماح لـ systemd بإنشاء وإدارة مجموعة التحكم الخاصة بها. استخدم systemd-runهذه الطريقة مع الأوامر التي تُشغّلها حاليًا، أو قم بتهيئة خدمة systemd عندما يكون من الضروري استمرار الحد بعد إعادة التشغيل. حدد CPUQuota=حدًا أقصى صارمًا لوقت وحدة المعالجة المركزية، واختر بين خيارين MemoryHigh=للتحكم في الضغط MemoryMax=وحدود الذاكرة الصارمة. تُطبّق هذه الحدود على الوحدة وعملياتها الفرعية معًا.

مجموعة التحكم (cgroup) هي آلية في نواة لينكس تُنظّم العمليات بحيث يتمكن النظام من حساب استخدام الموارد والتحكم فيه. يقوم نظام systemd في أوبونتو تلقائيًا بوضع الخدمات في مجموعات تحكم، لذا لا يحتاج معظم المستخدمين إلى إنشاء مجلدات /sys/fs/cgroupيدويًا. تستخدم الأمثلة أدناه واجهة التحكم في الموارد الخاصة بنظام systemd، ويجب التحقق منها ومطابقتها مع إصدار systemd المُثبّت على إصدار أوبونتو الخاص بك.

اختر عنصر التحكم الذي يناسب المشكلة

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

تحقق من نظام أوبونتو قبل تحديد الحدود

تحقق أولاً من توفر systemd وما إذا كان نظام ملفات cgroup موحدًا الإصدار 2:

systemctl --version
stat -fc %T /sys/fs/cgroup

تشير نتيجة cgroup2fsالأمر الثاني إلى نظام ملفات cgroup الموحد الإصدار الثاني. قد تختلف إصدارات أوبونتو والأنظمة المُخصصة، لذا لا تفترض أن جميع الأجهزة لها نفس التسلسل الهرمي أو ميزات systemd. يمكنك أيضًا فحص إصدار systemd الحالي باستخدام الأمر الأول. إذا لم يكن تركيب cgroup هو الإصدار الثاني، فقد تختلف بعض خصائص الموارد أو سلوك وحدة التحكم؛ راجع صفحة دليل أوبونتو للإصدار المُثبّت قبل نسخ أي تكوين.

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

قم بتقييد أمر أنت على وشك تنفيذه

لتشغيل أمر في جلسة المستخدم الخاصة بك، قم بتشغيله في نطاق مؤقت باستخدام systemd-run --user --scope. على سبيل المثال:

systemd-run --user --scope --unit=worker-capped \
  -p CPUQuota=50% \
  -p MemoryHigh=700M \
  -p MemoryMax=900M \
  -- python3 /opt/worker.py

استبدل أمر بايثون بالبرنامج الذي تحتاج لتشغيله فعليًا. يمنح هذا المثال مجموعة التحكم (cgroup) عرض نطاق ترددي أقصى لوحدة المعالجة المركزية يعادل نصف وحدة معالجة مركزية واحدة، ويبدأ معالجة ضغط الذاكرة عند حوالي 700 ميجابايت، ويحدد حدًا أقصى للذاكرة الصلبة يبلغ 900 ميجابايت. تستخدم قيم الذاكرة وحدات النظام الأساسية 1024. 100%تمثل الحصة ما يصل إلى وقت وحدة معالجة مركزية واحدة؛ 200%ويمكن استخدام ما يصل إلى وقت وحدتي معالجة مركزية عند توفرهما. لا تعني هذه الحصة نسبة مئوية من جميع أنوية المعالج في الحاسوب.

يُنفَّذ الأمر في المقدمة لأن هذا نطاق. عند انتهائه، تختفي الوحدة المؤقتة. قم بإزالته --userفقط إذا كنت تنوي استخدام مدير النظام ولديك الصلاحيات اللازمة؛ بالنسبة لوحدة مؤقتة على مستوى النظام، شغِّل الأمر مع sudoخيارات الأمر المناسبة. قد تُرفض إعدادات الموارد إذا كان المدير أو وحدة تحكم مجموعة التحكم لا يدعمها.

قم بتحديد حدود خدمة systemd المستمرة

بالنسبة لخدمة مثل هذه worker.service، أنشئ ملفًا جاهزًا بدلًا من تعديل ملف وحدة المورّد. شغّل البرنامج sudo systemctl edit worker.serviceوأضف ما يلي:

[Service]
CPUQuota=50%
MemoryHigh=700M
MemoryMax=900M

احفظ ملف الإضافة، ثم أعد تحميل تعريفات وحدات systemd وأعد تشغيل الخدمة حتى تبدأ العملية وفقًا للسياسة المعدلة:

sudo systemctl daemon-reload
sudo systemctl restart worker.service

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

تحقق من الوحدة وراقب سلوكها

بالنسبة لنطاق البيانات العابرة، تحقق من حالته باستخدام اسم الوحدة الذي قدمته:

systemctl --user status worker-capped.scope
systemd-cgtop

بالنسبة لخدمة النظام، احذفها --userمن أمر الحالة. يعرض عرض الحالة وجود الوحدة ونشاطها، systemd-cgtopويُظهر استخدام الموارد المباشر من قِبل مجموعة التحكم. لفحص الخصائص المُكوّنة، استعلم عن الوحدة مباشرةً، على سبيل المثال:

systemctl --user show worker-capped.scope \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax

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

ماذا لو كانت العملية قيد التشغيل بالفعل؟

systemd-runيبدأ هذا الأمر عملية جديدة داخل وحدة جديدة؛ فهو لا يأخذ مُعرّف عملية موجودًا عشوائيًا وينقله إلى هذا النطاق. إذا كانت العملية تابعة لخدمة systemd، فقم بتطبيق الإعدادات على تلك الخدمة باستخدام ملف إضافي، أو استخدم الأمر ` sudo systemctl set-property --runtime worker.service CPUQuota=50% MemoryHigh=700M MemoryMax=900M. هذا --runtimeالنموذج مؤقت ولا يحل محل إعدادات الخدمة الدائمة.

إذا كانت العملية برنامجًا عاديًا في جلسة سطح المكتب، فإن الطريقة الآمنة والبسيطة عادةً ما تكون إيقافها وإعادة تشغيلها systemd-run. قد يؤثر تطبيق خاصية على نطاق أوسع، مثل نطاق المستخدم بالكامل، على العديد من التطبيقات غير ذات الصلة. يتطلب نقل عملية عن طريق كتابة معرّفها (PID) في ملف cgroup التحكم في التسلسل الهرمي المفوض ذي الصلة، ويجب أن يلتزم بقواعد وضع العمليات في cgroup v2؛ لا تكتب في الدلائل التي يديرها systemd بشكل عشوائي.

كيفية اختيار سياسة وحدة المعالجة المركزية والذاكرة

• هل تحتاج إلى حد أقصى ثابت لاستهلاك وحدة المعالجة المركزية؟ اختر القيمة المناسبة CPUQuota=. القيم الأقل تقلل من ذروة استهلاك وحدة المعالجة المركزية ولكنها قد تبطئ عملية الإكمال وتزيد من وقت الانتظار.
• هل تحتاج إلى أولوية أقل فقط؟ فكّر في استخدام CPUWeight=خيار "الوزن" بدلاً من "الحصة". فهو يوزّع موارد وحدة المعالجة المركزية بشكل نسبي عند التنافس عليها؛ ولا يحجز نسبة مئوية ثابتة أو يمنع استخدام وحدة المعالجة المركزية الخاملة.
• هل تحتاج إلى ضغط على الذاكرة دون توقف فوري؟ اضبطه MemoryHigh=كعتبة الضغط الرئيسية وراقب زمن الاستجابة وسلوك الاستعادة.
• هل تحتاج إلى حدود احتواء نهائية؟ أضف MemoryMax=هامشًا كافيًا لاستيعاب الذروات الطبيعية. كن مستعدًا لسلوك نفاد الذاكرة عندما يتعذر الالتزام بالحدود.
• هل تستخدم حاوية بالفعل؟ فضل استخدام علامات وحدة المعالجة المركزية والذاكرة المدعومة من قبل مدير الحاويات، والتي تقوم بتكوين مجموعات التحكم (cgroups) لتلك الحاوية وتناسب دورة حياتها.

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

مراجع

• وثائق أوبونتو: التحكم في موارد cgroups و systemd
• صفحة دليل أوبونتو: systemd-run
• صفحة دليل أوبونتو: systemd.resource-control
• وثائق نواة لينكس: مجموعة التحكم الإصدار 2