Performance Bottlenecks

Lima chapter sebelumnya memberi kita alat ukur yang terpisah-pisah: CPU, memori, disk, jaringan, dan load average. Di lapangan, masalah performance jarang berdiri sendiri — satu sumber daya jenuh lebih dulu, lalu gejalanya merembet ke mana-mana. Sumber daya yang jenuh itulah bottleneck: titik tersempit yang menentukan kecepatan keseluruhan sistem, seperti satu jalur bridge di tengah jalan tiga lajur. Chapter ini memetakan empat sumber bottleneck, memisahkan gejala di permukaan dari akar masalah, lalu melatih urutan diagnosis yang selalu memeriksa hal termurah lebih dulu.

Empat Sumber Bottleneck #

Empat sumber daya bisa menjadi titik jenuh, dan masing-masing punya tanda khas yang terbaca dari sarana pemantauan di chapter-chapter sebelumnya:

Bottleneck CPU paling jujur: proses-proses betul-betul menghitung, jadi load average naik sementara %iowait nyaris nol. Bottleneck memori lebih licik — kernel menukar halaman memori ke disk, dan sistem melambat bukan karena kalkulasi berat, melainkan karena disk tiba-tiba sibuk melayani swap; kondisi ini disebut swap thrashing. Bottleneck disk terlihat sebagai %iowait tinggi: CPU menganggur bukan karena tak ada pekerjaan, melainkan karena pekerjaan menunggu jawaban disk. Proses yang menunggu I/O lama berstatus D (uninterruptible sleep) dan ikut dihitung dalam load average — itulah mengapa masalah disk selalu menaikkan load. Bottleneck jaringan paling kontekstual: pembuktiannya ada di jumlah retransmit dan antrean antarmuka jaringan.

Gejala di Permukaan, Akar di Tempat Lain #

Keluhan yang sampai ke kita hampir selalu berupa gejala umum, bukan akar masalah:

Karena gejala bisa berakar di mana-mana, diagnosis perlu urutan tetap, dari pemeriksaan termurah ke termahal. Pertama, baca load average — satu angka dari uptime, tafsirannya dibahas di Uptime dan Load Average . Kedua, baca free untuk memastikan memori dan swap. Ketiga, baca %iowait untuk menyingkirkan atau menuduh disk. Terakhir, baru selidiki jaringan — pemeriksaan termahal karena butuh membandingkan dua titik pengukuran.

Metode USE: Utilization, Saturation, Errors #

Kerangka ringkas untuk memeriksa sumber daya apa pun adalah USE method: untuk setiap sumber daya, tanyakan tiga hal — Utilization (seberapa penuh dipakai), Saturation (seberapa banyak pekerjaan mengantre karena penuh), dan Errors (berapa banyak operasi gagal):

Manfaat utamanya disiplin: kita tidak menyebut sumber daya bermasalah sebelum ketiga pertanyaan terjawab dengan angka. Rujukan lengkap kolom-kolomnya ada di vmstat(8) dan top(1) .

Praktik: Skrip Pendeteksi Bottleneck #

Blok berikut merangkum urutan diagnosis menjadi skrip mini: fungsi deteksi menerima tiga angka metrik — load average 1 menit, persentase memori, persentase %iowait — lalu mencetak tersangka utama beserta langkah lanjutannya. Angka datang dari fixture, bukan sistem langsung, agar latihan bisa diulang dengan hasil sama:

deteksi() {
  load=$1; mem=$2; iowait=$3
  kategori=$(awk -v l="$load" -v m="$mem" -v i="$iowait" 'BEGIN {
    if      (i >= 20) print "disk"
    else if (m >= 90) print "memori"
    else if (l >= 4)  print "cpu"
    else              print "sehat"
  }')
  case $kategori in
    disk)   echo "Tersangka: disk I/O - iowait ${iowait}%, cari proses berstatus D" ;;
    memori) echo "Tersangka: memori - pemakaian ${mem}%, cek swap dan OOM di log" ;;
    cpu)    echo "Tersangka: CPU - load ${load}, urutkan proses dengan top" ;;
    sehat)  echo "Tidak ada bottleneck mencolok - lanjut periksa jaringan" ;;
  esac
}
deteksi 8.40 55 2
deteksi 3.10 41 38
deteksi 2.20 96 1

Output yang Dihasilkan:

Tersangka: CPU - load 8.40, urutkan proses dengan top
Tersangka: disk I/O - iowait 38%, cari proses berstatus D
Tersangka: memori - pemakaian 96%, cek swap dan OOM di log

Mari kita bedah baris-per-barisnya:

1. Baris 2 (load=$1; mem=$2; iowait=$3): tiga argumen diikat ke nama variabel agar isi case mudah dibaca — bash menolak desimal dalam [ -ge ], jadi pembandingan diserahkan ke awk.
2. Baris 3-8 (kategori=$(awk ...)): awk membandingkan angka desimal dengan aman; %iowait diperiksa paling awal karena iowait ikut menaikkan load average — disk harus dibebaskan dulu sebelum menuduh CPU.
3. Baris 9-14 (case $kategori in): hasil klasifikasi diterjemahkan menjadi instruksi tindak lanjut yang spesifik — termasuk jalan keluar “sehat” yang menganjurkan pemeriksaan jaringan, pemeriksaan termahal di urutan terakhir.

Untuk memindai banyak mesin sekaligus, pola yang sama bekerja pada file metrik: satu baris per mesin, lalu awk menyaring mesin yang melampaui ambang:

printf '%s\n' 'web01 8.40 55 2' 'db01 3.10 41 38' 'app01 2.20 96 1' > metrik.txt
awk '$3+0 >= 90 {print $1 ": memori kritis (" $3 "%)"} $4+0 >= 20 {print $1 ": iowait tinggi (" $4 "%)"}' metrik.txt

Output yang Dihasilkan:

db01: iowait tinggi (38%)
app01: memori kritis (96%)

File metrik.txt memuat empat kolom: host, load, persen memori, persen iowait. Penjumlahan +0 pada $3+0 memaksa awk memperlakukan kolom itu sebagai angka, sehingga perbandingan >= 90 membandingkan nilai, bukan teks. Dua mesin lolos saringan dan menunjuk ke arah yang berbeda — persis seperti di server sungguhan.

Angka semacam itu biasanya dikumpulkan dari alat pemantauan. Berikut contoh tampilan vmstat 1 pada server yang sedang sesak:

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 2  5 482104  61208  20480 812004  214  189 24105  3204 1890 2210  3  2 59 36  0  0

Pembacaannya mengikuti tabel USE: si/so yang tidak nol berarti swap aktif dua arah, bi besar berarti disk sibuk membaca, dan wa 36% menegaskan CPU menganggur menunggu I/O — kombinasi disk jenuh plus memori mepet. Kalau tekanan memori dibiarkan, akhirnya adalah OOM killer. Berikut contoh tampilan jejaknya di log kernel:

Jan 15 09:14:02 server-kantor kernel: Out of memory: Killed process 8021 (python3) total-vm:1984320kB, anon-rss:1862310kB

Baris seperti ini adalah vonis akhir kernel: proses python3 dengan PID 8021 dibunuh karena memori habis. Nama proses itulah yang dicari di log setelah free memperlihatkan memori kritis.

Metrik menunjukkan apa yang jenuh; untuk mengetahui mengapa, kita butuh jejak peristiwanya — dan jejak itu tersimpan di log sistem, topik chapter berikutnya.