نام (NAME)

systemd-oomd.service, systemd-oomd - کشنده کمبود حافظه (OOM) در فضای کاربری

خلاصه دستور (SYNOPSIS)

systemd-oomd.service

/usr/lib/systemd/systemd-oomd

توضیحات (DESCRIPTION)

systemd-oomd یک سرویس سیستمی است که از cgroups-v2 و اطلاعات توقف ناشی از فشار (PSI) برای نظارت و انجام اقدامات اصلاحی پیش از وقوع کمبود حافظه (OOM) در فضای هسته استفاده می‌کند.

شما می‌توانید با تنظیم ManagedOOMSwap= و ManagedOOMMemoryPressure= در پیکربندی واحد، نظارت و اقدامات را بر روی واحدها فعال کنید؛ ببینید systemd.resource-control(5). systemd-oomd هنگام راه‌اندازی، اطلاعات مربوط به چنین واحدهایی را از systemd(1) دریافت کرده و تغییرات بعدی آن‌ها را زیر نظر می‌گیرد.

گروه‌های کنترلی (cgroups) واحدهایی که ManagedOOMSwap= یا ManagedOOMMemoryPressure= در آن‌ها روی kill تنظیم شده باشد، نظارت خواهند شد. systemd-oomd به‌طور دوره‌ای آمارهای PSI را برای سیستم و آن cgroupها بررسی می‌کند تا زمان اقدام را تعیین نماید. اگر از محدودیت‌های پیکربندی‌شده فراتر رود، systemd-oomd یک cgroup را برای خاتمه انتخاب کرده و سیگنال SIGKILL را به تمام فرآیندهای درون آن ارسال می‌کند. توجه داشته باشید که تنها cgroupهای نواده (فرزند) نامزدهای واجد شرایط برای خاتمه هستند؛ واحدی که ویژگی آن روی kill تنظیم شده است خود یک نامزد نیست (مگر اینکه یکی از نیاکان آن ویژگی خود را روی kill تنظیم کرده باشد). همچنین فقط cgroupهای برگ (leaf) و cgroupهایی با memory.oom.group تنظیم‌شده روی 1 نامزدهای واجد شرایط هستند؛ ببینید OOMPolicy= در systemd.service(5).

از oomctl(1) می‌توان برای فهرست کردن cgroupهای تحت نظارت و اطلاعات فشار استفاده کرد.

برای اطلاعات بیشتر درباره پیکربندی این سرویس، oomd.conf(5) را ببینید.

برای شرح API مربوط به D-Bus، org.freedesktop.oom1(5) و org.freedesktop.LogControl1(5) را ببینید.

نیازمندی‌های سیستم و پیکربندی (SYSTEM REQUIREMENTS AND CONFIGURATION)

سیستم باید در حال اجرای systemd با سلسله‌مراتب یکپارچه کامل cgroup باشد تا قابلیت‌های مورد انتظار cgroups-v2 فراهم شوند. علاوه بر این، محاسبه مصرف حافظه (memory accounting) باید برای تمام واحدهای تحت نظارت systemd-oomd فعال باشد. ساده‌ترین راه برای فعال‌سازی محاسبه حافظه، اطمینان از تنظیم مقدار DefaultMemoryAccounting= روی true در systemd-system.conf(5) است.

هسته باید با پشتیبانی از PSI کامپایل شده باشد. این قابلیت در لینوکس 4.20 و بالاتر در دسترس است.

اکیداً توصیه می‌شود که حافظه مبادله (swap) روی سیستم فعال باشد تا systemd-oomd به‌طور بهینه عمل کند. با فعال بودن swap، سیستم زمان کافی را برای جابه‌جایی صفحات حافظه (swapping pages) صرف می‌کند تا به systemd-oomd امکان واکنش داده شود. بدون swap، سیستم بسیار سریع‌تر وارد وضعیت قفل زنده (livelock) می‌شود و ممکن است مانع از پاسخگویی systemd-oomd در یک بازه زمانی معقول گردد. برای جزئیات بیشتر درباره swap به "In defence of swap: common misconceptions"[1] مراجعه کنید. هرگونه اقدام مبتنی بر swap در سیستم‌های بدون swap نادیده گرفته خواهد شد. اگرچه systemd-oomd می‌تواند اقدامات مبتنی بر فشار را در چنین سیستمی انجام دهد، افزایش فشار ناگهانی‌تر خواهد بود و ممکن است برای دستیابی به آستانه‌ها و رفتار مطلوب نیاز به تنظیمات بیشتری داشته باشد.

توجه داشته باشید که اگر قصد دارید نظارت و اقدامات را بر روی user.slice، user-$UID.slice یا cgroupهای نیاکان آن‌ها فعال کنید، اکیداً توصیه می‌شود که برنامه‌های شما توسط مدیر کاربر systemd مدیریت شوند تا از اجرای فرآیندهای بیش از حد در یک محدوده نشست (session scope) یکسان جلوگیری شود (و بدین ترتیب از وضعیتی که در آن وظایف با مصرف حافظه بالا باعث می‌شوند systemd-oomd تمام موارد زیر مجموعه آن cgroup را خاتمه دهد، پیشگیری گردد). اگر از یک محیط رومیزی مانند GNOME یا KDE استفاده می‌کنید، این محیط‌ها پیشاپیش بسیاری از اجزای نشست را با مدیر کاربر systemd اجرا می‌کنند.

توصیه‌های استفاده (USAGE RECOMMENDATIONS)

ManagedOOMSwap= با مقادیر swap در سطح کل سیستم کار می‌کند، بنابراین تنظیم آن روی برش ریشه (root slice) -.slice، و مجاز دانستن تمام cgroupهای فرزند به عنوان نامزدهای واجد شرایط، بیشترین توجیه را دارد.

ManagedOOMMemoryPressure= معمولاً روی cgroupهای زیر برش ریشه عملکرد بهتری دارد. برای واحدهایی که فرآیندهای آن‌ها حساسیت کمتری به تأخیر دارند (مانند system.slice)، یک حد بالاتر مانند مقدار پیش‌فرض 60% ممکن است قابل قبول باشد، زیرا این فرآیندها معمولاً می‌توانند کندی‌های ناشی از کمبود حافظه را بدون پیامدهای جدی پشت سر بگذارند. با این حال، مواردی مانند user@$UID.service ممکن است به مقدار بسیار کمتری مانند 40% نیاز داشته باشند.