| OOMD.CONF(5) | oomd.conf | OOMD.CONF(5) |
نام (NAME)
oomd.conf, oomd.conf.d - فایلهای پیکربندی مدیریت کمبود حافظه سیستمدی (systemd-oomd)
خلاصه دستور (SYNOPSIS)
توضیحات (DESCRIPTION)
این فایلها پارامترهای مختلف قاتل کمبود حافظه (OOM) فضای کاربری در systemd(1) یعنی systemd-oomd.service(8) را پیکربندی میکنند. برای توضیحات کلی در مورد ساختار نحوی به systemd.syntax(7) مراجعه کنید.
دایرکتوریهای پیکربندی و اولویت (CONFIGURATION DIRECTORIES AND PRECEDENCE)
پیکربندی پیشفرض در زمان کامپایل تعیین میشود، بنابراین پیکربندی تنها زمانی مورد نیاز است که انحراف از آن مقادیر پیشفرض لازم باشد. فایل پیکربندی اصلی از یکی از دایرکتوریهای فهرستشده به ترتیب اولویت بارگذاری میشود و تنها اولین فایل یافتشده استفاده میگردد: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [1], /usr/lib/systemd/. نسخه ارائهشده توسط توزیعکننده (vendor) شامل ورودیهای کامنتشدهای است که مقادیر پیشفرض را به عنوان راهنمای مدیر سیستم نشان میدهد. بازنویسیهای محلی را نیز میتوان با ایجاد فایلهای تکمیلی (drop-in) مطابق توضیحات زیر انجام داد. فایل پیکربندی اصلی را نیز میتوان برای این منظور ویرایش کرد (یا یک رونوشت در /etc/ اگر در /usr/ عرضه شده باشد)، با این حال استفاده از فایلهای تکمیلی (drop-in) برای پیکربندی محلی نسبت به تغییر دادن فایل پیکربندی اصلی توصیه میشود.
علاوه بر فایل پیکربندی اصلی، قطعهکدهای پیکربندی تکمیلی (drop-in) از مسیرهای زیر خوانده میشوند: /usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/, و /etc/systemd/*.conf.d/. این فایلهای تکمیلی اولویت بالاتری دارند و فایل پیکربندی اصلی را بازنویسی (override) میکنند. فایلها در زیردایرکتوریهای پیکربندی *.conf.d/ صرفنظر از اینکه در کدامیک از زیردایرکتوریها قرار داشته باشند، بر اساس نام فایل خود به ترتیب واژهنگاری (lexicographic) مرتب میشوند. هنگامی که چندین فایل یک گزینه مشابه را تعیین میکنند، برای گزینههایی که تنها یک مقدار واحد را میپذیرند، ورودی موجود در فایلی که نام آن در آخر مرتب شده است اولویت دارد؛ و برای گزینههایی که فهرستی از مقادیر را میپذیرند، ورودیها به همان ترتیبی که در فایلهای مرتبشده ظاهر میشوند جمعآوری میگردند.
هنگامی که بستهها نیاز به سفارشیسازی پیکربندی داشته باشند، میتوانند فایلهای تکمیلی (drop-in) را در /usr/ نصب کنند. فایلهای موجود در /etc/ برای مدیر سیستم محلی رزرو شدهاند، که میتواند از این منطق برای بازنویسی فایلهای پیکربندی نصبشده توسط بستههای توزیعکننده استفاده کند. برای بازنویسی قطعات تکمیلی بسته باید از فایلهای تکمیلی استفاده شود، زیرا فایل پیکربندی اصلی اولویت پایینتری دارد. توصیه میشود نام تمام فایلها در این زیردایرکتوریها با یک عدد دورقمی و یک خط تیره پیشوندگذاری شود تا ترتیببندی آنها سادهتر گردد. این کار همچنین مفهومی از اولویتهای فایلهای تکمیلی را تعریف میکند تا به توزیعکنندگان سیستمعامل اجازه دهد فایلهای تکمیلی را در یک محدوده مشخص پایینتر از محدوده مورد استفاده کاربران عرضه کنند. این امر خطر بازنویسی تصادفی فایلهای تکمیلی تعریفشده توسط کاربران را توسط فایلهای تکمیلی بستهها کاهش میدهد. توصیه میشود از محدوده 10-40 برای فایلهای تکمیلی در /usr/ و از محدوده 60-90 برای فایلهای تکمیلی در /etc/ و /run/ استفاده شود، تا اطمینان حاصل گردد که فایلهای تکمیلی محلی و گذرا بر فایلهای تکمیلی ارائهشده توسط توزیعکننده سیستمعامل اولویت دارند.
برای غیرفعال کردن یک فایل پیکربندی ارائهشده توسط توزیعکننده، روش توصیهشده قرار دادن یک پیوند نمادین (symlink) به /dev/null در دایرکتوری پیکربندی در /etc/ با همان نام فایل پیکربندی توزیعکننده است.
رویداد پیش از کشتن (PREKILL EVENT)
systemd-oomd از اطلاعرسانی به مؤلفههای خارجی پیش از کشتن یک گروه کنترلی پشتیبانی میکند. این کار با ارسال یک اعلان از طریق varlink به تمامی سوکتهای یافتشده در پوشه /run/systemd/oomd.prekill.hook/ انجام میشود. هر سوکت باید رابط io.systemd.oom.Prekill را پیادهسازی کند. این اعلان حاوی مسیر گروه کنترلی است تا قلاب (hook) بتواند تشخیص دهد کدام گروه کنترلی در حال کشته شدن است. این امر به مؤلفههای خارجی اجازه میدهد پیش از خاتمه گروه کنترلی، هرگونه پاکسازی یا ثبت گزارش لازم را انجام دهند. این قلاب به عنوان راهی برای جلوگیری از کشته شدن در نظر گرفته نشده است، بلکه به عنوان یک سازوکار اعلان عمل میکند. توجه داشته باشید که این یک گزینه نیازمند دسترسی ویژه (privileged) است، زیرا حتی در صورت داشتن مهلت زمانی، همگام بوده و کشتن را به تاخیر میاندازد، بنابراین با احتیاط استفاده شود. سازوکار معمولاً ارجح برای پردازش فشار حافظه، عمل بر اساس توصیههای سند Resource Pressure Handling[2] است که بدون نیاز به دسترسی ویژه و ناهمگام است و کشتن را به تاخیر نمیاندازد.
مجموعه قوانین OOM (OOM RULESETS)
systemd-oomd از مجموعه قوانین سفارشی پشتیبانی میکند که شرایط و اقداماتی را برای مدیریت OOM بر مبنای هر واحد (per-unit) تعریف میکنند. فایلهای مجموعه قوانین از پسوند .oomrule استفاده میکنند و از مسیرهای زیر بارگذاری میشوند: /etc/systemd/oomd/rules.d/, /run/systemd/oomd/rules.d/, /usr/local/lib/systemd/oomd/rules.d/, و /usr/lib/systemd/oomd/rules.d/. واحدها از طریق تنظیم OOMRules= در systemd.resource-control(5) از این مجموعه قوانین استفاده میکنند، که فهرستی جداشده با فاصله از نامهای مجموعه قوانین (نام فایل بدون پسوند .oomrule) را میپذیرد.
هر فایل مجموعه قوانین شامل یک بخش "[Rule]" با گزینههای زیر است. حداقل یکی از گزینههای MemoryPressureAbove= یا SwapUsageMax= باید پیکربندی شود؛ مجموعه قوانین بدون شرط نادیده گرفته میشوند. اگر هر دو تنظیم شده باشند، شرایط با عملگر AND ترکیب میشوند، یعنی اقدام تنها زمانی فعال میشود که هر دو آستانه به طور همزمان فراتر رفته باشند.
MemoryPressureAbove=
در نگارش 261 اضافه شد.
SwapUsageMax=
در نگارش 261 اضافه شد.
Action=
در نگارش 261 اضافه شد.
LastingSec=
در نگارش 261 اضافه شد.
گزینهها (OPTIONS)
گزینههای زیر در بخش [OOM] در دسترس هستند:
SwapUsedLimit=
در نگارش 247 اضافه شد.
DefaultMemoryPressureLimit=
در نگارش 247 اضافه شد.
DefaultMemoryPressureDurationSec=
در نگارش 248 اضافه شد.
PrekillHookTimeoutSec=
در نگارش 260 اضافه شد.
همچنین ببینید (SEE ALSO)
systemd(1), systemd.resource-control(5), systemd-oomd.service(8), oomctl(1)
نکات (NOTES)
- 1.
- 💣💥🧨💥💥💣 لطفاً توجه داشته باشید که این فایلهای پیکربندی باید همواره در دسترس باشند. اگر /usr/local/ یک پارتیشن جداگانه باشد، ممکن است در مراحل اولیه بوت در دسترس نباشد و نباید برای پیکربندی استفاده شود.
- 2.
- Resource Pressure Handling
| systemd 261.2 |