Tune Linux Swappiness: Panduan Lengkap Step-by-Step 2026

Skip basa-basi. Server kamu OOM killer aktif terus, swap usage tinggi padahal RAM masih ada, atau performa nge-drop tiba-tiba pas traffic naik?-fix-nya mungkin cuma satu baris: vm.swappiness. Gak percaya? Yuk langsung gas ke langkah-langkahnya.

Kenapa Harus Peduli Sama Swappiness?

Jadi gini, swappiness itu parameter kernel yang ngatur seberapa agresif Linux muter data antara RAM dan swap disk. Default-nya kebanyakan distro itu 60. Angka itu artinya kernel bakal mulai geser halaman ke swap relatif awal — bahkan sebelum RAM bener-bener kepake habis. Untuk desktop, ini gak masalah. Tapi buat server production? Bisa jadi masalah besar. Karena kalau proses yang harusnya di RAM malah digeser ke swap disk yang jauh lebih lambat, performa aplikasi langsung jeblok. web server jadi lemot, database query lambat, dan yang paling bikin panik: OOM killer tiba-tiba ngebunuh process penting kayak MySQL atau PHP-FPM.

Masalahnya ini sering kali gak keliatan langsung. Kamu gak dapat alert bahwa server mulai swap-heavy. Yang kamu tau cuma tiba-tiba user komplain website lemot, atau monitoring kamu nampilin response time yang naik drastis. Padahal kalau kamu cek free -h, swap usage-nya udah 80%. Dan ya, itu bikin pusing. Apalagi kalau servernya VPS dengan storage SSD yang IOPS-nya terbatas — setiap write ke swap itu makan resource disk juga.

Kapan sih swappiness perlu di-tune? Pertama, kalau kamu punya server dengan RAM cukup besar (8GB ke atas) dan kamu mau maximize penggunaan RAM sebelum masuk swap. Kedua, kalau kamu pakai database server kayak MySQL, PostgreSQL, atau Redis yang sangat bergantung pada RAM. Ketiga, kalau kamu pakai container seperti Docker atau Kubernetes di mana kamu sudah size RAM sesuai kebutuhan dan swap cuma bikin performa lebih buruk. Keempat, kalau server kamu jadi victim OOM killer yang sering bunuh process penting — seting swappiness lebih rendah bisa kasih waktu lebih lama sebelum OOM trigger.

Apa Itu vm.swappiness dan Bagaimana Cara Kerjanya?

Oke, biar lebih jelas. vm.swappiness itu punya rentang nilai dari 0 sampai 200. Yup, 200 — bukan cuma 100 seperti yang banyak orang kira. Di rentang 0-100, angka yang lebih tinggi artinya kernel lebih agresif geser data ke swap. Di atas 100, kernel bakal prioritaskan swap over RAM bahkan untuk page yang baru dipake. Nilai 0 bukan berarti gak pernah swap — kernel masih bisa swap kalau tekanan memory udah kritis, tapi dia bakal pake swap sebagai last resort. Nilai default 60 itu dianggap balanced untuk desktop usage.

Di container dan virtualisasi environment, banyak yang set swappiness ke 10 atau bahkan 1. Karena di situ RAM udah di-alokasi khusus buat container tertentu, dan kalau container mulai swap, performa aplikasi di dalamnya langsung drop. Di sisi lain, kalau kamu set swappiness ke 0 di environment yang RAM-nya terbatas, kamu bisa dapetin OOM killer yang lebih sering muncul karena kernel gak punya opsi fallback ke swap sebelum ngebunuh process.

Cara Cek Swappiness Saat Ini

Sebelum kamu ubah apapun, cek dulu nilai sekarang:

cat /proc/sys/vm/swappiness

Atau pakai cara yang lebih friendly:

sysctl vm.swappiness

Output-nya biasanya angka 60 di kebanyakan distro. Sekarang cek juga actual swap usage di server kamu:

free -h

Perhatiin kolom swap — kalau used-nya udah mendekati total, itu tanda swappiness kamu perlu di-tune. Atau kalau mau lebih detail, pakai swapon --show buat lihat ukuran dan usage tiap swap partition/file.

3 Cara Tune Swappiness di Linux

Metode 1: Temporary (Hilang Saat Reboot)

Cocok buat testing. Kamu langsung set dan lihat dampaknya:

sudo sysctl -w vm.swappiness=10

Langsung aktif. Gak perlu reboot. Tapi begitu server restart, balik ke default lagi. Gunanya buat experiment — set ke 10, monitor beberapa jam, lihat apakah performa membaik atau malah muncul OOM. Kalau hasilnya oke, lanjut ke metode permanen.

Metode 2: Permanent via /etc/sysctl.conf

Ini cara yang paling umum dipake. Edit file sysctl.conf:

sudo nano /etc/sysctl.conf

Tambahin baris ini di akhir file:

vm.swappiness = 10

Save, lalu apply:

sudo sysctl -p

Verifikasi:

cat /proc/sys/vm/swappiness

Harusnya sekarang tampil 10. Dan ini bakal survive reboot. Selesai.

Metode 3: via sysctl.d (Recommended untuk Modern Distros)

Di distro terbaru, lebih clean pakai sysctl.d:

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf

sudo sysctl --system

Kenapa lebih bagus? Karena gak nyampur sama config lain di /etc/sysctl.conf. Lebih modular, lebih gampang di-maintain, dan kalau kamu perlu rollback, tinggal hapus file-nya. Ini best practice yang aku pake di semua server yang aku handle.

Nilai Swappiness yang Direkomendasikan

Setelah Tune: Monitoring yang Wajib Dilakukan

Ubah swappiness itu gak selesai di situ. Kamu WAJIB monitor dampaknya. Yang pertama, cek swap usage berkala:

watch -n 5 'free -h'

Jalankan ini beberapa jam setelah perubahan. Kalau swap usage tetap rendah dan gak ada OOM killer di dmesg, berarti setting kamu works. Kalau muncul OOM, berarti swappiness kamu terlalu rendah untuk kondisi server itu.

Yang kedua, cek log kernel untuk OOM events:

sudo dmesg | grep -i "out of memory"

Atau di systemd-based distro:

sudo journalctl -k | grep -i "out of memory"

Kalau gak ada output, bagus. Kalau ada? Kamu perlu naikin swappiness sedikit — coba 20 atau 30, terus monitor lagi. Dan yang ketiga, kalau kamu pakai monitoring tool seperti Netdata atau Grafana, set alert buat swap usage di atas 50%. Biar kamu tau lebih awal sebelum jadi masalah.

Troubleshooting: Kalau Sudah Tune tapi Masalah Belum Kelar

Kalau kamu udah tune swappiness tapi swap masih tinggi, masalahnya mungkin bukan di swappiness. Cek ini dulu:

1. RAM beneran habis? Jalankan ps aux --sort=-%mem | head -20 buat lihat proses mana yang paling banyak makan RAM. Kalau ada proses yang consume 50%+ RAM, itu masalahnya — bukan swappiness.
2. Memory leak? Cek smem -t -k -s pss untuk lihat real memory usage per process. Kalau ada angka yang terus naik tiap jam, ada leak.
3. HugePages aktif? Di database server, hugepages bisa bikin memory usage terlihat lebih tinggi dari kenyataan. Cek dengan grep HugePages /proc/meminfo.
4. VM overcommit? Cek cat /proc/sys/vm/overcommit_memory. Kalau nilainya 1, kernel boleh alokasi RAM melebihi kapasitas fisik — ini bisa bikin OOM lebih sering muncul.

Semua itu bisa kamu cek sendiri. Dan kalau udah ketemu root cause-nya, swappiness tuning bakal jauh lebih efektif karena kamu udah address masalah aslinya dulu.

Best Practice untuk Production Server

Oke, ini checklist cepat yang aku pake di production:

1. Set vm.swappiness = 10 sebagai default untuk semua production server
2. Untuk database server (MySQL/PostgreSQL), set ke 1 kalau RAM-nya sufficient (16GB+)
3. Untuk Redis, set ke 1 — in-memory database gak boleh swap
4. Selalu monitor swap usage minimal 48 jam setelah perubahan
5. Set up alert kalau swap usage > 50%
6. Di container environment, set swappiness di host, bukan di dalam container
7. Dokumentasi semua perubahan swappiness di CMDB atau catatan server
8. Test di staging environment dulu sebelum apply ke production

Oh ya, satu hal lagi. Kalau kamu pakai VPS dengan NVMe SSD, swap usage yang tinggi itu bisa geser lifespan SSD kamu karena write amplification. Jadi set swappiness rendah itu bukan cuma soal performa — tapi juga soal hardware longevity.

Internal Links Terkait

• Optimasi Performa Server Linux secara Menyeluruh
• Cara Fix OOM Killer di Linux Production
• Setup Monitoring Server dengan Netdata dan Grafana
• Best Practice Memory Limit untuk Docker Container

Yaudah, itu aja. Tune swappiness, monitor selama 48 jam, set alert. Kalau semua oke, case closed. Simpel kan? Praktekin langsung ya, dan jangan lupa dokumentasiin setiap perubahan yang kamu bikin di server. Semangat!