Cara Set Swappiness Linux: Panduan Lengkap Tuning RAM 2026

Jadi gini, kemarin sore aku lagi santai ngopi sithik, baru aja mau nutup jam kerja, eh masuk ticket. Server production lemot, user mulai komplain, dan yang bikin heran – RAM masih sisa 8GB dari 16GB. Aku cek satu-satu: CPU normal, disk normal, network normal. Terus piye? Akhirnya ketauan, ternyata Linux-nya lagi sibuk swap ke disk padahal RAM-nya nganggur legane. Aneh, to? Nah, dari situ aku makin gali soal swappiness, dan hasilnya aku tulis di sini.

Oke, sebelum lanjut – ini masalah yang bukan bumbu-bumbu aja. Kalau server kamu ngalamin hal yang sama, dampaknya nyata: aplikasi web makin lambat, query database kerasa berat, API response time membengkak, dan manajemen mulai tanya-tanya. Swap itu bukan barang jahat, kok. Tapi kalau kernel terlalu gampang swap pas RAM masih lega, kerjanya malah kontraproduktif. Ibaratnya, kamu punya dapur yang gede, tapi bukannya masak di dapur, kamu malah masak di garasi yang debunya numpuk. Gak efisien, to?

Nah, di sini kita bahas tuntas soal satu parameter kecil yang jarang dilirik: swappiness. Nggih, namanya emang aneh, tapi pengaruhnya ke responsivitas server itu gede banget. Aku bakal kasih langkah cek, cara set sementara sama permanen, plus rekomendasi nilai yang udah aku praktekin di berbagai workload – dari VPS web server sampai dedicated database. Semua perintah di sini udah aku tes di beberapa distro, jadi aman buat dipake.

Terus, sebenernya kenapa server bisa kejadian kayak gini? Ada beberapa pemicu umum. Pertama, nilai default kernel emang 60, artinya kernel cukup agresif buat mindahin halaman anon ke swap. Kedua, workload kayak database atau cache yang punya pola akses memori tinggi. Ketiga, kadang ada aplikasi yang memory leak, bikin mem pressure naik, lalu kernel main aman dengan buang halaman ke swap. Dan yang bikin gemes, fix-nya sebenernya simpel banget: cukup satu baris sysctl.

Swappiness itu sebenarnya apa sih?

Swappiness adalah parameter kernel yang ngatur seberapa agresif Linux pindahin halaman memori (anonymous pages) ke swap space. Nilainya dari 0 sampai 100, dan mulai kernel 5.8 bisa diset sampai 200. Makin gede angkanya, makin cepet dan makin banyak kernel pindahin data ke swap. Makin kecil, kernel makin sabar – data dibiarin di RAM selama masih muat.

Gampangnya gini: bayangin kamu kerja di meja yang super lebar. Meja itu RAM-mu, lemari di sebelah itu swap. Kalau kamu tipe yang rajin beres-beres, barang langsung dipindah ke lemari walau meja masih longgar – nah, itu swappiness tinggi. Kalau kamu tidak, barang dibiarkan di atas meja sampe meja bener-bener mepet. Mayoritas server lebih cocok sama gaya kedua: barang jangan dibuang dari meja selagi masih ada tempat.

Langkah 1 – Cek dulu nilai swappiness dan status swap mu

Jangan asal set. Cek dulu nilai sekarang dan seberapa banyak swap yang udah kepake. Buka terminal root atau sudo, terus jalanin:

cat /proc/sys/vm/swappiness
free -h
swapon --show

Kalau angka pertama keluar 60, berarti masih default. Perhatiin juga kolom swap di output free -h. Kalau swap usage udah menonjol padahal RAM masih sisa banyak, nah – itu pola yang tadi aku bilang. Swap kepake itu normal kok di server, yang jadi masalah justru kalau kepake-nya gak wajar.

Contoh output yang sering aku lihat di lapangan:

root@web:~# cat /proc/sys/vm/swappiness
60
root@web:~# free -h
               total        used        free      shared  buff/cache   available
Mem:           15Gi       5.2Gi       6.1Gi       120Mi       4.1Gi        9.8Gi
Swap:          4.0Gi       1.9Gi       2.1Gi

Nah, 1.9Gi swap kepake padahal available masih 9.8Gi. Jelas kernel-nya keburu nge-swap. Pola kayak gini biasa muncul di server yang masih default-abis, apalagi habis upgrade distro yang bawa workload lebih rame dari sebelumnya.

Langkah 2 – Set swappiness langsung, tanpa restart

Ubah nilainya sekarang juga biar kernel langsung ngerti:

sysctl -w vm.swappiness=10

Verifikasi terus:

sysctl vm.swappiness
vm.swappiness = 10

Angka ini langsung berlaku tapi gak persist. Cocok buat uji coba dulu: jalanin satu dua hari, pantau pakai free -h, atur lagi kalau dirasa perlu. Nek pas, lanjut ke langkah berikutnya biar permanen.

Langkah 3 – Bikin permanen biar gak balik lagi pas reboot

Biar nilai ini bertahan, taruh di konfigurasi sysctl. Cara paling rapi di distro modern: bikin file baru di /etc/sysctl.d/. Kalau file itu belum ada, buat aja:

nano /etc/sysctl.d/99-swappiness.conf

Isi satu baris:

vm.swappiness = 10

Simpen, terus reload:

sysctl --system

Kenapa nama file diawali angka 99? Karena /etc/sysctl.d dibaca urut abjad, jadi 99 memastikan nilai kita menang di atas file bawaan distro kayak 50-default.conf di Ubuntu. Setelah reload, verifikasi lagi, dan cek juga habis reboot buat mastiin nilainya bener-bener nempel.

Rekomendasi nilai swappiness per workload

Ini yang paling sering ditanyain: berapa sih yang pas? Jawabannya tergantung workload. Tapi ini patokan yang aku pake dan udah terbukti di lapangan, termasuk buat setup cPanel yang gampang kena pola load tinggi – aku bahas lebih detail di artikel troubleshoot high load cPanel:

Catatan penting: hati-hati sama swappiness=0

Banyak artikel lama nyaranin 0 karena di kernel lama artinya beda. Sekarang cara kerjanya udah berubah, dan kalau kamu gak paham konteksnya, malah bakal bikin bug yang susah dilacak. Nilai aman yang sering aku pakai: 10 buat serba-bisa, 1 buat database dedicated. Jangan lupa selalu tes dulu di staging sebelum nyentuh production.

Jangan lupa barengi dengan setting memori lain

Swappiness doang gak akan nolong kalau zona memori-mu kacau. Kalau mau lebih dalam, perhatiin juga vm.min_free_kbytes – cadangan halaman bebas buat kernel – sama vm.vfs_cache_pressure buat cache inode dan dentry. Biasanya aku set min_free_kbytes sekitar 1-3 persen dari total RAM, tapi sesuaikan sama kebutuhan. Ini masih nyambung sama topik yang aku tulis di artikel bedah memory leak server Linux, dan kalau nilai swappiness tiap reboot gak konsisten, cek juga file konfigurasi di /etc/sysctl.conf.

Troubleshooting: gejala, penyebab, dan perbaikan

Catatan kecil buat yang jalanin database di VPS RAM terbatas: kalau kamu sering kena crash karena memory, kombinasi swappiness rendah dengan setting MySQL yang bener bisa nolong banget. Baca juga artikel cara fix MySQL crash di VPS RAM kecil biar lengkap. Dan jangan lupa, kalau mau pantau efek tuning ini, saran aku pasang pantau memory pakai Netdata dan Grafana biar keliatan trennya dalam seminggu.

FAQ

Udah sih, itu aja. Bookmark artikel ini buat referensi pas lagi tuning server berikutnya, dan coba dulu di staging atau mesin yang gak kritis. Nek ada pengalaman beda atau pertanyaan, drop di komentar ya – sopo ngerti iso nolong temen-temen lain. Matur nuwun wis mampir, lan ojo lali nyimpen backup dulu sebelum ngoprek apa-apa. Santai aja, bakal kelar.