لينكس / المتقدم: الحدود والأمان والاسترداد / الدرس 15
قراءة سياسة cgroup وحدود العمل
استخدم مفاهيم cgroup v2 لفهم تنظيم الموارد وحدودها وتفويضها وإنهاء العمل دون ضبط المضيف.
في هذه الصفحة
أهداف الدرس
- تمييز cgroups من فضاءات الأسماء وحدود العمليات التقليدية.
- تفسير حماية الذاكرة والحدود الصلبة وعدادات الأحداث.
- قراءة سياسة موارد systemd ضمن تصميم الخدمة.
تنظم cgroups العمليات هرمياً
يوفر cgroup v2 هرمية موحدة تنظم العمليات وتعرض متحكمات لموارد مختارة. تنتمي العملية إلى مجموعة ويرث الأبناء العضوية عند الإنشاء عادة. لا ينقل تحريك الأب لاحقاً جميع نسله القائم تلقائياً. تضبط فضاءات الأسماء العرض وتضبط cgroups التنظيم والتحكم. تبقى حدود العملية مفيدة لكنها لا تستبدل حد مجموعة يشمل نسل الخدمة. أكد استخدام v2 أو النظام الأقدم قبل تفسير الملفات لاختلاف المسارات والدلالات.
القراءة قبل كتابة ملفات المتحكم
يصف /proc/self/cgroup عضوية العملية كما تظهر من سياقها. في تركيب v2 المعتاد يسرد cgroup.controllers المتحكمات المتاحة للأبناء، ويصف cgroup.subtree_control المفعّل للنسل. لا يعني التوفر تطبيق حد. وقد ترى الحاوية شجرة مفوضة لا جذر المضيف. لا تكتب مباشرة في هرمية يديرها مدير لمجرد قابلية الملفات للكتابة؛ فقد تتعارض مع المحاسبة والعمر والتفويض. استخدم واجهة المدير المدعومة للسياسة.
cat /proc/self/cgroup
findmnt -t cgroup2
cat /sys/fs/cgroup/cgroup.controllersيفترض المسار الأخير تركيب v2 المعتاد. تعتمد محتوياته على النواة والتفويض. تقرأ الأوامر الحالة ولا تفعل متحكمات أو تنقل عمليات.
تختلف الحماية والضغط والحدود
يعرض memory.current الاستخدام المحسوب للمجموعة ونسلها. ينشئ memory.high حداً للضغط والاسترداد لا سقف تخصيص مطلقاً. أما memory.max فحد صلب قد يسبب إجراء نفاد ذاكرة عند عجز الاسترداد. ويعبر memory.low وmemory.min عن حماية بضمانات وقيود هرمية مختلفة. فسّر العدادات وسياسة الأسلاف معاً؛ فقد يتأثر الابن بحد محيط رغم عدم تحديده محلياً. لا تصف كل إنهاء بأنه OOM دون دليل.
التعبير عن سياسة العمل عبر المدير
تربط إعدادات موارد systemd المقاصد بضوابط النواة عند الدعم. يعبر MemoryHigh= عن ضغط طبيعي وMemoryMax= عن حد أخير وTasksMax= عن عدد المهام شاملاً الخيوط. وCPUWeight= وزن نسبي بين الأشقاء، بينما CPUQuota= نوع آخر من السقف. هذه مفاهيم سياسة وليست وصفة تحسين أداء. اخترها وفق متطلبات التطبيق والفشل وافحص التوافق مع systemd والنواة. يجب أن تترك سعة للبدء والاسترداد المشروعين.
systemctl show example-worker.service -p ControlGroup -p MemoryHigh -p MemoryMax -p TasksMax
systemctl cat example-worker.serviceافحص في صورة مؤقتة تحوي الوحدة الافتراضية الخصائص الفعلية ومصدر الإعداد. لا يثبت المثال إضافة أو يغير حدوداً أو يعيد الخدمة.
التفويض حد للمسؤولية
تسمح الشجرة المفوضة لمدير موثوق بتنظيم النسل ضمن حدود ممنوحة ولا تمنحه الهرمية كلها. اجعل لكل جزء مالكاً واضحاً. التقط عند الحادث العضوية وحدود الأسلاف والأحداث ونتيجة الوحدة والسجل قبل التغيير. قد يفسر OOM الإنهاء لا سبب ارتفاع الطلب؛ تابع إلى الحمل أو التسرب. ينبغي للاسترداد إعادة السلوك المفيد مع حفظ الأدلة، وللتغيير الدائم فحص مختبري قابل للتكرار.
الأخطاء الشائعة وإصلاحها
اعتبار memory.high سقفاً صلباً
- لماذا يحدث؟
- اختلط ضبط الضغط بحد التخصيص الصلب.
- كيف تصلحه؟
- اقرأ memory.max والأحداث منفصلين.
- كيف تتجنب تكراره؟
- وثق إن كان الإعداد يحمي أو يضغط أو يحد.
يبدو الابن بلا حد لكنه مقيد
- لماذا يحدث؟
- أُهمل حد أحد الأسلاف.
- كيف تصلحه؟
- افحص الهرمية الفعلية وخصائص المدير.
- كيف تتجنب تكراره؟
- راجع السياسة على امتداد الأسلاف.
تعارض الكتابة المباشرة مع سياسة systemd
- لماذا يحدث؟
- غير مديران هرمية الموارد نفسها.
- كيف تصلحه؟
- استخدم واجهة سياسة المالك المدعومة في المختبر.
- كيف تتجنب تكراره؟
- حدد التفويض والملكية قبل الأتمتة.
اختبر فهمك
1. يموت عامل وتبلغ وحدته نتيجة مرتبطة بـ OOM. ما الذي يبقى إثباته؟
اعرض الحل المشروح
اربط الزمن والأحداث والعضوية وحدود الأسلاف لتحديد الحد المعني. ثم حدد سبب تجاوز الطلب للسياسة وكيف عالج التطبيق الضغط. لا يثبت رفع الحد وحده السبب أو يزيله.
2. لماذا يؤثر TasksMax في برنامج متعدد الخيوط ذي عمليات قليلة؟
اعرض الحل المشروح
يشمل الحد الخيوط، فقد تستهلك عملية واحدة خانات كثيرة. افحص نموذج المهام والسياسة المحيطة. قد يقلل تقدير يعتمد قائمة عمليات قصيرة من السعة المطلوبة.
أهم ما تعلمته
- اقرأ الأسلاف الفعليين لا الملف المحلي وحده.
- استخدم سياسة موارد مُدارة واربط الأحداث بالأسباب.