VPS RAM Kecil Sering Kena OOM Killer? Pasang zram Sebelum Upgrade

1 GB RAM terasa cukup sampai container kedua dijalankan. Setelah itu, satu proses yang memori-nya naik pelan-pelan akan memaksa kernel memilih korban: proses itu dibunuh tanpa peringatan, dan yang tersisa di log cuma satu baris Killed process. Di VPS kecil, zram di VPS sering jadi selisih antara server yang bertahan dan layanan yang mati sendiri tengah malam.

Oke, lanjuutt.. kita bahas dulu kenapa hal ini terjadi, lalu pasang zram dengan benar dan tuning supaya benar-benar dipakai.

Kenapa VPS kecil gampang kena OOM Killer

OOM Killer bukan bug, tapi mekanisme pengaman terakhir. Saat kernel sudah tidak punya halaman memori bebas dan tidak ada swap yang bisa dipakai, ia harus membunuh sesuatu supaya sistem tidak mati total. Yang dibunuh biasanya proses dengan skor tertinggi — sering justru aplikasi paling rakus memori, kadang proses yang salah.

Ada tiga pola yang berulang di VPS kecil:

Page cache ikut terpakai. File yang dibaca aplikasi (log, aset, cache) menempati RAM. Sebagian bisa dilepas kernel, tapi aplikasi tetap butuh memori anonim untuk heap dan stack.
Tidak ada swap sama sekali. Banyak image VPS dikirim tanpa swap file. Begitu RAM penuh, tidak ada ruang untuk memindahkan halaman yang jarang dipakai.
Batas container tidak dihitung. Docker Compose tanpa mem_limit membuat tiap container beranggapan seluruh RAM host miliknya.

Cara memastikan itu benar-benar OOM

Sebelum menambah apa pun, baca buktinya:


free -h
swapon --show
sudo journalctl -k --since "-24 hours" | grep -i -E 'out of memory|killed process'

Kalau swapon --show kosong dan log menampilkan Out of memory: Killed process ..., penyebabnya sudah pasti. Catat juga nama prosesnya — kalau yang dibunuh berulang kali adalah database, masalah sebenarnya adalah RAM-nya kurang, bukan swap yang tidak ada.

Apa itu zram dan bedanya dengan swap file

zram adalah perangkat blok yang hidup di dalam RAM: setiap halaman yang ditulis ke sana dikompresi lebih dulu, lalu disimpan di memori. Karena tidak ada disk yang terlibat, latensinya jauh lebih rendah daripada swap file di SSD, dan tidak ada I/O yang menggerus kuota disk VPS.

Panduan zram ArchWiki memakai asumsi konservatif rasio kompresi 1:2 (data dunia nyata sering 1:3), dan karena itu membuat perangkat zram lebih besar dari dua kali ukuran RAM dianggap mubazir — isinya akan memakan lebih banyak RAM daripada yang tersedia. Perangkat zram yang baru dibuat tidak memesan RAM sama sekali; memorinya baru terpakai saat ada halaman yang benar-benar ditulis ke sana.

Analogi sederhananya: swap file itu seperti menyewa gudang di seberang jalan — muat banyak, tapi setiap pengambilan barang butuh jalan kaki. zram seperti memadatkan kardus di dalam rumah: ruangnya terbatas, tapi aksesnya instan. Yang perlu diingat, keduanya tidak menambah RAM fisik — zram hanya memperpanjang napas.

Pasang zram di VPS Ubuntu atau Debian

Kita pakai systemd-zram-generator, paket resmi yang tersedia di Ubuntu 24.04 (versi 1.1.2) dan Debian 12 maupun 13. Tidak perlu skrip udev buatan sendiri, cukup satu file konfigurasi.

Cek kondisi awal. Jalankan free -h, swapon --show, dan zramctl. Kalau zramctl tidak mengeluarkan apa pun, berarti belum ada perangkat zram. Pastikan paketnya ada di repo: apt policy systemd-zram-generator.

Pasang paketnya.


   sudo apt update
   sudo apt install -y systemd-zram-generator

Tulis konfigurasi. Buat /etc/systemd/zram-generator.conf:


   [zram0]
   zram-size = ram
   compression-algorithm = zstd
   swap-priority = 100

Penjelasan tiap baris:

zram-size menerima ekspresi matematika dengan variabel ram (nilai MemTotal dalam MB). Bawaannya min(ram / 2, 4096), artinya VPS 1 GB hanya dapat perangkat 512 MB. Untuk RAM 1–2 GB, zram-size = ram lebih masuk akal karena rasio kompresi 2:1 membuat isi penuh 1 GB hanya memakai sekitar 512 MB RAM.
compression-algorithm kita set eksplisit ke zstd supaya hasilnya tidak bergantung pada default distro. Daftar algoritma yang tersedia bisa dibaca dari /sys/block/zram0/comp_algorithm.
swap-priority bawaannya memang 100, ditulis di sini supaya zram selalu dipakai lebih dulu daripada swap file biasa yang prioritasnya lebih rendah.

Aktifkan. Generator systemd akan membuat unit dari file konfigurasi tadi:


   sudo systemctl daemon-reload
   sudo systemctl start /dev/zram0

Tidak perlu systemctl enable — generator berjalan otomatis saat boot selama file konfigurasinya ada.

Verifikasi. Ketiga perintah ini harus menunjukkan hasil yang konsisten:


   zramctl
   swapon --show
   free -h

zramctl menampilkan nama perangkat, algoritma (zstd), dan ukuran disk; swapon --show menampilkan satu baris /dev/zram0 dengan PRIO 100; free -h menampilkan kolom Swap yang tidak lagi nol.

Kalau perlu mengubah atau mematikan zram

Ubah nilainya di file konfigurasi, lalu jalankan ulang unitnya. Untuk mematikan sama sekali:


sudo swapoff /dev/zram0
sudo systemctl stop [email protected]

Hapus juga file /etc/systemd/zram-generator.conf kalau tidak ingin perangkatnya dibuat lagi saat boot berikutnya.

Tuning sysctl supaya zram benar-benar dipakai

Masalah yang sering muncul setelah zram terpasang: perangkatnya ada, tapi DATA di zramctl tetap 0. Penyebabnya bukan zram, melainkan kernel yang belum terdorong memindahkan halaman ke sana. ArchWiki merangkum setelan yang biasa dipakai:


vm.page-cluster = 0
vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.swappiness = 100

Terapkan dengan sudo sysctl --system, lalu periksa satu per satu, misalnya sysctl vm.page-cluster.

Dua setelan yang paling terasa efeknya:

vm.page-cluster = 0 membuat kernel membaca dan menulis satu halaman per operasi swap, bukan beberapa halaman sekaligus. Pada disk, penggabungan I/O itu menguntungkan; pada zram yang tidak punya waktu seek, menggabungkan justru menambah latensi.
vm.watermark_boost_factor = 0 mematikan lonjakan agresif saat memori menipis, sehingga reclaim berjalan lebih tenang.

Untuk vm.swappiness, ArchWiki memakai 180 karena swap-nya ada di RAM dan murah. Kita mulai dari 100 supaya lebih konservatif; kalau setelah beberapa hari DATA masih kecil padahal RAM sering di atas 80%, naikkan bertahap dan bandingkan hasilnya sendiri, bukan menyalin angka dari panduan mana pun.

Lapis kedua: swap file kecil sebagai jaring pengaman

zram cepat, tapi ruangnya terbatas oleh RAM. Kalau isinya sudah penuh dan masih ada tekanan, tanpa lapis kedua kernel kembali ke OOM Killer. Swap file kecil menutup celah itu — lambat, tapi lebih baik daripada proses dibunuh.


sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon --priority 10 /swapfile

Supaya aktif lagi setelah reboot, tambahkan ke /etc/fstab:


/swapfile none swap sw,pri=10 0 0

Prioritas 10 sengaja lebih rendah dari zram (100), jadi kernel memakai zram lebih dulu dan swap file hanya tersentuh saat benar-benar perlu. Dua catatan: cek dulu ruang disk dengan df -h /, dan kalau filesystem-nya Btrfs, fallocate tidak bisa dipakai untuk swap — gunakan sudo btrfs filesystem mkswapfile --size 1g /swapfile.

Kapan zram tidak menolong

Jujur saja, zram bukan obat untuk semua VPS kecil. Ada empat situasi di mana hasilnya mengecewakan:

Datanya tidak bisa dikompresi. Foto, arsip ZIP, dan dump database yang sudah padat hampir tidak menyusut. Statistik huge_pages di /sys/block/zram0/mm_stat menunjukkan berapa banyak halaman yang masuk kategori ini. Kalau angkanya besar, zram hanya menambah beban CPU.
CPU-nya sudah tipis. Kompresi dan dekompresi memakai CPU. Di VPS 1 vCPU yang sedang menjalankan build atau crawl, zram bisa membuat semuanya terasa lebih lambat.
Aplikasinya jalan di container LXC. Container memakai kernel host, dan swapon di dalam container umumnya ditolak. Untuk setup seperti ini, konfigurasi zram di host Proxmox, bukan di dalam container.
Kebutuhannya memang RAM nyata. Database dengan buffer pool besar harus tinggal di RAM fisik. Kalau setelah zram dan swap file OOM masih muncul, itu sinyal untuk menaikkan paket VPS — bukan menambah trik.

Cara membaca hasilnya setelah beberapa hari

Jangan menilai dari perasaan “sepertinya lebih ringan”. Dua perintah ini memberi angka:


zramctl
cat /sys/block/zram0/mm_stat

Pada mm_stat, kolom pertama adalah orig_data_size (ukuran data sebelum dikompresi) dan kolom kedua compr_data_size (setelah dikompresi). Bagi angka pertama dengan kedua: kalau hasilnya sekitar 2, kompresi bekerja seperti yang diharapkan. Kalau mendekati 1, isi zram praktis tidak menyusut dan kita sedang membuang CPU.

Yang juga layak dipantau adalah apakah Killed process sudah tidak muncul lagi di journalctl -k. Itu indikator paling jujur, jauh lebih jujur daripada grafik memori yang terlihat lega karena halaman dipindahkan ke zram.

Kesimpulan

OOM Killer di VPS kecil biasanya bukan tanda aplikasi kita buruk, tapi tanda tidak ada tempat untuk memindahkan halaman yang jarang dipakai. zram mengisi kekosongan itu dengan cara yang murah: kompresi di dalam RAM, tanpa I/O disk, tanpa biaya bulanan tambahan. Dengan systemd-zram-generator, satu file konfigurasi dan tiga perintah sudah cukup, lalu tuning vm.page-cluster yang membuatnya benar-benar terpakai.

Batasnya tetap ada dan sebaiknya diakui: zram memperpanjang napas, bukan menambah paru-paru. Kalau setelah semua ini server masih kehabisan memori, tidak ada konfigurasi yang bisa menggantikan RAM yang memang kurang. Tapi untuk banyak VPS 1–2 GB yang selama ini mati diam-diam tiap malam, satu perangkat zram bisa jadi perbaikan paling murah yang pernah kita pasang. Selamat mencoba, dan semoga log-nya bersih malam ini.