Mengira RAM Server Hampir Habis Gara-Gara Kolom free di Output free -m Kecil

Banyak orang menjalankan free -m, melihat kolom free tinggal beberapa ratus MB dari total beberapa GB, lalu menyimpulkan server butuh upgrade RAM. Reaksi ini wajar, karena kolomnya memang bernama free. Masalahnya, di Linux kolom itu hampir tidak pernah jadi angka yang tepat untuk menilai apakah memori cukup. Gambaran yang lebih jujur ada di kolom available, ditambah beberapa tanda lain seperti aktivitas swap dan log OOM. Artikel ini membahas empat anggapan yang sering muncul soal memori Linux. Untuk tiap anggapan, kita lihat kenapa terasa benar dan apa yang sebenarnya terjadi di kernel.

Kolom free kecil bukan berarti RAM hampir habis

Anggapan ini terasa benar karena logikanya sederhana: free artinya kosong, kosongnya sedikit, berarti hampir penuh. Cara pikir ini cocok di banyak sistem lain, tapi tidak di Linux. Kernel Linux sengaja memakai RAM yang sedang menganggur sebagai page cache. Page cache adalah salinan isi file dari disk yang baru dibaca atau ditulis. Ada juga buffers, yaitu cache untuk metadata block device. Keduanya dijumlah di kolom buff/cache. Saat PHP membaca file script, MySQL membaca tabel, atau web server mengirim gambar statis, isi file itu disimpan di RAM. Akses berikutnya tidak perlu menyentuh disk lagi. Dari sudut pandang kernel, RAM yang benar-benar kosong adalah RAM yang terbuang. Jadi di server yang sudah lama menyala, kolom free kecil justru normal. Saat aplikasi butuh memori tambahan, kernel mengambil kembali sebagian cache tersebut dan memberikannya ke aplikasi. Proses ini disebut reclaim. Karena itu, angka yang perlu dilihat adalah kolom available. Kolom ini adalah perkiraan kernel tentang berapa memori yang masih bisa dipakai aplikasi baru tanpa harus swap. Isinya kira-kira memori yang benar-benar kosong ditambah bagian cache yang aman dilepas. Angkanya diambil dari field MemAvailable di /proc/meminfo. Di versi free yang lebih lama, kolom ini belum ada dan perannya diwakili baris -/+ buffers/cache. Di meja support, pertanyaan ini sering muncul setelah orang melihat grafik monitoring yang menghitung cache sebagai memori terpakai. Grafiknya tampak merah, padahal available masih lega. Langkah pertama yang biasanya kita cek adalah kolom available, bukan free.

Tidak semua buff/cache bisa dilepas begitu saja

Setelah paham poin pertama, banyak orang langsung mengoreksi ke arah sebaliknya. Rumusnya jadi free ditambah buff/cache sama dengan memori yang tersedia. Rumus ini terasa masuk akal, tapi terlalu optimis. Ada beberapa jenis memori yang dihitung di buff/cache tapi tidak bisa dibuang seketika:

Shared memory dan isi tmpfs, misalnya /dev/shm atau /tmp yang di-mount sebagai tmpfs. Datanya hidup di RAM dan tidak punya salinan di disk, jadi kernel tidak bisa membuangnya. Paling jauh, kernel bisa memindahkannya ke swap. Nilainya terlihat di kolom shared pada free dan field Shmem di /proc/meminfo.
Dirty page, yaitu cache yang isinya sudah diubah tapi belum ditulis ke disk. Halaman ini harus di-flush dulu sebelum bisa dilepas, dan proses flush butuh waktu serta I/O.
Cache yang sedang sering dipakai. Secara teknis cache ini bisa dibuang, tapi kalau dibuang, file yang sama akan langsung dibaca ulang dari disk. Ujungnya server malah lambat.

Itu sebabnya angka available biasanya lebih kecil dari free ditambah buff/cache. Kernel sudah memperhitungkan bagian yang tidak realistis untuk dilepas. Satu hal lagi yang sering tertukar adalah memori milik aplikasi. Contohnya InnoDB buffer pool di MySQL. Buffer pool dialokasikan langsung oleh proses mysqld, jadi masuk ke kolom used, bukan buff/cache. Kalau buffer pool diset terlalu besar untuk ukuran server, available akan menyusut secara permanen. Cara menimbang ukurannya dibahas di Cara Memastikan Ukuran InnoDB Buffer Pool di Server Sudah Pas.

Membersihkan cache tidak membuat server lebih lega

Banyak tutorial lama menyarankan membersihkan cache secara berkala dengan menulis angka ke /proc/sys/vm/drop_caches, kadang lewat cron. Hasilnya langsung terlihat. Kolom free melonjak dan grafik jadi hijau, jadi wajar kalau orang menganggap masalahnya selesai. Yang sebenarnya terjadi, kernel membuang cache yang bersih, termasuk cache yang masih berguna. Setelah itu, setiap file yang dibutuhkan website harus dibaca ulang dari disk. Selama cache terisi kembali, response time biasanya naik dan beban I/O meningkat. Dalam beberapa jam atau hari, kolom free akan kecil lagi, karena kernel memang dirancang untuk mengisi RAM kosong dengan cache. Langkah ini juga tidak menolong kalau masalah aslinya ada di aplikasi. Contohnya proses PHP yang terus membengkak atau worker yang jumlahnya terlalu banyak. Memori milik proses tidak tersentuh oleh drop_caches. Dokumentasi kernel sendiri memposisikan fitur ini untuk keperluan testing dan debugging, bukan untuk perawatan rutin. Kalau ada cron seperti ini di server, biasanya lebih aman dinonaktifkan, lalu cari tahu proses mana yang sebenarnya rakus memori.

Swap terpakai belum tentu RAM kurang

Swap adalah area di disk, berupa partisi atau file, tempat kernel memindahkan halaman memori yang jarang dipakai. Melihat swap terisi beberapa ratus MB memang bikin cemas. Swap identik dengan RAM yang tidak cukup, dan disk jauh lebih lambat dari RAM. Kenyataannya, kernel bisa memindahkan halaman yang lama tidak disentuh ke swap meskipun available masih besar. Contohnya bagian proses yang hanya aktif saat startup, atau daemon yang jarang bekerja. Dengan cara ini, RAM bisa dipakai untuk cache yang lebih berguna. Seberapa agresif kernel melakukan ini dipengaruhi parameter vm.swappiness, dan nilainya bisa berbeda antar distro atau image. Jadi angka swap used yang diam di satu nilai biasanya bukan masalah. Yang perlu diwaspadai adalah aktivitas swap: halaman terus-menerus dipindah ke swap lalu dibaca balik ke RAM. Kondisi ini disebut thrashing. Saat thrashing, CPU banyak menunggu disk dan aplikasi terasa macet, padahal penggunaan CPU-nya tidak tinggi. Di vmstat, aktivitas ini terlihat di kolom si (swap in) dan so (swap out). Kalau kedua kolom itu terus bernilai di atas nol selama beberapa detik berturut-turut, server memang sedang kekurangan memori.

Tanda memori benar-benar kurang dan cara mengeceknya

Kalau free bukan patokan, lalu kapan upgrade RAM atau tuning aplikasi benar-benar perlu? Biasanya beberapa tanda ini muncul bersamaan:

Kolom available kecil dibanding total dan terus menurun dari waktu ke waktu, bukan hanya turun sesaat saat ada lonjakan.
Kolom si dan so di vmstat aktif terus-menerus, bukan sesekali.
Kernel log mencatat OOM killer. OOM killer adalah mekanisme kernel yang membunuh proses saat memori benar-benar habis. Gejala yang sering terlihat: MySQL atau PHP-FPM mati tiba-tiba tanpa error jelas di log aplikasinya.
Kolom wa (I/O wait) di vmstat naik bersamaan dengan aktivitas swap.

Perintah berikut semuanya read-only dan aman dijalankan di server produksi:

BASH

# Ringkasan memori; fokus ke kolom available
free -m

# Lima sampel tiap 1 detik; perhatikan kolom si, so, dan wa
vmstat 1 5

# Detail dari kernel: memori tersedia, shared memory, dan dirty page
grep -E 'MemAvailable|Shmem:|Dirty' /proc/meminfo

# Jejak OOM killer di kernel log (sistem dengan systemd)
journalctl -k | grep -iE 'out of memory|oom-kill'

# Alternatif jika journalctl tidak tersedia
dmesg -T | grep -iE 'out of memory|oom-kill'

# Proses dengan pemakaian RAM terbesar
ps aux --sort=-rss | head -n 10

Perintah terakhir penting karena upgrade RAM bukan satu-satunya jawaban. Sering kali penyebabnya satu konfigurasi yang terlalu besar untuk ukuran server, misalnya jumlah worker PHP-FPM atau buffer database. Kalau itu yang terjadi, menambah RAM hanya menunda masalah. Untuk VPS, ada catatan tambahan. Di virtualisasi berbasis container, angka di free bisa mengikuti limit container atau perhitungan host, tergantung platform. Kalau angkanya terlihat janggal, bandingkan dengan grafik di panel penyedia dan cek dokumentasi mereka soal cara memori dihitung.

Yang perlu diingat saat melihat free -m berikutnya

Abaikan kolom free dan baca kolom available. Selama available masih punya ruang yang wajar dan kolom si serta so di vmstat tenang, cache besar adalah tanda server bekerja dengan benar, bukan tanda kehabisan RAM. Jangan bersihkan cache secara paksa. Mulai khawatir saat available terus menyusut, swap aktif bolak-balik, atau OOM killer muncul di kernel log. Di titik itu, cari dulu proses atau konfigurasi yang memakan memori sebelum memutuskan upgrade.