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), fitur kernel yang sudah digunakan systemd untuk mencatat penggunaan setiap service di 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 unit yang digunakan kernel: MemoryMax=805306368 dan CPUQuotaPerSecUSec=800ms. Jika menampilkan MemoryMax=infinity, drop-in tidak pernah dimuat. Periksa apakah file berada di /etc/systemd/system/myapp.service.d/override.conf dan diawali header [Service], karena baris pengaturan tanpa section di atasnya membuat systemd mencatat Assignment outside of section. Ignoring. dan menjalankan service tanpa batas sama sekali.

Bagian selanjutnya menjelaskan cara memilih angka tersebut dan masalah yang masih dapat terjadi setelah angka itu ditetapkan.

Mengapa proses yang tidak terkendali membekukan VPS tanpa memenuhi memorinya

Proses yang mencapai batas memori keras akan berhenti dalam waktu sekitar satu detik, lalu service dimulai ulang. Itu kondisi yang baik. Kondisi buruk terjadi saat tidak ada proses yang berhenti: server masih merespons ping, SSH menerima koneksi, tetapi prompt shell tidak pernah muncul. Mesin masih 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 menyediakan page baru. Page yang paling murah untuk diambil kembali adalah page yang didukung file, sedangkan page cache menyimpan kode executable dari semua proses yang sedang berjalan. Karena itu, kernel mengeluarkan text page dari 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 dan dimuat kembali dalam sebuah loop. Kondisi ini disebut thrashing.

Dua hal membuat kondisi ini lebih buruk pada VPS dibandingkan laptop. Storage sering terhubung melalui jaringan atau digunakan bersama, sehingga setiap page fault memerlukan lebih banyak milidetik dibandingkan perangkat NVMe lokal. Selain itu, kernel tidak mengukur waktu, melainkan kegagalan: selama reclaim masih dapat mengembalikan sebuah page, seberapa lambat pun prosesnya, kernel menganggap dirinya masih membuat kemajuan dan tidak memanggil out of memory (OOM) killer. Server dapat berada dalam kondisi ini selama beberapa menit sebelum ada proses yang 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 bagian yang penting. full avg10=48.15 berarti bahwa selama sepuluh detik terakhir, 48% waktunya semua task yang dapat dijalankan pada server terhenti karena menunggu pekerjaan memori, sehingga tidak ada yang berjalan. Server yang sehat menunjukkan nilai yang mendekati nol pada full. Nilai di atas 10 terasa lambat bagi pengguna, sedangkan nilai 40 atau lebih menunjukkan kondisi yang biasanya disebut beku.

Hal ini juga menjelaskan mengapa batas saja bukan jaminan. Unit yang berada di bawah MemoryHigh= akan dibatasi kecepatannya, bukan dihentikan, sehingga tetap aktif dan tetap lambat. 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 perangkat bersama. Akibatnya, unit tersebut dapat meningkatkan /proc/pressure/io untuk setiap service lain pada server. Batas menentukan pihak yang menanggung dampak kekurangan sumber daya, tetapi batas tidak dapat menciptakan kapasitas baru.

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 menggunakan tata letak v1 yang lebih lama. Dalam tata letak tersebut, MemoryHigh= dan MemorySwapMax= tidak tersedia, 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 dijalankan dengan systemd.unified_cgroup_hierarchy=0 tidak menggunakan v2.

Pada cgroup v2, systemd mengaktifkan pencatatan penggunaan memory untuk setiap unit secara default. Karena itu, datanya sudah tersedia:

systemd-cgtop -m

Perintah tersebut mengurutkan cgroup berdasarkan penggunaan memory. Ini adalah cara tercepat untuk mengetahui "apa yang menghabiskan resource 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 tersebut menentukan bentuk kegagalan yang terjadi.

• MemoryHigh= adalah batas lunak. Jika penggunaan melampauinya, kernel secara agresif mereklamasi memori dari cgroup tersebut dan sengaja memperlambat alokasi memorinya. Penggunaan masih dapat melewati angka tersebut, dan tidak ada proses yang dihentikan.
• MemoryMax= adalah batas keras. Jika alokasi tidak dapat dipenuhi dalam batas tersebut, 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 server, dan OOM killer global memilih korbannya berdasarkan oom_score, yang biasanya berarti proses terbesar. Proses terbesar biasanya adalah database Anda, bukan script 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 tersebut menjadi zona peringatan: kebocoran yang lambat akan melewati High dan terlihat sebagai service yang menjadi lambat, sedangkan lonjakan mendadak akan 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 ukuran paket diubah. MemorySwapMax=0 mencegah unit tersebut menggunakan swap sepenuhnya, sehingga proses yang berjalan sangat lambat berubah menjadi penghentian yang cepat dan jelas.

Beberapa service memungkinkan Anda menentukan kebutuhan memorinya sejak awal, tanpa harus mengukurnya: unit Ollama menentukan ukuran cache KV berdasarkan context window yang Anda berikan. Karena itu, baca biaya peningkatan num_ctx terhadap RAM sebelum memilih batas untuk unit tersebut.

Batas memori perlu disertai kebijakan restart. Jika tidak, proses yang dihentikan hanya akan meninggalkan service dalam keadaan berhenti.

[Unit]
StartLimitIntervalSec=300
StartLimitBurst=5

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

StartLimit* harus ditempatkan dalam [Unit], sedangkan Restart= dalam [Service]. Jika salah satunya ditempatkan di bagian yang salah, systemd akan mengabaikannya. Lima kali restart dalam lima menit menunjukkan kebocoran, bukan gangguan sesaat. 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 bagi sumber daya 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 backup pada CPUWeight=20 akan mengalah kepada web server pada 100 saat beban tinggi, tetapi tetap dapat menggunakan seluruh mesin saat mesin sedang idle. Batas kuota yang ketat membuang kapasitas idle tersebut.

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

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

TasksMax menghentikan fork loop

TasksMax= adalah jumlah proses dan thread yang dapat dimiliki suatu unit. Thread juga dihitung, sehingga service Java atau Go memerlukan ruang tambahan yang lebih besar 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 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 manager dengan systemctl show -p DefaultTasksMax.

Batasi tugas satu kali dengan systemd-run

Anda tidak memerlukan unit file untuk menggunakan semua ini. systemd-run membuat unit sementara di sekitar 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 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. Namun, user manager Anda hanya memiliki controller yang didelegasikan kepadanya, sehingga suatu properti dapat ditolak. Jalankan dengan sudo jika hal itu terjadi. Saat suatu tugas memerlukan tempat permanen, pindahkan pengaturan tersebut tanpa perubahan ke unit sebenarnya: lihat menjalankan skrip sebagai service dan timer systemd.

Pertanyaan tentang swap, dengan jawaban yang jujur

Swap mengubah bentuk kegagalan, bukan mencegahnya.

Tanpa swap, kebocoran memori mencapai batas dan suatu proses berhenti dalam hitungan detik. Gangguan layanan berlangsung singkat, terlihat jelas, dan mudah ditelusuri di journal setelahnya. Dengan swap, kernel menulis anonymous page yang jarang digunakan ke disk sehingga memperoleh waktu tambahan. Jika proses akan berhenti bertambah, swap menyelamatkan Anda. Jika proses tersebut terus menggunakan memori tanpa batas, swap mengubah gangguan selama lima detik menjadi stall selama dua puluh menit. Kondisi ini lebih buruk, karena proses yang berhenti masih menyisakan shell yang dapat digunakan, sedangkan sistem yang terus melakukan thrashing tidak.

swapon --show
free -h

Solusi yang praktis untuk VPS kecil adalah menggunakan swap file berukuran sedang untuk page yang dialokasikan sekali dan tidak pernah digunakan lagi, serta menetapkan MemorySwapMax=0 pada unit yang siap Anda korbankan. Service penting tetap menggunakan swap. Service yang tidak dapat diprediksi akan cepat mencapai batas lalu di-restart.

Menurunkan vm.swappiness adalah tuas yang lemah, dan penting untuk memahami alasannya. Pengaturan ini hanya menggeser keseimbangan antara mengeluarkan page cache dan melakukan swap pada anonymous page. Keduanya tetap memerlukan pembacaan dari disk pada waktu berikutnya. Pengaturan ini mengubah page mana yang mengalami thrashing, bukan menentukan apakah sistem akan mengalami thrashing.

Daemon OOM lebih awal menghentikan proses sebelum terjadi kemacetan

Kernel menunggu hingga reclaim gagal sepenuhnya. Pada VPS kecil, waktu tunggu tersebut adalah celah ketika mesin dapat kehilangan respons. Dua daemon ruang pengguna menutup celah ini dengan memantau memori sendiri dan menghentikan proses lebih awal.

earlyoom memeriksa memori yang tersedia dan swap bebas hingga sepuluh kali per detik. Daemon ini menghentikan proses dengan nilai oom_score tertinggi hanya jika keduanya turun di bawah ambang batasnya. Pada mesin tanpa swap, hanya ambang memori yang menentukan.

sudo apt install earlyoom
systemctl status earlyoom

Paket Debian dan Ubuntu memulai service saat instalasi. Opsi konfigurasinya 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 bebas. Keduanya secara default bernilai 10 persen. Angka kedua dalam setiap pasangan adalah titik pemicu SIGKILL. earlyoom mengirim SIGTERM setelah memori dan swap sama-sama berada di bawah nilai pertama. Kemudian, earlyoom mengirim SIGKILL setelah keduanya berada di bawah nilai kedua, yang secara default adalah setengah dari nilai pertama. Biarkan pola --avoid dan --prefer tanpa tanda kutip dan tanpa spasi. systemd meneruskan karakter kutip secara literal, sehingga pola yang diberi tanda kutip tidak pernah cocok. Terapkan perubahan dengan sudo systemctl restart earlyoom. Baca journalctl -u earlyoom untuk mengetahui proses yang dihentikan 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 proses tunggal. Karena itu, opsi ini menghentikan 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 image server, hasilnya sering kosong karena pengaturan ini harus diaktifkan secara eksplisit untuk setiap unit. Pilih salah satu daemon saja. Menjalankan keduanya membuat dua daemon berlomba memilih proses yang dihentikan, sehingga alasan penghentian 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"

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 di RAM saat proses tersebut dihentikan, sekitar 1.8 GB pada contoh ini. Baca nama dalam tanda kurung dengan hati-hati. Nama tersebut adalah proses yang dipilih kernel sebagai korban. Kernel memilih proses terbesar, tetapi proses tersebut tidak selalu menjadi penyebab kekurangan memori.

Kill 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 mencakup sebagian besar diagnosis. Memory cgroup out of memory berarti satu unit mencapai MemoryMax= yang Anda tetapkan, sedangkan sistem lainnya tidak bermasalah. Out of memory biasa berarti seluruh mesin kehabisan memori. Artinya, batas yang Anda tetapkan tidak ada atau jika dijumlahkan terlalu besar.

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 menyatakan hal yang sama dalam satu baris, sebagai Active: failed (Result: oom-kill).

Counter cgroup adalah sumber informasi ketiga dan satu-satunya 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 terkena 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 diam-diam yang dibahas sebelumnya: service tetap berjalan, melambat hingga hampir tidak dapat digunakan, 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 hanya disimpan di RAM. Semua baris akan hilang setelah reboot yang Anda perlukan 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 menjumlahkan semua batas hingga mencapai 2 GB penuh, karena setiap unit dapat mencapai penggunaan puncak pada saat yang sama. Berikan porsi terbesar kepada service yang paling penting, lalu batasi komponen lain yang bersifat spekulatif di sekitarnya.

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

Mempertahankan akses masuk memerlukan satu pengaturan tambahan. OOMScoreAdjust=-500 dalam drop-in untuk ssh.service membuat OOM killer global jauh lebih kecil kemungkinannya memilih daemon SSH Anda sebagai korbannya. Hal 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 menjadi korban. Pengaturan ini tidak memperpendek stall.

Container berjalan dalam cgroup-nya sendiri. 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 dari MemoryMax= dan CPUQuota= dibahas dalam mengatur 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 halaman, bukan berdasarkan lamanya proses tersebut. Saat memori terbatas, kernel mengeluarkan page cache, termasuk halaman executable program yang sedang berjalan, lalu membacanya kembali pada instruksi berikutnya. 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 dapat berjalan dalam sepuluh detik terakhir. Userspace daemon seperti earlyoom dapat menghentikan proses sebelum server mencapai kondisi tersebut.

Apa perbedaan antara MemoryHigh dan MemoryMax?

MemoryHigh= adalah batas lunak yang menerapkan throttling. Kernel melakukan reclaim secara agresif dari unit tersebut dan memperlambat alokasinya, tetapi penggunaan memori dapat melebihi angka tersebut dan tidak ada proses yang dihentikan. MemoryMax= adalah batas keras: alokasi yang tidak dapat dipenuhi di bawah 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. Kemudian 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.

Haruskah saya menambahkan swap ke VPS kecil?

File swap kecil membantu menangani cold pages yang dialokasikan sekali dan tidak pernah diakses lagi. Swap tidak membantu proses yang tidak terkendali: swap hanya menunda penghentian proses dan mengubah gangguan singkat menjadi stall panjang yang membuat Anda tidak dapat login untuk memperbaikinya. Gunakan swap dalam jumlah terbatas, lalu tetapkan MemorySwapMax=0 pada unit yang dapat Anda korbankan. Dengan begitu, unit tersebut mencapai batasnya dan segera restart, sementara service penting tetap dapat menggunakan swap.

Dapatkah saya 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 saat 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.