RAM Server Selalu Penuh, Bahaya atau Normal?

RAM server yang "selalu penuh" adalah keluhan yang sangat umum, dan di Linux jawabannya hampir selalu: itu normal. Kernel Linux sengaja memakai memori yang sedang tidak dipakai aplikasi untuk menyimpan salinan file yang sering dibaca (page cache). Memori ini bisa dilepas seketika saat aplikasi membutuhkannya, jadi sebenarnya tidak "habis".

Yang dipertaruhkan adalah keputusanmu. Kalau angka "used" di grafik panel dianggap tanda bahaya, kamu bisa membayar upgrade RAM yang tidak perlu, atau lebih buruk, menjalankan skrip pembersih cache yang justru membuat server lebih lambat. Sebaliknya, kalau semua grafik penuh dianggap normal, kamu bisa melewatkan tanda kekurangan memori yang sebenarnya sampai proses penting mati mendadak.

Bagaimana membaca pemakaian RAM dengan benar?

Perintah paling sederhana adalah free -h. Hasilnya kurang lebih seperti ini:

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.2Gi       180Mi        60Mi       2.5Gi       2.4Gi
Swap:          2.0Gi          0B       2.0Gi

Sekilas, free hanya 180 MiB dan terlihat mengkhawatirkan. Padahal sebagian besar memori ada di buff/cache, dan kolom available menunjukkan masih ada sekitar 2,4 GiB yang bisa dipakai aplikasi baru tanpa perlu swap.

Arti setiap kolom

Kolom available dihitung kernel dari nilai MemAvailable di /proc/meminfo. Angka ini memperhitungkan bahwa sebagian cache bisa dilepas dan sebagian lagi tidak, sehingga jauh lebih jujur daripada free.

Kenapa grafik panel sering terlihat penuh

Banyak panel atau alat monitoring menampilkan RAM "terpakai" dengan cara menjumlahkan semua yang tidak kosong, termasuk cache. Akibatnya grafik terlihat stabil di 90 persen lebih, padahal server santai. Sebelum panik, cek definisi metrik di alat yang kamu pakai, atau bandingkan dengan free -h langsung di server. Cara membaca grafik semacam ini dibahas lebih jauh di artikel metrik server yang wajib dipantau.

Ada juga aplikasi yang memang memesan memori besar sejak awal. MySQL dan MariaDB menyiapkan InnoDB buffer pool sesuai pengaturan, aplikasi Java memesan heap, dan Redis menyimpan seluruh datanya di RAM. Pemakaian tinggi dari aplikasi seperti ini wajar selama memang sudah direncanakan dan masih menyisakan ruang untuk sistem.

Tanda RAM benar-benar kurang

Angka penuh bukan masalah. Masalahnya adalah ketika aplikasi mulai berebut memori. Tanda-tandanya:

• available terus rendah, misalnya di bawah 10 persen dari total, terutama saat jam sibuk.
• Swap aktif terus-menerus. Jalankan vmstat 1 10 dan lihat kolom si (swap in) dan so (swap out). Angka yang selalu di atas nol berarti data terus dipindah antara RAM dan disk, dan server terasa lambat.
• Proses mati sendiri. Cari jejak OOM killer dengan journalctl -k | grep -i "out of memory" atau dmesg | grep -i oom. Penjelasan lengkapnya ada di artikel proses mati mendadak karena OOM killer.
• Tekanan memori tinggi. Kernel modern menyediakan /proc/pressure/memory (Pressure Stall Information). Nilai some dan full yang terus naik berarti proses sering tertahan karena menunggu memori.
• Disk sibuk padahal tidak ada aktivitas tulis besar. Saat RAM sempit, kernel harus terus membuang cache lalu membaca ulang file dari disk.

Untuk melihat siapa pemakai terbesar, jalankan ps aux --sort=-rss | head -n 10, atau buka htop lalu urutkan berdasarkan kolom memori. Panduan memakai alat itu ada di artikel melihat proses berjalan dengan top dan htop.

Kapan cukup dibiarkan, kapan perlu bertindak?

Biarkan saja bila available masih longgar, swap hampir tidak bergerak, tidak ada catatan OOM, dan aplikasi terasa responsif. Grafik yang penuh karena cache justru tanda kernel memanfaatkan RAM dengan baik. Tidak ada keuntungan memiliki RAM kosong yang menganggur.

Bertindaklah bila tanda-tanda di atas muncul berulang. Langkah pertama bukan selalu menambah RAM. Periksa dulu apakah ada pengaturan yang terlalu boros, misalnya jumlah worker PHP-FPM yang melebihi kemampuan server, buffer pool database yang diatur lebih besar dari RAM yang tersedia, atau kebocoran memori di aplikasi yang membuat pemakaian naik terus setiap hari sampai di-restart.

Swap bisa menjadi bantalan untuk lonjakan sesaat, terutama di VPS kecil. Pertimbangannya dibahas di artikel perlukah swap di VPS kecil. Namun swap bukan pengganti RAM. Kalau server terus bergantung pada swap, performanya akan turun.

Bila setelah penyesuaian available tetap tipis di jam normal, menambah RAM adalah langkah yang masuk akal. Pada VPS, ini biasanya cukup dengan upgrade paket tanpa memindahkan data.