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 waktu prosesor. Keduanya diberlakukan 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 komentar 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 yang Anda gunakan dalam unit milik kernel: MemoryMax=805306368 dan CPUQuotaPerSecUSec=800ms. Jika hasilnya MemoryMax=infinity, drop-in belum dimuat. Periksa apakah file tersimpan di /etc/systemd/system/myapp.service.d/override.conf dan diawali dengan header [Service], karena baris pengaturan tanpa section di atasnya membuat systemd mencatat Assignment outside of section. Ignoring. lalu menjalankan service tanpa batas sama sekali.

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

Mengapa proses yang tidak terkendali membekukan VPS tanpa pernah memenuhi kapasitasnya

Proses yang mencapai batas memori keras akan berhenti dalam waktu sekitar satu detik, lalu service dimulai ulang. Itu kondisi yang baik. Kondisi buruk terjadi ketika tidak ada proses yang berhenti: server masih merespons ping, SSH menerima koneksi, tetapi prompt shell tidak pernah muncul. Mesin masih hidup 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 menyediakan page baru. Page yang paling murah untuk diambil kembali adalah page yang didukung file, dan page cache menyimpan kode executable dari semua proses yang berjalan. Karena itu, kernel mengeluarkan text page milik sshd, lalu instruksi berikutnya yang dijalankan sshd adalah page fault yang harus membaca kembali byte tersebut dari storage. Setiap proses akhirnya menunggu disk, bukan berjalan. Page yang sama terus dikeluarkan lalu dimuat kembali dalam satu loop. Kondisi ini disebut thrashing.

Dua hal membuat kondisi ini lebih buruk pada VPS daripada laptop. Storage sering terhubung melalui jaringan atau digunakan bersama, sehingga setiap page fault memerlukan waktu beberapa milidetik lebih lama daripada pada perangkat NVMe lokal. Selain itu, kernel tidak mengukur waktu, melainkan kegagalan: selama reclaim masih berhasil mengembalikan satu page, meskipun sangat lambat, kernel menganggap sistem masih mengalami kemajuan dan tidak memanggil out of memory (OOM) killer. Server dapat berada dalam kondisi tersebut selama beberapa menit sebelum ada proses yang dihentikan.

Anda dapat memantaunya saat kondisi ini 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 bagian yang penting. full avg10=48.15 berarti bahwa selama sepuluh detik terakhir, 48% waktu setiap task yang dapat dijalankan pada server mengalami stall karena menunggu pekerjaan memori, sehingga tidak ada task yang berjalan. Server yang sehat menunjukkan nilai mendekati nol pada full. Nilai di atas 10 terasa lambat bagi manusia, sedangkan 40 atau lebih menunjukkan kondisi yang biasanya disebut beku.

Ini juga menjelaskan mengapa limit saja bukan jaminan. Unit yang dibatasi oleh MemoryHigh= akan mengalami throttling, bukan dihentikan. Unit tersebut tetap hidup dan tetap lambat, dan tidak ada proses yang dimulai ulang karena dari sudut pandang systemd, unit tersebut tidak pernah gagal. Unit yang dibatasi tetapi masih diizinkan menggunakan swap akan menghasilkan operasi baca dan tulis yang dibebankan kepada unit tersebut, tetapi dilayani oleh satu device bersama. Akibatnya, unit itu dapat menaikkan /proc/pressure/io untuk setiap service lain pada server. Limit menentukan pihak yang menanggung dampak kekurangan resource, tetapi tidak dapat menciptakan kapasitas.

Periksa apakah 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 sistem melakukan boot dengan tata letak v1 yang lebih lama. Pada tata letak ini, MemoryHigh= dan MemorySwapMax= tidak ada, dan perilaku OOM per unit berbeda. Ubuntu 22.04 dan versi lebih baru, serta Debian 11 dan versi lebih baru, menggunakan v2 secara default. Image lama atau kernel yang melakukan boot dengan systemd.unified_cgroup_hierarchy=0 tidak menggunakan v2.

Pada sistem cgroup v2, systemd mengaktifkan penghitungan penggunaan memori untuk setiap unit secara default. Karena itu, angkanya sudah tersedia:

systemd-cgtop -m

Perintah tersebut mengurutkan cgroup 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 terlebih dahulu.

MemoryHigh melakukan throttling. MemoryMax menghentikan proses.

Perbedaan antara kedua pengaturan memori ini menentukan bentuk kegagalannya.

• MemoryHigh= adalah batas lunak. Di atas batas ini, kernel secara agresif mengambil kembali memori dari cgroup tersebut dan sengaja memperlambat alokasi memorinya. Penggunaan memori masih dapat melewati 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 inilah alasan utama untuk menetapkan MemoryMax= pada apa pun yang tidak sepenuhnya Anda percayai. Tanpa batas, kekurangan memori menjadi masalah seluruh host, dan OOM killer global memilih korbannya berdasarkan oom_score, yang biasanya berarti proses terbesar. Proses terbesar biasanya adalah 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 adalah zona peringatan: kebocoran yang berjalan lambat melewati High dan terlihat sebagai service yang menjadi lambat, sedangkan lonjakan tiba-tiba langsung melewati Max lalu dihentikan.

Nilai persentase dihitung berdasarkan memori fisik yang terpasang, sehingga MemoryMax=25% pada paket 4 GB bernilai 1 GB dan tetap menjadi seperempat kapasitas host setelah ukuran paket ditingkatkan. MemorySwapMax=0 membuat unit tersebut sepenuhnya tidak menggunakan swap, sehingga proses yang berjalan lambat dalam waktu lama berubah menjadi penghentian yang cepat dan jelas.

Beberapa service memungkinkan Anda menentukan kebutuhan memorinya sejak awal, bukan mengukurnya: unit Ollama menentukan ukuran cache KV berdasarkan context window yang Anda berikan. Baca biaya kenaikan num_ctx terhadap RAM sebelum memilih batas untuk unit tersebut.

Batas memerlukan kebijakan restart di sebelahnya. 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] dan Restart= di [Service]. Jika salah satunya ditempatkan di section yang keliru, systemd akan mengabaikannya. Lima kali restart dalam lima menit menunjukkan kebocoran, bukan gangguan singkat. Setelah itu systemd menyerah dan membiarkan unit dalam status failed. Status inilah yang ingin Anda temukan nanti, bukan crash loop yang menyembunyikan masalah.

Batasi CPU dengan CPUQuota atau berbagi waktu CPU 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 sebanyak mungkin thread sesuai kebutuhannya. Pada paket 2 vCPU, CPUQuota=200% setara dengan seluruh mesin.

CPUWeight= merupakan pilihan 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 dengan CPUWeight=20 akan mengalah kepada web server dengan nilai 100 saat beban tinggi, tetapi tetap dapat menggunakan seluruh mesin saat mesin sedang idle. Kuota ketat membuang kapasitas idle tersebut.

Pahami batasan yang diberikan oleh pembatasan CPU. Proses yang terikat CPU jarang membuat Linux berhenti merespons karena scheduler terus membagikan waktu kepada semua proses. Memori yang biasanya membuat server 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 untuk beban kerja seperti itu merupakan persoalan tersendiri, yang dibahas dalam berapa banyak RAM dan CPU yang diperlukan coding agent VPS.

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

TasksMax menghentikan loop fork

TasksMax= adalah jumlah proses dan thread yang dapat dimiliki oleh suatu unit. Thread ikut dihitung, sehingga service Java atau Go memerlukan batas yang lebih longgar daripada yang terlihat dari daftar proses. Ini adalah perlindungan paling murah terhadap script yang melakukan fork dalam loop, karena fork gagal di dalam unit sebelum server kehabisan ID proses.

TasksMax=128

Saat suatu unit mencapai batas tersebut, kernel mencatat baris log 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 pekerjaan 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 menampilkan Running scope as unit: run-r7c1a....scope. Output tetap ditampilkan di layar, dan batasan tersebut dihapus saat perintah selesai. Properti apa pun dari systemd.resource-control dapat digunakan setelah -p.

Untuk pekerjaan yang berlangsung lama, hapus --scope dan berikan nama. Pekerjaan 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. Karena itu, suatu properti dapat ditolak. Jalankan dengan sudo jika hal tersebut terjadi. Jika suatu pekerjaan memerlukan unit permanen, pindahkan pengaturannya tanpa perubahan ke unit nyata: lihat menjalankan skrip sebagai service dan timer systemd.

Pertanyaan tentang swap, dijawab secara jujur

Swap mengubah bentuk kegagalan, bukan mencegahnya.

Tanpa swap, kebocoran mencapai batas memori dan sesuatu mati dalam hitungan detik. Outage berlangsung singkat, terlihat jelas, dan mudah dianalisis di journal setelahnya. Dengan swap, kernel menulis halaman anonim yang jarang digunakan ke disk sehingga tersedia waktu tambahan. Jika proses akan berhenti menggunakan memori pada tingkat tertentu, swap membantu. Jika proses terus berjalan tanpa kendali, swap mengubah outage selama lima detik menjadi stall selama dua puluh menit. Stall lebih buruk karena proses yang mati masih menyisakan shell yang dapat digunakan, sedangkan mesin yang terus-menerus melakukan thrashing tidak.

swapon --show
free -h

Solusi 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. Service penting tetap memiliki akses ke swap. Service yang perilakunya tidak dapat diprediksi akan cepat mencapai batas lalu di-restart.

Menurunkan vm.swappiness hanya memberikan pengaruh terbatas, 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 waktu berikutnya. Pengaturan ini mengubah halaman mana yang mengalami thrashing, bukan menentukan apakah mesin akan mengalami thrashing.

Daemon OOM lebih awal membunuh proses sebelum sistem macet

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

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

sudo apt install earlyoom
systemctl status earlyoom

Paket Debian dan Ubuntu memulai service 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 minimum memori yang tersedia, sedangkan -s PERCENT menetapkan minimum swap yang bebas. Keduanya secara default bernilai 10 persen. Angka kedua pada setiap pasangan adalah batas SIGKILL. earlyoom mengirim SIGTERM setelah nilai pertama terlewati ke bawah, lalu mengirim SIGKILL setelah nilai kedua terlewati ke bawah. Nilai kedua secara default adalah setengah dari nilai pertama. Terapkan perubahan dengan sudo systemctl restart earlyoom. Baca journalctl -u earlyoom untuk melihat proses yang dibunuh dan jumlah memori yang digunakan proses tersebut.

systemd-oomd adalah opsi lainnya. Halaman manualnya menjelaskan bahwa daemon 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". Daemon ini bekerja pada seluruh cgroup, bukan proses tunggal. Karena itu, daemon ini membunuh unit, bukan child process yang tidak terkait. Unit harus memilih ikut 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 image server, biasanya tidak ada apa pun karena pengaturan ini harus diaktifkan secara eksplisit untuk setiap unit. Pilih satu daemon saja dan gunakan daemon tersebut. Menjalankan keduanya membuat kedua daemon berlomba memilih korban. Akibatnya, alasan suatu proses dibunuh menjadi lebih sulit ditelusuri.

Unit mana yang bertanggung jawab?

Mulai dari kernel karena kernel mencatat setiap proses yang dihentikannya.

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

Penghentian oleh 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 dihentikan, sekitar 1.8 GB pada contoh ini. Baca nama dalam tanda kurung dengan hati-hati. Nama itu adalah proses yang dipilih kernel sebagai korban. Kernel memilih proses terbesar, yang belum tentu merupakan proses penyebab kekurangan memori.

Penghentian akibat batas cgroup memiliki awalan yang berbeda. Laporan yang tercetak di atasnya menyebutkan 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 memberikan sebagian besar diagnosis. Memory cgroup out of memory berarti satu unit mencapai MemoryMax= yang Anda tetapkan, sementara sistem lainnya tidak mengalami masalah. Out of memory biasa berarti seluruh mesin kehabisan memori. Artinya, batas Anda tidak ditetapkan atau jumlahnya terlalu besar jika digabungkan.

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 dan satu-satunya sumber 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 melampaui MemoryHigh= lalu mengalami throttling. max menghitung berapa kali unit mencapai batas keras, sedangkan oom_kill menghitung proses yang benar-benar dihentikan. Nilai high yang besar bersama oom_kill 0 menunjukkan kasus senyap yang dibahas sebelumnya: service tetap berjalan, menjadi sangat lambat, 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 tersebut direset ketika unit dimulai ulang karena systemd membuat ulang cgroup.

Ada satu prasyarat yang mendasari semua ini. Jika /var/log/journal tidak ada, journal tersimpan di RAM, dan semua baris log hilang setelah reboot yang Anda perlukan untuk memulihkan sistem.

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 boot selain 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. Setelah itu, tetapkan batas untuk service lain yang penggunaannya masih bersifat spekulatif.

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

Mempertahankan akses masuk sepadan dengan satu pengaturan tambahan. OOMScoreAdjust=-500 dalam drop-in untuk ssh.service membuat OOM killer global jauh lebih kecil kemungkinannya memilih daemon SSH sebagai korbannya. Ini dapat menentukan apakah Anda masih dapat memperbaiki server atau harus me-reboot-nya dari control panel. Pengaturan ini hanya mengubah pilihan kernel terhadap proses yang dihentikan. Pengaturan ini tidak mempersingkat waktu server mengalami 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 MemoryMax= dan CPUQuota= per container dibahas dalam menetapkan batas memori dan CPU di Docker Compose.

FAQ

Mengapa VPS saya macet, bukan menghentikan proses yang tidak terkendali?

Karena kernel menilai kemajuan berdasarkan apakah reclaim berhasil mengembalikan page, bukan berdasarkan lamanya proses tersebut. Saat memori menipis, kernel mengevakuasi page cache, termasuk executable page milik program yang sedang berjalan, lalu membacanya kembali saat instruksi berikutnya dijalankan. Semua proses menunggu storage dan belum ada alokasi yang benar-benar gagal, sehingga OOM killer tidak pernah dipanggil. Periksa /proc/pressure/memory saat kondisi ini terjadi: 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 server mencapai kondisi tersebut.

Apa perbedaan antara MemoryHigh dan MemoryMax?

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

Bagaimana cara mengetahui service yang dihentikan oleh OOM killer?

Jalankan journalctl -k --grep "Killed process" --since "2 hours ago". Baris yang diawali Memory cgroup out of memory berarti satu unit mencapai MemoryMax= miliknya sendiri, sedangkan Out of memory tanpa awalan 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 ke VPS kecil?

File swap kecil membantu untuk cold page yang dialokasikan sekali dan tidak pernah digunakan lagi. Swap tidak membantu proses yang tidak terkendali. Swap hanya menunda penghentian proses dan mengubah gangguan singkat menjadi macet berkepanjangan sehingga Anda tidak dapat login untuk memperbaikinya. Gunakan swap secukupnya, lalu tetapkan MemorySwapMax=0 pada unit yang dapat Anda korbankan. Dengan begitu, unit tersebut mencapai batasnya dan restart dengan cepat, sementara service penting tetap dapat menggunakan swap.

Bisakah saya membatasi command tanpa menulis unit file?

Bisa. sudo systemd-run --scope -p MemoryMax=1G -p CPUQuota=50% ./script.sh menjalankan command di terminal Anda dalam transient scope dengan batas tersebut. 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 di journal.