Tuning Dirty Ratio Page Cache Linux untuk Server Production: Panduan Lengkap Step-by-Step

Tolong ya, jangan asal ngutak-atik vm.dirty_ratio kalau sampeyan belum bener-bener ngerti konsekuensinya. Bukan maksudku menggurui, tapi aku udah dua kali nemu server production yang malah tambah parah habis pemiliknya naikin angka dirty ratio ke level ekstrem biar katanya kinerjanya nambah. Hasilnya? Bukan cuma risiko data loss yang naik, tapi IO jadi makin jelek dan MySQL makin sering ngambek di jam sibuk. Aku capek, dan sampeyan bakal ngerasain capek yang sama kalau ngalamin hal kayak gini.

Ini bukan artikel teori dari buku. Ini catatan dari pengalaman nyata, dari server yang beneran kena masalah karena tuning yang salah. Dan jujur, aku capek liat kasus yang sama berulang terus. Jadi baca pelan-pelan, pahami dulu, baru set apa-apa. Jangan cuma copy-paste command terus klaim beres, karena iki justru awal dari bencana.

Apa Itu Dirty Ratio Page Cache Linux dan Kenapa Salah Set Itu Bahaya

Oke, samain persepsi dulu. Yang disebut dirty page di Linux itu data yang udah diubah sama aplikasi, tapi belum ditulis ke storage fisik. Linux nyimpen dulu di page cache, terus nulis ke disk nanti-nanti lewat mekanisme writeback. Kernel bakal nge-flush data ini pas ada pemicu: batas dirty_ratio kedorong, umur data lewat dirty_expire_centisecs, atau ada memory pressure. Sistem ini sebenernya bagus banget, karena bikin operasi tulis kerasa cepet banget. Masalahnya baru muncul pas tuning-nya nggak nyambung sama karakteristik workload di server kamu.

Contoh paling umum yang sering aku temuin: server database dengan RAM gede, dirty pages numpuk puluhan GB, terus tiba-tiba kernel flush semuanya sekaligus dalam hitungan detik. Disk yang tadinya santai tiba-tiba kena beban maksimal. Write latency melonjak, query mulai ngantri, semua berasa lag. Admin baru biasanya langsung nuduh MySQL, padahal pelakunya ada di lapisan kernel, tepatnya di kebijakan writeback yang salah set.

Terus kenapa tuning ini gampang salah? Karena gampang banget ketipu angka. Banyak yang liat RAM 64GB, terus mikir yaudah set dirty_ratio 50 biar cache-nya gede kan cepet. Kelihatan masuk akal, tapi realitanya kebalikan: makin gede angka dirty ratio, makin banyak data numpuk, dan pas tiba waktunya flush, burst-nya makin gede. Kalau storage kamu HDD jadul atau SSD entry-level, burst kayak gini bisa bikin IO wait tembus 100% dan server nyaris frozen. Ditambah lagi risiko data loss pas crash, karena dirty pages yang belum ditulis bakal lenyap begitu power putus. Dan kalian tahu sendiri, ngejelasin data loss ke client itu bukan pengalaman yang menyenangkan.

Langkah 1: Cek Kondisi Server Kamu Sekarang

Sebelum ngubah apa-apa, lihat dulu kondisi sekarang. Jangan asal set, nanti bingung sendiri. Nih, cek tiga hal ini dulu: berapa dirty pages yang lagi numpuk, nilai sysctl saat ini, dan aktivitas disknya.

cat /proc/meminfo | grep -i dirty

Perhatiin baris Dirty di output. Contohnya gini:

Dirty: 1485824 kB

1485824 kB itu sekitar 1.4GB data yang belum ditulis ke disk. Nggak selalu masalah, tapi kalau angka ini terus-terusan gede di server database, waktunya waspada. Lanjut, cek nilai sysctl yang sekarang aktif:

sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs vm.dirty_writeback_centisecs

Outputnya kira-kira begini di kebanyakan distro:

vm.dirty_background_ratio = 10
vm.dirty_ratio = 20
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500

Nilai ini default dari kernel. Belum tentu salah, tapi juga belum tentu cocok sama workload kamu. Itu yang nanti kita sesuaikan bareng-bareng.

Langkah 2: Pahami Empat Knob Utama Biar Nggak Asal Set

Intinya gini: background ratio itu garis mulai kerja, dirty ratio itu garis batas maksimal. Kalau keduanya kegedean, data numpuk banyak dan pas flush jadi ledakan. Kalau kekecilan, kernel kebanyakan bangun dan disk malah kebanjiran request kecil-kecil. Dua-duanya jelek, cuma beda rasa aja. Lha iki nih yang bikin admin bingung — nilai yang ‘kelihatan gede’ justru yang bikin disk paling kewalahan.

Langkah 3: Kenali Workload Kamu Dulu

Nggak ada angka sakti yang berlaku buat semua server. Yang aku lakuin selalu sama: tanya dulu server ini ngapain. Server database kayak MySQL atau PostgreSQL itu sifatnya heavy write, jadi dirty pages-nya harus dijaga pendek. File server atau backup storage justru bisa lebih longgar. Web server statis malah hampir nggak kepengaruh sama tuning ini.

Terus, lihat juga storage-nya. NVMe bisa nelen flush besar tanpa kedip. HDD atau SSD SATA entry-level nggak sanggup. Kalau sampeyan nggak tahu server kamu di atas disk apa, jalanin ini dulu:

lsblk -d -o NAME,ROTA,MODEL,SIZE

Kolom ROTA yang nilainya 1 berarti HDD, 0 berarti SSD. Ini penting banget, karena nilai tuning buat HDD dan SSD itu beda jauh. Ini yang sering dilompati orang, padahal di sini justru akar masalahnya sering muncul.

Langkah 4: Set Nilai yang Aman dan Terbukti di Lapangan

Ini yang sering aku pakai di lapangan. Bukan nilai ekstrem, tapi nilai yang bikin writeback anteng dan disk nggak kejutan:

Buat server database di HDD yang lagi bermasalah, aku biasanya set gini. Tulis di /etc/sysctl.d/99-dirty-tuning.conf:

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500

Lalu biar langsung aktif tanpa reboot:

sysctl -p /etc/sysctl.d/99-dirty-tuning.conf

Kalau masih ragu dan mau nyoba dulu tanpa persist, pakai sysctl -w. Tapi inget, ini cuma berlaku sampai reboot, jadi jangan lupa tulis ke file kalau udah yakin.

Langkah 5: Verifikasi Hasil Setelan Kamu

Setelah di-apply, cek lagi apakah nilainya benar-benar kebaca sama kernel:

sysctl vm.dirty_background_ratio vm.dirty_ratio
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Terus pantau aktivitas disknya. Kalau sebelumnya IO wait sering nembak 100%, sekarang seharusnya lebih landai. Cek pakai vmstat sambil ngejalanin beban:

vmstat 2 30

Perhatiin kolom wa (wait) dan bi (blocks in) / bo (blocks out). Kalau bo nggak lagi nembak-nembak gede, berarti writeback-nya udah lebih merata. Untuk server database, cek juga query yang tadinya ngantri. Seharusnya beda kerasa. Kalau nggak berubah sama sekali, berarti masalahnya mungkin bukan di sini — jangan maksa.

Langkah 6: Kapan Pakai dirty_bytes sebagai Ganti Ratio

Ratio itu dihitung dari persentase total RAM. Di server RAM gede, 5% aja bisa 3GB. Di VPS RAM 1GB, 10% cuma 100MB — nyaris nggak ada artinya, dan kernel bakal kebanyakan bangun. Buat kasus kayak gini, mending pakai dirty_bytes dan dirty_background_bytes yang angkanya absolut:

vm.dirty_background_bytes = 104857600
vm.dirty_bytes = 209715200

Itu artinya background flush mulai pas dirty pages nyentuh 100MB, dan batas kerasnya di 200MB. Angka ini cocok banget buat VPS kecil atau server yang write-nya nggak gede-gede amat. Tapi perhatiin: kamu nggak bisa pakai ratio dan bytes barengan. Kalau salah satu diset, yang lain otomatis dinonaktifkan. Jangan sampe dua-duanya kamu set, nanti kernel-nya bingung dan hasilnya malah aneh.

Troubleshooting: Gejala, Penyebab, Solusi

Pro Tips dan Hal yang Sering Dilupakan

• Selalu catat nilai default sebelum ngubah. Jalanin sysctl -a | grep dirty sebelum dan sesudah, biar ada bukti kalau-kalau butuh rollback.
• Ubah di window maintenance atau trafik rendah, terus pantau minimal seminggu. Jangan sekali set langsung lupa.
• Buat server database, lihat juga tuning lain kayak tuning MySQL InnoDB buffer pool biar hasilnya maksimal dan dua lapisan ini jalan barengan.
• Kalau server masih lelet setelah tuning ini, jangan dipaksa. Cek troubleshoot high load server buat langkah yang lebih lengkap.
• dirty_ratio dan dirty_background_ratio cuma salah satu potongan teka-teki performa disk. Yang lain kayak I/O scheduler dan filesystem mount options juga ngaruh, jadi jangan fokus ke satu titik aja.
• Kalau mau pemantauan yang proper, mulai dari monitoring disk IO di Linux dulu biar ada baseline sebelum tuning. Nggak bisa tau berhasil kalau nggak pernah ukur sebelum-sebelumnya.

Kesimpulan

Tuning dirty ratio page cache itu bukan soal ngejar angka gede biar keliatan pro. Ini soal bikin writeback jalan santai, disk nggak kejutan, dan data nggak numpuk berbahaya. Mulai dari cek kondisi, kenali workload, set nilai yang masuk akal, verifikasi, terus pantau. Prosesnya pelan, tapi hasilnya stabil.

Tolong ya, jangan ngulang kesalahan yang sama. Jangan asal naikin dirty ratio cuma karena baca forum, tanpa ngerti workload dan storage kamu. Pahami dulu, pantau terus, dan pelajari dampaknya baik-baik. Take it seriously — karena pas data ilang, bukan aku yang tanggung jawabnya, tapi production server kamu sendiri. Monggo, dipraktekin dengan hati-hati.