Cara Mengecek Kesehatan RAM Server Linux — Panduan Lengkap

Saya pernah dapet alert middle of the night — server client tiba-tiba OOM killer aktif, proses database mati satu-satu. Panik? Tentu. Tapi yang bikin saya kesel bukan alertnya, tapi ternyata masalah ini sudah terjadi berhari-hari tanpa seorang pun sadar. RAM-nya sudah “sakit” lama, tapi karena tidak ada yang ngecek, ya sudah dibiarkan sampai akhirnya parah.

Bayangin kayak mobil — kamu bisa aja naik mobil tiap hari tanpa servis, tapi kalau oli sudah hitam dan mesin mulai bergetar aneh, mau tidak mau suatu saat mogok di tengah jalan. RAM server itu sama persis. Dia bisa jalan normal di awal, tapi kalau tidak dicek secara berkala, gejala kecilnya akan menumpuk sampai jadi masalah besar yang bikin seluruh service down.

Jadi artikel ini ditulis bukan untuk kamu yang sedang panik karena server down — tapi untuk kamu yang ingin mencegah itu terjadi. Kita akan bahas cara mengecek kesehatan RAM server Linux dari level paling basic sampai yang advanced, lengkap dengan command-command yang biasa saya pakai di lapangan.

Kenapa RAM Health Itu Penting Banget?

Sebelum masuk ke command, kamu perlu tahu kenapa ini urgensinya tinggi. RAM yang sehat artinya server bisa handle request tanpa bottleneck. RAM yang sakit — entah karena memory leak, faulty DIMM, atau overcommit — bisa bikin segalanya lambat, termasuk website kamu yang tiba-tiba load-nya 10 detik padahal biasanya 2 detik.

Di dunia NOC, kami punya istilah: “silent killer.” Server yang RAM-nya sudah hampir penuh tapi masih bisa jalan itu ibarat orang yang demam tapi masih maksa kerja — kelihatannya oke, tapi sebentar lagi collapse. Kalau kamu mengelola VPS atau dedicated server, memahami cara membaca kondisi RAM itu wajib, bukan opsional.

Membaca Output free -h dengan Benar

Command pertama dan paling sering dipakai adalah free -h. Tapi masalahnya, banyak orang salah baca outputnya. Mereka lihat “used” tinggi langsung panik, padahal itu belum tentu masalah.

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       8.2Gi       1.1Gi       512Mi       5.8Gi       6.4Gi
Swap:          2.0Gi       128Mi       1.8Gi

Ini output dari server yang handle WordPress multisite. Sekilas, “used” 8.2GB terlihat tinggi dari total 15GB. Tapi jangan panik dulu — lihat kolom available: 6.4GB. Artinya, sistem masih punya cukup RAM yang bisa dipakai untuk proses baru.

Yang harus kamu perhatikan:

• available (bukan free) — ini angka yang sebenarnya menunjukkan RAM yang benar-benar bisa dipakai
• buff/cache — ini RAM yang dipakai untuk caching. Linux secara agresif menggunakan RAM untuk cache file, tapi cache ini bisa dilepas kapan saja kalau ada proses yang butuh RAM
• Swap used — kalau angka ini tinggi (lebih dari 50% total swap), itu tanda RAM sudah tidak cukup dan sistem mulai pakai disk sebagai RAM cadangan. Disk jauh lebih lambat dari RAM, jadi performa pasti drop

Perbedaan free vs available

Memantau RAM Secara Real-Time dengan top/htop

Command free hanya memberikan snapshot sekali. Kalau kamu mau lihat konsumsi RAM secara real-time — misalnya untuk debugging saat performa server sedang drop — pakai htop atau top.

$ htop

Di htop, kamu akan lihat bar RAM di bagian atas. Yang perlu kamu perhatikan:

• Warna green = RAM yang terpakai untuk proses
• Warna blue = RAM yang dipakai untuk buffer/cache
• Warna yellow/orange = RAM yang digunakan oleh kernel

Kalau kamu tidak punya htop (biasanya di server minimalis), pakai top bawaan:

$ top

Di barisan atas top, cari baris Mem — di situ kamu akan lihat total, used, free, dan buffers/cache. Sort proses berdasarkan penggunaan memory dengan menekan M (huruf kapital) di keyboard.

Mengetahui Proses Mana yang Paling Rakus RAM

Sering kali masalah bukan di total RAM, tapi di satu proses yang rakus dan menghabiskan RAM sendirian. Ini yang saya sebut “proses cancer” — diam-diam makan resource sampai server mati.

$ ps aux --sort=-%mem | head -20

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1234  12.3 28.5 1843200 4567892 ?     Sl   Jul20  120:45 /usr/sbin/mysqld
nginx     5678   2.1  8.2  245760 1310720 ?     S    Jul20   15:23 nginx: worker
www-data  9012   1.8  6.5  524288 1048576 ?      S    Jul20   12:11 php-fpm: pool
root      3456   0.5  3.2  204800  524288 ?      Ss   Jul20    8:45 /usr/bin/node

Di contoh di atas, MySQL menggunakan 28.5% dari total RAM — itu wajar untuk database server yang handle banyak query. Tapi kalau kamu lihat proses yang tidak seharusnya pakai RAM sebanyak itu (misalnya php-fpm yang pakai 40%), itu sudah tanda ada masalah, mungkin memory leak.

Memahami Memory Mapping dengan smem

Command ps menampilkan RSS (Resident Set Size), tapi angka RSS bisa menyesatkan karena termasuk shared memory yang juga dipakai proses lain. Untuk pandangan yang lebih akurat, pakai smem:

$ sudo apt install smem
$ smem -t -k -s pss

  PID User     Command                         Swap      USS      PSS      RSS
 1234 mysql    /usr/sbin/mysqld                  0B    4.1G    4.1G    4.3G
 5678 nginx    nginx: worker process             0B    1.2G    1.2G    1.3G
 9012 www-data php-fpm: pool www                 0B  980.5M  985.2M    1.0G

PSS (Proportional Set Size) adalah angka paling akurat untuk menunjukkan berapa banyak RAM yang benar-benar dipakai satu proses, dengan proporsi shared memory yang dibagi rata. Kalau kamu mau tahu siapa sebenarnya yang paling rakus, lihat PSS, bukan RSS.

Verifikasi Kondisi Fisik RAM dengan dmidecode

Command-command di atas menunjukkan penggunaan RAM oleh software. Tapi bagaimana kalau masalahnya ada di hardware? RAM fisik yang rusak (faulty DIMM) bisa bikin error yang sangat sulit ditrace karena gejalanya kadang muncul kadang tidak.

$ sudo dmidecode -t memory | grep -A 17 "Memory Device"

Memory Device
	Size: 8192 MB
	Form Factor: DIMM
	Speed: 3200 MT/s
	Manufacturer: Samsung
	Serial Number: ABCD1234
	Part Number: M391A1G43AB1-CWE
	Rank: 2
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits

Perhatikan baris Error Information Handle: Not Provided. Kalau ada error pada DIMM fisik, di sinilah biasanya tercatat. Selain itu, periksa juga edac-utils untuk error correction reporting:

$ sudo apt install edac-utils
$ edac-util -s
edac-util: EDAC driver is not loaded.

$ sudo modprobe edac_mce_amd  # untuk AMD
$ sudo modprobe amd64_edac     # untuk AMD alternative
$ sudo modprobe intel_edac     # untuk Intel
$ edac-util -s

Memeriksa Swap dan Overcommit

Kadang server terasa lambat bukan karena RAM-nya penuh, tapi karena overcommit. Linux punya fitur overcommit — dia bolehkan alokasi memory lebih dari yang tersedia, dengan asumsi tidak semua alokasi akan dipakai sekaligus. Kadang asumsi ini salah.

$ cat /proc/sys/vm/overcommit_memory
0

$ cat /proc/sys/vm/overcommit_ratio
50

Artinya overcommit mode adalah heuristic (0), dan ratio adalah 50%. Untuk server production, saya biasanya menyarankan:

$ sudo sysctl -w vm.overcommit_memory=2
$ sudo sysctl -w vm.overcommit_ratio=80

# Untuk permanent:
echo "vm.overcommit_memory = 2" | sudo tee -a /etc/sysctl.conf
echo "vm.overcommit_ratio = 80" | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

Monitoring Memory Leak dengan Cara Praktikal

Memory leak itu ibarat keran air yang tidak ditutup — setetes demi setetes, lama-lama habis. Untuk mendeteksinya, kamu perlu memantau penggunaan RAM dari waktu ke waktu, bukan sekali saja.

# Install sar jika belum ada
$ sudo apt install sysstat

# Aktifkan sar
$ sudo systemctl enable sysstat
$ sudo systemctl start sysstat

# Cek penggunaan memory per jam (hari ini)
$ sar -r -f /var/log/sysstat/sa$(date +%d)

12:00:01 AM  kbmemfree kbmemused  %memused kbbuffers  kbcached  kbswpfree kbswpused  %swpused
12:10:01 AM    1126400  14233600     92.68   1048576   6094848    1920000     128000      6.25
12:20:01 AM    1098000  14262000     92.86   1048576   6123520    1915000     133000      6.49
12:30:01 AM    1075200  14284800     93.01   1048576   6147200    1910000     138000      6.74
12:40:01 AM    1052800  14307200     93.16   1048576   6170880    1905000     143000      6.98
12:50:01 AM    1030400  14329600     93.31   1048576   6194560    1900000     148000      7.23

Lihat polanya — kbmemfree terus menurun dari jam ke jam? Itu indikasi kuat ada memory leak. Dalam contoh di atas, free memory turun sekitar 24MB setiap 10 menit. Kalau dibiarkan, beberapa jam lagi server akan mulai swap heavy dan performa drop.

Cek Error RAM di System Log

Error hardware RAM biasanya tercatat di kernel log. Kamu bisa cek dengan:

Penjelasan log di atas:

• CE (Correctable Error) — Error yang bisa diperbaiki oleh ECC. Satu-dua CE masih bisa ditoleransi, tapi kalau frekuensinya tinggi, DIMM-nya sudah mulai rusak
• UE (Uncorrectable Error) — Error yang TIDAK bisa diperbaiki. Ini bahaya — bisa bikin data corrupt atau kernel panic. Kalau kamu lihat UE, ganti DIMM segera
• MCE (Machine Check Exception) — Hardware error reporting dari CPU. Bisa jadi RAM, bisa juga CPU atau motherboard

Stress Testing RAM

Mau tahu batas maksimal RAM server kamu sebelum mulai bermasalah? Lakukan stress test. Tapi hati-hati — jangan lakukan ini di server production yang sedang handle traffic normal.

# Install stress
$ sudo apt install stress

# Stress test dengan menggunakan 80% RAM selama 5 menit
$ stress --vm 2 --vm-bytes 80% --vm-keep --timeout 300s

# Atau lebih akurat dengan memtester
$ sudo apt install memtester
$ sudo memtester 4G 1

memtester version 4.6.5 (64-bit)
Copyright ©2010-2022 by Charles Cazabon.

Looping 1 time through 4G of memory.

Stuck Address       : ok
	Random Value      : ok
	Compare XOR        : ok
	Compare SUB        : ok
	Compare MUL        : ok
	Compare DIV        : ok
	Logical OR         : ok
	Logical AND        : ok
	Block Compare      : ok
	Checkerboard       : ok
	Bit Spread         : ok
	Bit Flip           : ok
	Walking Ones       : ok
	Walking Zeroes     : ok
	8-bit Writes       : ok
	16-bit Writes      : ok

Script Monitoring RAM Otomatis

Sebagai NOC engineer, saya tidak mungkin login ke server 24 jam untuk cek RAM manual. Yang saya lakukan adalah buat script sederhana yang mengirim alert kalau RAM sudah mencapai threshold tertentu.

#!/bin/bash
# ram-monitor.sh — Simpan di /usr/local/bin/

THRESHOLD=85
HOSTNAME=$(hostname)
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# Ambil persentase RAM yang terpakai (tanpa cache)
RAM_USED=$(free | awk '/Mem:/ {printf "%.0f", ($3-$7)/$2 * 100}')

if [ "$RAM_USED" -gt "$THRESHOLD" ]; then
    TOP_PROCS=$(ps aux --sort=-%mem | head -5 | awk '{printf "%s (%s%%)n", $11, $4}')
    
    echo -e "Subject: [WARNING] RAM Usage on $HOSTNAME is ${RAM_USED}%nn"
echo -e "RAM Usage: ${RAM_USED}%nTop processes:n${TOP_PROCS}nn"
echo -e "Timestamp: $DATE" | mail -s "[WARNING] RAM Alert: $HOSTNAME" admin@syslogsolutions.net
fi

Jalankan script ini setiap 5 menit dengan cron:

# Buka crontab
$ crontab -e

# Tambah baris ini:
*/5 * * * * /usr/local/bin/ram-monitor.sh

Related Issues

• Cara Mengecek Kesehatan CPU Server Linux
• Mengatasi Disk Full di VPS
• Memahami OOM Killer di Linux
• Panduan Monitoring Server Linux untuk NOC
• Optimasi Performance Server Linux

Kesimpulan

Mengecek kesehatan RAM server Linux itu bukan sesuatu yang rumit — yang sulit itu disiplin melakukannya secara berkala. Command-command yang sudah kita bahas di atas sebenarnya sangat mudah dijalankan, bahkan kamu bisa set script otomatis supaya tidak perlu manual check.

Yang paling penting dari semua ini: jangan hanya cek saat ada masalah. Jadikan ini rutinitas, sama seperti kamu servis mobil sebelum mogok, bukan sesudah mogok. Kalau kamu mengelola lebih dari satu server, pertimbangkan untuk pakai tool monitoring seperti Grafana + Prometheus atau Netdata yang bisa memberikan alert otomatis.