Batasi Memori dan CPU Proses dengan systemd

Batasi memori dan CPU proses dengan drop-in systemd

Anda dapat membatasi memori dan CPU proses pada Linux VPS dengan menambahkan beberapa baris ke unit yang menjalankan proses tersebut. MemoryMax= adalah batas maksimum memori. CPUQuota= adalah batas maksimum waktu prosesor. Keduanya diterapkan oleh cgroup v2 (control groups, version 2), yaitu fitur kernel yang sudah digunakan systemd untuk mencatat penggunaan setiap service pada server.

sudo systemctl edit myapp.service

Perintah tersebut membuka file drop-in yang berisi petunjuk dalam komentar. Tambahkan baris berikut di atas petunjuk tersebut:

[Service]
MemoryHigh=512M
MemoryMax=768M
MemorySwapMax=0
CPUQuota=80%
TasksMax=128

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl show myapp.service -p MemoryHigh -p MemoryMax -p CPUQuotaPerSecUSec -p TasksMax

systemctl show harus menampilkan kembali angka Anda dalam satuan yang digunakan kernel: MemoryMax=805306368 dan CPUQuotaPerSecUSec=800ms. Jika hasilnya MemoryMax=infinity, drop-in belum dimuat. Periksa apakah file berada di /etc/systemd/system/myapp.service.d/override.conf dan diawali header [Service], karena baris pengaturan tanpa section sebelumnya membuat systemd mencatat Assignment outside of section. Ignoring. dan menjalankan service tanpa batas sama sekali.

Bagian selanjutnya dalam panduan ini menjelaskan cara memilih angka tersebut dan masalah yang masih dapat terjadi setelah batas diterapkan.

Mengapa proses yang tidak terkendali membekukan VPS meskipun tidak pernah memenuhi memorinya

Proses yang mencapai batas memori keras akan berhenti dalam waktu sekitar satu detik, lalu service dimulai ulang. Ini adalah kondisi yang baik. Kondisi buruk terjadi ketika tidak ada yang berhenti: server merespons ping, SSH menerima koneksi, tetapi prompt shell tidak pernah muncul. Mesin tetap aktif dan sibuk, tetapi tidak ada pekerjaan yang bermanfaat.

Berikut mekanismenya karena hal ini tidak selalu jelas. Saat memori bebas menipis, kernel mengambil kembali page, alih-alih memberikan page baru. Page yang paling murah untuk diambil kembali adalah page yang didukung file, sedangkan page cache menyimpan kode executable dari semua proses yang berjalan. Karena itu, kernel mengeluarkan page teks sshd, lalu instruksi berikutnya yang dijalankan sshd menjadi page fault yang harus membaca kembali byte tersebut dari storage. Setiap proses akhirnya menunggu disk, bukan berjalan. Page yang sama terus dikeluarkan dan dimuat kembali dalam satu siklus. Kondisi ini disebut thrashing.

Dua hal membuat kondisi ini lebih buruk pada VPS daripada pada laptop. Storage sering terhubung melalui jaringan atau digunakan bersama, sehingga setiap page fault memerlukan lebih banyak milidetik daripada pada perangkat NVMe lokal. Selain itu, kernel tidak mengukur waktu, tetapi mengukur kegagalan: selama reclaim masih dapat mengembalikan sebuah page, seberapa lambat pun prosesnya, kernel menganggapnya masih membuat kemajuan dan tidak memanggil out of memory (OOM) killer. Server dapat berada dalam kondisi tersebut selama beberapa menit sebelum proses apa pun dihentikan.

Anda dapat mengamati kondisi ini saat terjadi. Kernel menyediakan pressure stall information (PSI) di Linux 4.20 dan versi yang lebih baru:

cat /proc/pressure/memory
cat /proc/pressure/io

some avg10=63.72 avg60=41.02 avg300=12.33 total=13729481
full avg10=48.15 avg60=30.44 avg300=8.90 total=9114233

Baris full adalah baris yang penting. full avg10=48.15 berarti bahwa selama sepuluh detik terakhir, 48% waktunya setiap task yang dapat dijalankan pada server terhenti karena menunggu pekerjaan memori. Akibatnya, tidak ada yang berjalan. Server yang sehat menunjukkan nilai mendekati nol pada full. Nilai di atas 10 terasa lambat bagi pengguna, sedangkan nilai 40 atau lebih menunjukkan kondisi yang biasanya disebut membeku.

Inilah alasan batas, jika diterapkan sendiri, bukan sebuah jaminan. Unit yang berada di bawah MemoryHigh= akan mengalami throttling, bukan dihentikan. Unit tersebut tetap aktif dan tetap lambat, dan tidak ada yang memulai ulangnya karena dari sudut pandang systemd, unit tersebut tidak pernah gagal. Unit yang dibatasi tetapi masih diizinkan menggunakan swap menghasilkan operasi baca dan tulis yang dibebankan kepada unit tersebut, tetapi dilayani oleh satu perangkat bersama. Akibatnya, unit tersebut dapat menaikkan /proc/pressure/io untuk setiap service lain pada server. Batas menentukan pihak yang menanggung kekurangan, tetapi tidak dapat menciptakan kapasitas.

Pastikan VPS Anda menjalankan cgroup v2

stat -fc %T /sys/fs/cgroup

cgroup2fs adalah hierarki terpadu yang diperlukan oleh semua pengaturan di bawah ini. tmpfs berarti server melakukan boot dengan tata letak v1 yang lebih lama. Pada tata letak tersebut, MemoryHigh= dan MemorySwapMax= tidak tersedia, dan perilaku OOM per unit berbeda. Ubuntu 22.04 dan versi yang lebih baru, serta Debian 11 dan versi yang lebih baru, menggunakan v2 secara default. Image lama atau kernel yang melakukan boot dengan systemd.unified_cgroup_hierarchy=0 tidak menggunakan v2.

Pada cgroup v2, systemd mengaktifkan accounting memori untuk setiap unit secara default. Jadi, angkanya sudah tersedia:

systemd-cgtop -m

Perintah tersebut mencantumkan cgroup yang diurutkan berdasarkan penggunaan memori. Ini adalah cara tercepat untuk mengetahui "apa yang menghabiskan sumber daya server ini" saat server masih dapat merespons. Jika server masih baru, lakukan pekerjaan akun dan firewall dalam sepuluh menit pertama pada VPS baru sebelum langkah ini.

MemoryHigh melakukan throttling. MemoryMax menghentikan proses.

Perbedaan antara kedua pengaturan memori ini menentukan bentuk kegagalan yang terjadi.

• MemoryHigh= adalah batas lunak. Jika pemakaian melebihi batas ini, kernel secara agresif mengambil kembali memori dari cgroup tersebut dan sengaja memperlambat alokasi memorinya. Pemakaian masih dapat melebihi angka tersebut, dan tidak ada proses yang dihentikan.
• MemoryMax= adalah batas keras. Jika alokasi tidak dapat dipenuhi dalam batas ini, OOM killer berjalan di dalam cgroup tersebut dan menghentikan salah satu proses milik unit itu sendiri.

Bagian kedua itulah alasan utama untuk menetapkan MemoryMax= pada apa pun yang tidak sepenuhnya Anda percayai. Tanpa batas, kekurangan memori menjadi masalah seluruh server, dan OOM killer global memilih korbannya berdasarkan oom_score, yang biasanya berarti proses terbesar. Proses terbesar biasanya database Anda, bukan skrip yang mengalami kebocoran memori. Dengan batas, proses yang dihentikan berasal dari unit yang menyebabkannya.

Tetapkan keduanya, dengan MemoryHigh= sekitar 20 hingga 30 persen di bawah MemoryMax=. Selisih ini menjadi zona peringatan: kebocoran memori yang lambat melewati High dan terlihat sebagai service yang menjadi lambat, sedangkan lonjakan tiba-tiba langsung melewati Max lalu menyebabkan proses dihentikan.

Nilai persentase dihitung berdasarkan memori fisik yang terpasang. Jadi, MemoryMax=25% pada paket 4 GB bernilai 1 GB dan tetap menjadi seperempat kapasitas server setelah Anda memperbesar paket. MemorySwapMax=0 sepenuhnya mencegah unit tersebut menggunakan swap, sehingga proses yang berjalan lambat dalam waktu lama berubah menjadi penghentian yang cepat dan mudah dikenali.

Batas memori harus disertai kebijakan restart. Jika tidak, penghentian proses hanya akan meninggalkan service dalam keadaan berhenti.

[Unit]
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=5s

StartLimit* harus ditempatkan di [Unit], sedangkan Restart= harus ditempatkan di [Service]. Jika salah satunya ditempatkan di section yang keliru, systemd akan mengabaikannya. Lima kali restart dalam lima menit menunjukkan kebocoran, bukan gangguan sesaat. Setelah itu, systemd menyerah dan membiarkan unit dalam keadaan gagal. Keadaan inilah yang ingin Anda temukan nanti, bukan crash loop yang menyembunyikan masalah.

Batasi CPU dengan CPUQuota, atau bagi dengan CPUWeight

CPUQuota= menggunakan persentase waktu yang tersedia pada satu CPU. CPUQuota=50% setara dengan setengah core. CPUQuota=200% setara dengan dua core, yang dapat digunakan unit pada thread sebanyak yang diperlukan. Pada paket 2 vCPU, CPUQuota=200% setara dengan seluruh mesin.

CPUWeight= merupakan default yang lebih baik untuk sebagian besar service. Nilainya adalah pembagian relatif dari 1 hingga 10000, sedangkan default kernel adalah 100. Pengaturan ini hanya berpengaruh ketika terjadi persaingan: pekerjaan pencadangan pada CPUWeight=20 akan mengalah kepada web server pada 100 saat beban tinggi, tetapi tetap dapat menggunakan seluruh mesin ketika mesin sedang idle. Kuota tetap membuang kapasitas yang sedang idle tersebut.

Pahami dengan tepat manfaat pembatasan CPU. Proses yang terbatas oleh CPU jarang membuat Linux berhenti merespons karena scheduler tetap membagikan waktu kepada semua proses. Memori adalah sumber daya yang biasanya membuat mesin tidak berfungsi. Gunakan CPUQuota= jika Anda memerlukan batas atas yang dapat diprediksi, misalnya untuk proses build atau agent yang jika tidak dibatasi akan menggunakan CPU penuh selama satu jam. Menentukan ukuran resource untuk beban kerja tersebut merupakan topik tersendiri, yang dibahas dalam berapa banyak RAM dan CPU yang dibutuhkan coding agent VPS.

Jika CPU terlihat sibuk sementara tidak ada proses Anda yang menggunakan banyak resource, penyebabnya mungkin berada di sisi lain hypervisor. Ini disebut CPU steal time dari noisy neighbour, dan quota apa pun yang Anda tetapkan tidak akan mengubahnya.

TasksMax menghentikan fork loop

TasksMax= adalah jumlah proses dan thread yang boleh dimiliki oleh suatu unit. Thread juga dihitung, sehingga service Java atau Go memerlukan batas yang lebih tinggi daripada yang terlihat pada daftar proses. Ini adalah perlindungan paling sederhana terhadap script yang melakukan fork dalam loop, karena fork gagal di dalam unit sebelum server kehabisan process ID.

TasksMax=128

Saat suatu unit mencapai batas tersebut, kernel mencatat baris yang menyebutkan cgroup:

cgroup: fork rejected by pids controller in /system.slice/myapp.service

Program itu sendiri biasanya melaporkan fork: retry: Resource temporarily unavailable. Periksa nilai default yang diterapkan oleh manager dengan systemctl show -p DefaultTasksMax.

Batasi tugas sekali jalan dengan systemd-run

Anda tidak memerlukan unit file untuk menggunakan semua ini. systemd-run membuat unit sementara untuk satu perintah.

sudo systemd-run --scope -p MemoryMax=1G -p MemorySwapMax=0 -p CPUQuota=50% -p TasksMax=64 ./import-data.sh

--scope menjalankan perintah di terminal Anda setelah mencetak Running scope as unit: run-r7c1a....scope. Output tetap tampil di layar, dan batasan tersebut hilang setelah perintah selesai. Properti apa pun dari systemd.resource-control dapat digunakan setelah -p.

Untuk tugas yang berjalan lama, hapus --scope dan berikan nama. Tugas tersebut kemudian berjalan di latar belakang sebagai service sementara dan mencatat log ke journal:

sudo systemd-run --unit=nightly-import -p MemoryMax=1G -p CPUWeight=20 ./import-data.sh
journalctl -u nightly-import -f

Opsi yang sama dapat digunakan dengan --user saat Anda bukan root, tetapi user manager Anda hanya memiliki controller yang didelegasikan kepadanya sehingga sebuah properti dapat ditolak. Jalankan dengan sudo jika hal itu terjadi. Saat sebuah tugas memerlukan tempat permanen, pengaturannya dapat dipindahkan tanpa perubahan ke unit sebenarnya: lihat menjalankan skrip sebagai service dan timer systemd.

Menjawab pertanyaan tentang swap dengan jujur

Swap mengubah bentuk kegagalan, bukan mencegahnya.

Tanpa swap, kebocoran memori mencapai batas dan salah satu proses berhenti dalam hitungan detik. Gangguan layanan berlangsung singkat, terlihat jelas, dan mudah dianalisis di journal setelahnya. Dengan swap, kernel menulis halaman anonim yang jarang digunakan ke disk sehingga tersedia lebih banyak waktu. Jika proses akan berhenti bertambah, swap menyelamatkan Anda. Jika proses terus menggunakan memori tanpa kendali, swap mengubah gangguan layanan selama lima detik menjadi kemacetan selama dua puluh menit. Kemacetan ini lebih buruk karena proses yang berhenti masih menyisakan shell yang dapat digunakan, sedangkan sistem yang terus melakukan thrashing tidak.

swapon --show
free -h

Pendekatan yang dapat diterapkan pada VPS kecil adalah menyediakan swap file berukuran sedang untuk halaman yang dialokasikan sekali dan tidak pernah digunakan lagi, lalu menetapkan MemorySwapMax=0 pada unit yang siap Anda korbankan. Layanan penting tetap dapat menggunakan swap. Layanan yang tidak dapat diprediksi segera mencapai batas lalu dimulai ulang.

Menurunkan vm.swappiness bukan tuas yang kuat, dan penting untuk memahami alasannya. Pengaturan ini hanya mengubah keseimbangan antara mengeluarkan page cache dan melakukan swapping pada halaman anonim. Keduanya tetap memerlukan pembacaan dari disk pada tahap berikutnya. Pengaturan ini mengubah halaman mana yang mengalami thrashing, bukan menentukan apakah sistem akan mengalami thrashing.

Daemon OOM dini mematikan proses sebelum sistem macet

Kernel menunggu hingga reclaim gagal sepenuhnya. Pada VPS kecil, penundaan tersebut adalah waktu ketika Anda kehilangan akses ke mesin. Dua daemon userspace menutup celah ini dengan memantau memori sendiri dan mematikan proses lebih awal.

earlyoom memantau memori yang tersedia dan swap yang bebas. Daemon ini mematikan proses dengan skor tertinggi ketika salah satunya turun di bawah ambang batas.

sudo apt install earlyoom
systemctl status earlyoom

Paket Debian dan Ubuntu menjalankan service ini saat instalasi. Opsinya berada di /etc/default/earlyoom:

EARLYOOM_ARGS="-m 5,2 -s 5,2 --avoid '^(sshd|systemd)$' --prefer '^(node|python3)$'"

-m PERCENT menetapkan batas minimum memori yang tersedia, sedangkan -s PERCENT menetapkan batas minimum swap yang bebas. Keduanya secara default bernilai 10 persen. Angka kedua pada setiap pasangan adalah titik SIGKILL. earlyoom mengirim SIGTERM setelah nilainya turun di bawah angka pertama, lalu mengirim SIGKILL setelah turun di bawah angka kedua. Secara default, angka kedua adalah setengah dari angka pertama. Terapkan perubahan dengan sudo systemctl restart earlyoom. Baca journalctl -u earlyoom untuk melihat proses yang dimatikan dan jumlah memori yang digunakan proses tersebut.

systemd-oomd adalah opsi lainnya. Halaman manualnya menjelaskan bahwa opsi ini adalah "service sistem yang menggunakan cgroups-v2 dan pressure stall information (PSI) untuk memantau serta mengambil tindakan korektif sebelum OOM terjadi di ruang kernel". Opsi ini bekerja pada seluruh cgroup, bukan pada proses tunggal. Karena itu, opsi ini mematikan unit, bukan child process yang tidak terkait. Unit dapat ikut serta dengan ManagedOOMMemoryPressure=kill atau ManagedOOMSwap=kill. Ambang batasnya berada di /etc/systemd/oomd.conf.

systemctl status systemd-oomd
oomctl

oomctl menampilkan hal yang sedang dipantau. Pada server image, hasilnya sering kali tidak ada karena pengaturan ini harus diaktifkan secara eksplisit untuk setiap unit. Pilih salah satu daemon saja. Menjalankan keduanya berarti dua daemon berlomba memilih korban. Akibatnya, alasan proses dimatikan menjadi lebih sulit ditelusuri.

Unit mana yang bertanggung jawab?

Mulai dari kernel, karena kernel mencatat setiap proses kill yang dilakukannya.

journalctl -k --grep "Killed process" --since "2 hours ago"

Kill dari OOM killer global terlihat seperti ini:

Out of memory: Killed process 4127 (node) total-vm:2731084kB, anon-rss:1874232kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:4212kB oom_score_adj:0

anon-rss adalah memori yang digunakan proses tersebut di RAM saat proses itu dihentikan, sekitar 1.8 GB dalam contoh ini. Baca nama dalam tanda kurung dengan hati-hati. Nama itu adalah proses yang dipilih kernel sebagai korban. Kernel memilih proses terbesar, tetapi proses tersebut belum tentu yang menyebabkan kekurangan memori.

Kill akibat batas cgroup memiliki awalan yang berbeda. Laporan di atasnya mencantumkan cgroup yang mencapai batasnya sendiri:

Memory cgroup out of memory: Killed process 8811 (python3) total-vm:1044320kB, anon-rss:769112kB, file-rss:0kB, shmem-rss:0kB, UID:998 pgtables:1720kB oom_score_adj:0

Awalan tersebut sudah mencakup sebagian besar diagnosis. Memory cgroup out of memory berarti satu unit mencapai MemoryMax= yang Anda tetapkan, sementara sistem lainnya tidak bermasalah. Out of memory tanpa keterangan berarti seluruh mesin kehabisan memori. Artinya, batas yang Anda tetapkan tidak ada atau terlalu longgar jika dijumlahkan.

Selanjutnya, tanyakan kepada systemd apa yang dilihatnya:

systemctl status myapp.service
journalctl -u myapp.service -n 50

myapp.service: A process of this unit has been killed by the OOM killer.
myapp.service: Main process exited, code=killed, status=9/KILL
myapp.service: Failed with result 'oom-kill'.

systemctl status menyampaikan hal yang sama dalam satu baris, sebagai Active: failed (Result: oom-kill).

Penghitung cgroup adalah sumber informasi ketiga. Hanya penghitung ini yang mencatat throttling, yang sama sekali tidak menghasilkan baris log:

cat /sys/fs/cgroup/system.slice/myapp.service/memory.events
cat /sys/fs/cgroup/system.slice/myapp.service/memory.peak

low 0
high 4213
max 118
oom 12
oom_kill 12

high menghitung berapa kali unit melewati MemoryHigh= dan mengalami throttling. max menghitung berapa kali unit mencapai batas keras. oom_kill menghitung proses yang benar-benar dihentikan. high yang besar bersama oom_kill 0 adalah kasus diam-diam yang dijelaskan sebelumnya: service masih berjalan, kecepatannya sangat rendah, dan tidak melaporkan kegagalan kepada siapa pun. memory.peak (Linux 5.19 dan yang lebih baru) menyimpan penggunaan tertinggi yang dicapai cgroup. Gunakan angka ini untuk menentukan ukuran MemoryMax=. Kedua file direset saat unit dimulai ulang karena systemd membuat cgroup tersebut kembali.

Ada satu prasyarat yang mendasari semua ini. Jika /var/log/journal tidak ada, journal disimpan di RAM. Semua baris akan hilang setelah reboot yang diperlukan untuk memulihkan server.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

journalctl --list-boots yang menampilkan lebih dari boot saat ini berarti riwayat kini tetap tersimpan. Dengan demikian, journalctl -k -b -1 dapat menampilkan pesan kernel dari boot yang mengalami kegagalan.

Titik awal untuk VPS kecil

Pada paket 2 GB, sisakan 300 hingga 400 MB untuk kernel dan page cache. Jangan biarkan total batas mencapai 2 GB penuh, karena setiap unit dapat mencapai penggunaan puncak pada saat yang sama. Berikan porsi terbesar kepada service yang paling penting, lalu tetapkan batas untuk service lain yang bersifat spekulatif di sekitarnya.

[Service]
MemoryHigh=256M
MemoryMax=384M
MemorySwapMax=0
CPUWeight=20
TasksMax=64
Restart=on-failure
RestartSec=5s

Mempertahankan akses ke server memerlukan satu pengaturan tambahan. OOMScoreAdjust=-500 dalam drop-in untuk ssh.service membuat global OOM killer jauh lebih kecil kemungkinannya memilih daemon SSH sebagai proses yang dihentikan. Hal ini dapat menentukan apakah Anda dapat memperbaiki server atau harus me-reboot-nya dari control panel. Pengaturan ini hanya mengubah pilihan kernel mengenai proses yang dihentikan. Pengaturan ini tidak mempersingkat durasi stall.

Container berjalan dalam cgroup masing-masing. cgroup tersebut dibuat oleh container runtime, bukan oleh file unit Anda. Karena itu, batas pada docker.service tidak menjadi batas untuk satu container. Padanan per-container untuk MemoryMax= dan CPUQuota= dibahas dalam mengatur batas memori dan CPU di Docker Compose.

FAQ

Mengapa VPS saya macet alih-alih menghentikan proses yang tidak terkendali?

Karena kernel menilai kemajuan berdasarkan apakah proses reclaim mengembalikan halaman memori, bukan berdasarkan lamanya proses tersebut berlangsung. Saat memori terbatas, kernel mengeluarkan page cache, termasuk halaman executable dari program yang sedang berjalan, lalu membacanya kembali saat instruksi berikutnya dijalankan. Semua proses menunggu storage dan tidak ada alokasi yang secara teknis gagal, sehingga OOM killer tidak pernah dipanggil. Periksa /proc/pressure/memory saat kondisi ini berlangsung: nilai full avg10 di atas 40 berarti hampir tidak ada task yang sempat berjalan dalam sepuluh detik terakhir. Daemon userspace seperti earlyoom dapat menghentikan proses sebelum sistem mencapai kondisi tersebut.

Apa perbedaan antara MemoryHigh dan MemoryMax?

MemoryHigh= adalah batas lunak yang membatasi laju penggunaan memori. Kernel melakukan reclaim secara paksa dari unit tersebut dan memperlambat alokasinya, tetapi penggunaan memori dapat melampaui angka itu dan tidak ada proses yang dihentikan. MemoryMax= adalah batas keras: alokasi yang tidak dapat dipenuhi dalam batas tersebut akan memanggil OOM killer di dalam cgroup milik unit itu sendiri. Dengan demikian, proses yang menyebabkan masalah akan dihentikan, bukan proses terbesar pada sistem. Tetapkan MemoryHigh= di bawah MemoryMax= dan gunakan selisih di antara keduanya sebagai zona peringatan.

Bagaimana cara mengetahui service yang terkena OOM killer?

Jalankan journalctl -k --grep "Killed process" --since "2 hours ago". Baris yang diawali Memory cgroup out of memory berarti satu unit melampaui MemoryMax= miliknya sendiri, sedangkan Out of memory tanpa awalan tambahan berarti seluruh mesin kehabisan memori. Selanjutnya, jalankan journalctl -u <unit> -n 50 dan cari Failed with result 'oom-kill'. Jika /var/log/journal tidak ada di server Anda, journal disimpan di RAM dan buktinya hilang saat reboot. Buat direktori tersebut sebelum insiden berikutnya.

Apakah saya perlu menambahkan swap pada VPS kecil?

File swap berukuran kecil membantu untuk halaman memori yang jarang digunakan, dialokasikan sekali, lalu tidak pernah diakses lagi. Swap tidak membantu proses yang tidak terkendali. Swap hanya menunda penghentian proses dan mengubah gangguan singkat menjadi macet lama yang membuat Anda tidak dapat login untuk memperbaikinya. Gunakan swap secukupnya, lalu tetapkan MemorySwapMax=0 pada unit yang boleh dihentikan. Dengan begitu, unit tersebut mencapai batasnya dan segera restart, sementara service penting tetap dapat menggunakan swap.

Apakah saya dapat membatasi command tanpa menulis unit file?

Ya. sudo systemd-run --scope -p MemoryMax=1G -p CPUQuota=50% ./script.sh menjalankan command di terminal Anda dalam transient scope dengan batas tersebut, dan batas itu hilang setelah command selesai. Semua properti dari systemd.resource-control tersedia setelah -p, sehingga MemorySwapMax=, TasksMax=, dan CPUWeight= juga dapat digunakan. Hapus --scope dan tambahkan --unit=name untuk menjalankan job di background dengan output yang dicatat dalam journal.