Optimasi tanpa pengukuran hanyalah tebak-tebakan yang terasa ilmiah. Perangkat lama memperbesar risiko tebakan ini: gejala “lambat” bisa berasal dari RAM yang sesak, disk yang penuh, atau proses yang rakus — dan ketiganya menuntut penanganan berbeda. Aturan pertama section ini karenanya sederhana: catat kondisi dasar (baseline) sebelum mengubah apa pun, lalu ukur ulang setelahnya. Chapter ini melatih kita membaca free dari sudut pandang perangkat tua, menemukan proses paling rakus dengan ps, lalu membangun skrip snapshot yang membandingkan keadaan sebelum dan sesudah setiap perubahan.

Baseline: Ukur Dulu, Baru Optimasi #

Metodologinya meniru cara insinyur mengukur performa: catat keadaan, ubah satu hal, ukur lagi, bandingkan. Tanpa disiplin ini kita tidak pernah tahu apakah sebuah “optimasi” benar-benar berperan atau hanya memberi efek plasebo — perasaan “kelihatan lebih cepat” setelah menyetel sesuatu bukan bukti. Hasil pengukuran tidak perlu alat mahal; file teks kecil berisi keluaran free dan ps yang disimpan dengan nama jelas sudah cukup.

Membaca free dari Sudut Pandang Perangkat Tua #

Perintah free sudah kita bedah di Chapter Memory Monitoring ; di sini kita membacanya ulang untuk mesin kecil. Dua penanda paling menentukan adalah kolom available (perkiraan RAM yang masih bisa dipakai proses baru tanpa menyentuh swap) dan baris Swap (swap yang terpakai secara kronis menandakan RAM memang kekurangan, bukan sekadar sedang sibuk). Karena keluaran free asli berbeda di setiap mesin, latihan kita memakai fixture statis yang formatnya sama persis dengan keluaran free -m:

bash 
cat > free-laptop-lama.txt <<'AKHIR'
               total        used        free      shared  buff/cache   available
Mem:            1945        1498          88          96         358         301
Swap:           1023         987          36
AKHIR

awk '
/^Mem:/  { ram_total = $2; ram_used = $3; ram_avail = $7 }
/^Swap:/ { swap_total = $2; swap_used = $3 }
END {
  printf "RAM       : %d MiB total, %d MiB terpakai (%.1f%%)\n", ram_total, ram_used, ram_used/ram_total*100
  printf "available : %d MiB (%.1f%% dari total)\n", ram_avail, ram_avail/ram_total*100
  printf "swap      : %d MiB dari %d MiB terpakai (%.1f%%)\n", swap_used, swap_total, swap_used/swap_total*100
}' free-laptop-lama.txt

Output yang Dihasilkan:

text 
RAM       : 1945 MiB total, 1498 MiB terpakai (77.0%)
available : 301 MiB (15.5% dari total)
swap      : 987 MiB dari 1023 MiB terpakai (96.5%)

Hasilnya menceritakan kisah yang khas: available tinggal 15,5 persen, dan swap terpakai 96,5 persen — mesin ini hidup dalam tekanan memori kronis. Bedah potongan awk di atas:

  1. Baris 8–9 (dua pola baris): pola /^Mem:/ dan /^Swap:/ masing-masing menangkap satu baris; kernel memang menyajikan memori utama dan swap sebagai dua baris terpisah.
  2. Baris 8 ($7): kolom ketujuh baris Mem: adalah available — berhati-hatilah: $4 (free) terlihat lebih dramatis kecil, tetapi sebagian besar buff/cache bisa dikembalikan kapan saja, jadi $7 yang lebih jujur menggambarkan ruang gerak.
  3. Baris 11–13 (printf dengan %.1f): pembagian dilakukan langsung di dalam format agar pembulatan terjadi sekali; persentase tiga digit terasa cukup untuk keputusan praktis.

Menemukan Proses Paling Rakus #

Setelah tahu berapa yang terpakai, pertanyaan berikutnya adalah siapa pemakainya. ps aux --sort=-%mem | head mengurutkan seluruh proses turun berdasarkan kolom %MEM. Berikut contoh tampilan hasilnya pada laptop lama sesaat setelah login:

text 
USER  PID %CPU %MEM    VSZ   RSS TTY      STAT START  TIME COMMAND
budi  1120  1.2 38.6 2143120 769780 ?     Sl   09:12  3:44 /usr/lib/firefox/firefox
budi   845  0.3 12.6  912640 252940 ?     Sl   09:11  0:58 xfce4-terminal
budi   921  0.1  6.4  512300 128540 ?     Ss   09:11  0:12 picom
budi   633  0.0  0.8   10244  16980 ?     Ss   09:10  0:01 lightdm

Dua kolom perlu dibedakan tegas. Kolom RSS adalah memori fisik yang benar-benar dipegang proses — inilah angka yang membebani mesin tua. Kolom VSZ adalah ruang alamat virtual yang bisa jauh lebih besar dan tidak selalu terpakai nyata. Pada tampilan di atas, satu proses Firefox memegang sekitar 752 MiB RSS — 38,6 persen dari RAM 1945 MiB — menegaskan kembali pelajaran Chapter Memilih Distro Ringan bahwa browser adalah pemain utama. Untuk mengurutkan berdasarkan CPU cukup ganti kuncinya menjadi --sort=-%cpu, dan membaca antrean beban sistem tetap memakai uptime sebagaimana dibedah di Chapter Uptime dan Load Average . Ruang disk diukur dengan df -h, dan pencarian penyumbat direktori dengan du — keduanya dibahas tuntas di Chapter Disk Monitoring . Spesifikasi lengkap opsi ps ada di ps(1) dan free di free(1) .

Skrip Mini: Snapshot dan Pembanding Baseline #

Sekarang kita rakit metodologi baseline menjadi alat kerja. Dua fixture berperan sebagai dua hasil free -m yang disimpan pada waktu berbeda — “sebelum” dan “sesudah” satu perubahan — dan sebuah skrip membandingkannya:

bash 
cat > free-sebelum.txt <<'AKHIR'
               total        used        free      shared  buff/cache   available
Mem:            1945        1498          88          96         358         301
Swap:           1023         987          36
AKHIR

cat > free-sesudah.txt <<'AKHIR'
               total        used        free      shared  buff/cache   available
Mem:            1945        1012         148         102         783         790
Swap:           1023         540         483
AKHIR

cat > bandingkan-baseline.sh <<'SKRIP'
#!/bin/bash
# bandingkan-baseline.sh <free-sebelum> <free-sesudah>
awk '
  NR == FNR { if ($1 == "Mem:") { ram1 = $3; av1 = $7 } next }
  { if ($1 == "Mem:") { ram2 = $3; av2 = $7 } }
  END {
    printf "RAM terpakai : %d -> %d MiB (%+d)\n", ram1, ram2, ram2 - ram1
    printf "available    : %d -> %d MiB (%+d)\n", av1, av2, av2 - av1
  }
' "$1" "$2"
SKRIP

bash bandingkan-baseline.sh free-sebelum.txt free-sesudah.txt

Output yang Dihasilkan:

text 
RAM terpakai : 1498 -> 1012 MiB (-486)
available    : 301 -> 790 MiB (+489)

Hasilnya ringkas dan berpihak: pemakaian RAM turun 486 MiB dan available naik 489 MiB. Bedah skripnya:

  1. Baris 17 (NR == FNR ... next): idiom klasik awk dua file — selama NR (nomor baris kumulatif) masih sama dengan FNR (nomor baris per file), berarti kita masih membaca file pertama; next memastikan baris itu tidak jatuh ke pola kedua.
  2. Baris 18: untuk file kedua, blok inilah yang menangkap angka “sesudah” ke variabel ram2 dan av2.
  3. Baris 20–21 (%+d): format %+d mencetak tanda secara eksplisit (-486, +489) sehingga arah perubahan langsung terbaca — kebiasaan kecil yang sangat membantu saat laporan dibaca minggu kemudian.
  4. Baris 26: pemanggilan memakai dua fixture; di mesin nyata, ganti keduanya dengan file snapshot asli, misalnya hasil free -m > baseline-01.txt yang disimpan sebelum perubahan.

Baseline pada section ini selanjutnya jadi alat ukur semua chapter berikutnya. Pemakaian pertamanya: membuktikan bahwa memangkas service dan aplikasi autostart benar-benar mengembalikan ratusan megabyte — topik Chapter Mengurangi Aplikasi Background .