Load Average Tinggi di Linux, Apa Artinya dan Solusinya

Load average tinggi berarti banyak proses yang sedang bekerja atau mengantre untuk bekerja, lebih banyak daripada yang bisa dilayani server dengan nyaman.

Kenapa ini penting? Karena load average sering disalahartikan sebagai "persen CPU". Ada admin yang panik melihat angka 4 di server 8 core yang sebenarnya santai, dan ada juga yang mengabaikan angka 3 di server 1 core yang antreannya sudah panjang. Selain itu, di Linux load tinggi bisa terjadi saat CPU hampir menganggur, karena prosesnya sedang menunggu disk. Membaca angka ini dengan benar menentukan apakah kamu perlu mengoptimalkan aplikasi, memeriksa disk, atau menambah CPU.

Apa arti tiga angka load average?

Jalankan uptime atau lihat baris pertama top. Kamu akan menemukan sesuatu seperti load average: 2.15, 1.80, 1.20. Tiga angka itu adalah rata-rata dalam 1 menit, 5 menit, dan 15 menit terakhir.

Membaca urutannya membantu memahami arah:

• Angka 1 menit lebih tinggi dari 15 menit: beban sedang naik.
• Angka 1 menit lebih rendah dari 15 menit: beban mulai mereda.
• Ketiganya sama-sama tinggi: beban berat sudah berlangsung lama.

Yang dihitung adalah jumlah proses dalam status siap jalan (sedang memakai CPU atau menunggu giliran) ditambah proses dalam status uninterruptible sleep (status D), yang umumnya sedang menunggu operasi disk atau jaringan penyimpanan selesai. Bagian kedua inilah yang membuat Linux berbeda dari sistem lain.

Berapa load average yang dianggap tinggi?

Tidak ada angka tunggal. Patokannya adalah jumlah core CPU yang terlihat oleh sistem, yang bisa kamu cek dengan nproc. Di VPS, itu berarti jumlah vCPU (bedanya dengan core fisik dibahas di artikel apakah vCPU sama dengan core fisik).

Contoh: load 4 di server 8 core masih longgar. Load 4 di server 2 core berarti rata-rata ada dua proses yang selalu menunggu giliran.

Patokan ini hanya untuk beban CPU. Kalau load tinggi karena proses status D, menambah core tidak akan membantu.

Mencari penyebab load tinggi

1. Tentukan dulu: CPU atau I/O?

Buka top dan lihat baris %Cpu(s). Perhatikan tiga nilai:

• us dan sy tinggi: CPU benar-benar sibuk menjalankan aplikasi atau kernel.
• wa (I/O wait) tinggi: CPU menunggu disk. Load tinggi di sini berasal dari antrean I/O.
• st (steal) tinggi: di VPS, hypervisor sedang memberikan waktu CPU ke mesin virtual lain. Ini bukan kesalahan di dalam servermu.

Cara lain adalah vmstat 1 5. Kolom r menunjukkan proses yang menunggu CPU, kolom b menunjukkan proses yang terblokir, biasanya oleh I/O.

2. Bila CPU yang penuh

Urutkan proses berdasarkan pemakaian CPU di top (tekan P) atau htop. Penyebab yang sering ditemui: worker PHP yang menjalankan halaman berat, query database tanpa index, cron yang berjalan bersamaan, kompresi backup, atau bot yang membanjiri website. Langkah lengkapnya ada di artikel menemukan proses yang menghabiskan CPU.

Waspadai juga proses dengan nama aneh yang memakai CPU tinggi terus-menerus tanpa alasan jelas. Itu bisa tanda server dipakai menambang kripto secara diam-diam, seperti dijelaskan di artikel cryptojacking di server.

3. Bila I/O yang jadi penyebab

Cari proses yang berstatus D dengan ps -eo state,pid,cmd | grep "^D". Bila paket sysstat terpasang, iostat -x 1 5 menampilkan seberapa sibuk tiap disk; kolom %util yang mendekati 100 berarti disk kewalahan. Penyebab umumnya backup besar, database yang banyak menulis, log yang membengkak, atau RAM yang kurang sehingga server terus memakai swap. Pembahasan gejala serupa ada di artikel server lambat padahal CPU rendah.

4. Cocokkan dengan waktu kejadian

Load yang naik setiap jam yang sama biasanya terkait cron, backup, atau laporan terjadwal. Cek crontab -l dan timer systemd (systemctl list-timers). Menggeser jadwal ke jam sepi sering sudah cukup.

Kapan solusinya menambah resource?

Bila load tinggi disebabkan beban CPU yang sah (bukan proses nyasar atau konfigurasi boros) dan terjadi setiap jam sibuk, menambah vCPU masuk akal. Bila penyebabnya I/O, solusinya bisa berupa disk yang lebih cepat, RAM tambahan supaya cache file lebih besar, atau memindahkan database ke server terpisah. Bila steal time yang tinggi, masalahnya ada di host fisik, dan yang perlu dihubungi adalah penyedia server.

Sebelum memutuskan, kumpulkan data minimal satu sampai dua minggu. Alat pemantauan yang menyimpan riwayat load, pemakaian CPU per jenis (user, system, I/O wait, steal), dan aktivitas disk akan menunjukkan pola yang tidak terlihat dari satu kali menjalankan top. Dengan data itu, kamu bisa membedakan server yang memang kekurangan tenaga dari server yang hanya sibuk sebentar setiap tengah malam karena backup. Keputusan upgrade pun jadi berbasis bukti, bukan perasaan saat panik.