Uptime dan Load Average

Tiga angka kecil di ujung output uptime adalah indikator kesehatan yang paling sering dikutip orang — dan paling sering disalahartikan. Load average bukan persentase, bukan pula hasil pengukuran CPU semata, sehingga “load 2” bisa berarti mesin kewalahan pada satu sistem dan bersantai pada sistem lain, tergantung jumlah core. Pada chapter ini kita bedah apa yang sebenarnya dihitung load average, bagaimana membacanya relatif terhadap jumlah core, dan mengapa load yang tinggi tidak selalu berarti CPU yang penuh.

Apa yang Sebenarnya Dihitung Load Average #

Load average adalah rata-rata jumlah proses yang sedang berada di antrean scheduler: proses yang benar-benar berjalan di core saat itu, ditambah proses yang siap berjalan tetapi menunggu giliran. Angkanya dihaluskan dengan rata-rata eksponensial pada tiga jendela waktu — 1, 5, dan 15 menit — sehingga angka 1 menit merefleksikan kondisi baru-baru ini sedangkan 15 menit memberi gambaran latar yang lebih stabil. Analoginya adalah kasir supermarket: jumlah core adalah kasir yang bertugas, proses adalah pembeli, dan load adalah panjang antrean rata-rata. Satu antrean per kasir berarti semua kasir sibuk penuh; antrean yang lebih panjang berarti pembeli menunggu.

Ada satu detail yang sering mengejutkan: proses berstate D (uninterruptible sleep) ikut dihitung dalam antrean, meski state itu — yang sudah kita kenal dari kolom STAT di Chapter ps, top, dan htop — berarti proses sedang menunggu I/O, bukan menunggu giliran CPU. Pilihan desain ini disengaja: proses penunggu I/O tetap menghalangi pekerjaan selesai, jadi layak dihitung sebagai beban sistem.

Interpretasi Relatif Jumlah Core #

Angka load hanya bermakna bila dibandingkan dengan jumlah core — informasi yang mudah didapat lewat nproc atau lscpu dari Chapter Hardware Information . Tabel berikut memperlihatkan bagaimana load yang sama berarti dua hal berbeda:

Rasio load ÷ core adalah alat bacanya: di bawah 0.7 sistem umumnya lega, di sekitar 1.0 kapasitas habis, dan di atasnya pekerjaan mulai menumpuk. Karena /proc/loadavg berisi nilai yang berubah tiap detik dan berbeda antar mesin, latihan berikut memakai fixture berformat identik dengan file asli lalu menghitung rasio yang sama pada tiga konfigurasi core berbeda:

printf '2.50 2.10 1.80 2/206 54321\n' > loadavg.txt

for core in 2 4 8; do
  awk -v c="$core" '{
    printf "load 2.50 pada %d core -> rasio %.2f\n", c, $1/c
  }' loadavg.txt
done

Output yang Dihasilkan:

load 2.50 pada 2 core -> rasio 1.25
load 2.50 pada 4 core -> rasio 0.62
load 2.50 pada 8 core -> rasio 0.31

Satu angka load yang sama, tiga keadaan yang berbeda: pada mesin 2 core rasio 1.25 berarti antrean sudah melampaui kapasitas, sedangkan pada mesin 8 core rasio 0.31 berarti sistem baru memakai sepertiga dayanya. Tanpa menyebut jumlah core, angka 2.50 sendiri tidak bercerita apa-apa.

uptime dan /proc/loadavg #

Perintah uptime menampilkan jam sekarang, berapa lama sistem menyala, jumlah sesi user, dan ketiga load average sekaligus. Berikut contoh tampilan uptime pada server yang sudah berjalan dua minggu:

 14:23:01 up 13 days,  7:41,  2 users,  load average: 1.20, 0.98, 0.75

Angka “up 13 days” inilah asal nama perintahnya — pertama dipakai untuk memastikan berapa lama server bertahan sejak terakhir dinyalakan, dan kini menjadi pembuka percakapan klasik antar administrator saat bertengkar soal siapa yang perlu reboot. Ketiga load di ujung baris dibaca berpasangan: 1.20 → 0.98 → 0.75 yang menurun berarti lonjakan kecil barusan sedang mereda; pola menaik seperti 0.75 → 0.98 → 1.20 berarti beban justru sedang menumpuk. Opsi dan formatnya terdokumentasi di uptime(1) .

Sumber datanya tetap procfs. File /proc/loadavg memuat lima field yang bisa dibaca tanpa alat apa pun:

Spesifikasi kelima field ada di proc(5) — dan karena file ini hanyalah teks, perintah awk '{print $1}' /proc/loadavg cukup untuk memasukkan load 1 menit ke dalam skrip apa pun.

Load Tinggi Tidak Selalu Berarti CPU Penuh #

Mari kita rangkai jebakan dari awal chapter. Kasus klasiknya: monitoring melaporkan load 6.10 pada mesin 4 core — rasio 1.52, kategori sesak — padahal baris %Cpu(s) di top menunjukkan %id masih di angka 90 persen. Dua pembacaan yang tampak kontradiktif ini punya satu penjelasan: mayoritas antrean berisi proses state D yang menunggu I/O, bukan proses yang berebut core. Dua pemeriksaan cepat menutup kasusnya: lihat %wa di top (dibedah di Chapter CPU Monitoring ), lalu daftar proses yang sedang berstate D dengan ps -eo state,pid,comm | awk '$1 == "D"'. Bila daftarnya dipenuhi satu aplikasi yang sama, akar masalahnya ada di disk atau storage jaringan yang lambat — menambah core tidak akan menolong.

Skrip Status: Rasio dan Kategori #

Menggabungkan seluruh bab, berikut skrip mini yang membaca fixture /proc/loadavg, menghitung rasio tiap jendela waktu terhadap jumlah core, lalu memberi kesimpulan berdasarkan load 15 menit — angka paling stabil yang pantas menjadi dasar keputusan:

printf '2.50 2.10 1.80 2/206 54321\n' > loadavg.txt
printf '7.20 6.80 6.10 4/206 76543\n' > loadavg-sibuk.txt

cat > status-load.sh <<'SKRIP'
#!/bin/bash
# status-load.sh <file-loadavg> <jumlah-core>
awk -v core="$2" '{
  printf "1 menit : load %-5s rasio %.2f\n", $1, $1/core
  printf "5 menit : load %-5s rasio %.2f\n", $2, $2/core
  printf "15 menit: load %-5s rasio %.2f\n", $3, $3/core

  if ($3/core >= 1.0)      kesimpulan = "KRITIS"
  else if ($3/core >= 0.7) kesimpulan = "WASPADA"
  else                     kesimpulan = "SEHAT"
  printf "kesimpulan (berdasar load 15 menit): %s\n", kesimpulan
}' "$1"
SKRIP

bash status-load.sh loadavg.txt 4
bash status-load.sh loadavg-sibuk.txt 4

Output yang Dihasilkan:

1 menit : load 2.50  rasio 0.62
5 menit : load 2.10  rasio 0.53
15 menit: load 1.80  rasio 0.45
kesimpulan (berdasar load 15 menit): SEHAT
1 menit : load 7.20  rasio 1.80
5 menit : load 6.80  rasio 1.70
15 menit: load 6.10  rasio 1.52
kesimpulan (berdasar load 15 menit): KRITIS

Bedah skrip di atas:

1. Baris 7 (awk -v core="$2"): seluruh program awk menerima jumlah core sebagai variabel core lewat opsi -v, sehingga satu program bisa melayani mesin berapa pun tanpa mengubah kodenya.
2. Baris 8–10 (printf ... $1/core ...): tiga baris pertama mencetak ketiga jendela waktu lengkap dengan rasionya. Perhatikan urutan field di fixture: $1 load 1 menit, $2 load 5 menit, $3 load 15 menit.
3. Baris 12–15 (tangga if): kesimpulan diambil dari load 15 menit ($3) — jendela terpanjang yang paling kebal terhadap lonjakan sesaat — lalu dicetak pada baris terakhir. Skrip di mesin nyata berjalan dengan bash status-load.sh /proc/loadavg "$(nproc)".
4. Baris 19–20: dua fixture diuji. Sistem pertama nyaman di rasio 0.45. Sistem kedua memperlihatkan pola 1.80 → 1.70 → 1.52 yang menurun perlahan — jejak lonjakan besar barusan yang belum sepenuhnya reda — dan tetap divonis KRITIS oleh load 15 menitnya.

Dengan ini seluruh indikator dasar sudah terkumpul: CPU, memori, disk, jaringan, dan antrean. Tugas berikutnya bukan lagi membaca angka satu per satu, melainkan merangkainya menjadi diagnosis — gejala mana yang muncul lebih dulu, dan urutan mana yang menuntun ke akar masalah. Penyusunan itulah topik Chapter Performance Bottlenecks .