Sudah Pindah ke VPS dengan vCPU Lebih Banyak, Kenapa Load Average Tetap Tinggi?

Pola ini sering muncul: load average VPS terus di atas jumlah core, jadi paket di-upgrade dari 2 vCPU ke 8 vCPU. Setelah pindah, angka load di uptime tetap tinggi, sementara top menunjukkan CPU usage hanya belasan persen. Wajar kalau orang menyimpulkan vCPU barunya tidak bekerja. Kenyataannya, load average di Linux tidak hanya mengukur CPU, dan di situlah sumber salah pahamnya.

Apa yang sebenarnya dihitung load average di Linux

Load average adalah tiga angka yang muncul di uptime, top, atau /proc/loadavg. Ketiganya mewakili rata-rata 1, 5, dan 15 menit. Rata-rata ini bukan rata-rata biasa. Kernel menghitung ulang angkanya secara berkala (kira-kira setiap beberapa detik) dengan exponential moving average, yaitu rata-rata yang memberi bobot lebih besar ke kondisi terbaru tapi tetap membawa sisa nilai lama. Karena itu angka 1 menit bisa turun pelan walaupun bebannya sudah hilang. Yang dijumlahkan kernel setiap kali menghitung adalah banyaknya task di dua state:

R (running/runnable): sedang jalan di CPU atau antre menunggu giliran CPU.
D (uninterruptible sleep): sedang tidur menunggu sesuatu dan tidak bisa diganggu signal. Biasanya yang ditunggu adalah I/O disk.

Task di state S (interruptible sleep), misalnya worker PHP-FPM yang idle menunggu request atau daemon yang menunggu koneksi, tidak ikut dihitung. State D inilah yang membedakan Linux dari sebagian sistem Unix lain, yang hanya menghitung task runnable. Linux sengaja memasukkan state D supaya load average mencerminkan permintaan terhadap sistem secara keseluruhan, bukan hanya CPU. Efeknya, load average Linux lebih tepat dibaca sebagai panjang antrean pekerjaan yang belum selesai, entah antre CPU atau antre disk. Di meja support, hal ini paling sering membingungkan pelanggan. Mereka melihat angka load, membandingkannya dengan jumlah core, lalu langsung menyimpulkan CPU kurang. Aturan "load di atas jumlah core berarti overload" hanya masuk akal kalau hampir semua task-nya berstatus R.

Kenapa proses bisa tertahan di state D

Saat aplikasi membaca file yang belum ada di page cache, prosesnya memanggil syscall seperti read(). Kernel lalu membuat request I/O ke block layer, dan request itu masuk ke queue perangkat disk. Selama data belum kembali, proses tidak bisa melanjutkan apa pun, jadi kernel menaruhnya di state D sampai I/O selesai. Alasan state ini dibuat tidak bisa diinterupsi: kernel sedang memegang struktur data yang setengah jadi, misalnya buffer yang menunggu diisi DMA dari disk. Kalau proses dibangunkan di tengah jalan oleh signal, kondisinya bisa tidak konsisten. Inilah sebabnya proses yang macet di state D sering tidak mati walaupun sudah dikirim kill -9. Signal-nya baru diproses setelah I/O-nya selesai atau gagal. Selain baca-tulis disk lokal, state D juga sering muncul karena:

Mount NFS atau network storage yang lambat atau putus.
Flush dirty page ke disk saat banyak data ditulis sekaligus, misalnya saat backup, dump database, atau ekstraksi arsip besar.
Swap. Kalau RAM penuh, proses yang menyentuh halaman memori yang sudah di-swap out harus menunggu disk.

Di VPS, disk virtual biasanya berbagi storage fisik dengan tenant lain di host yang sama. Latency-nya bisa naik karena hal yang tidak terlihat dari dalam VM. Dari sisi guest, yang terlihat hanya proses yang menumpuk di state D.

Kenapa vCPU tambahan tidak menurunkan angkanya

Kalau load tinggi berasal dari antrean CPU, menambah vCPU memang membantu. Task R yang tadinya antre kini punya lebih banyak tempat untuk jalan, jadi antreannya memendek. Task D tidak menunggu CPU. Task itu menunggu disk. Delapan vCPU yang semuanya idle tetap tidak bisa membuat disk merespons lebih cepat. Selama throughput dan latency storage-nya sama, jumlah task yang tertahan di D juga kurang lebih sama, dan load average ikut bertahan. Ada dua efek samping yang membuat situasinya terasa makin aneh:

Load bisa malah naik. Dengan vCPU lebih banyak, aplikasi bisa menjalankan lebih banyak worker paralel. Contohnya pool PHP-FPM atau thread MySQL yang dihitung dari jumlah core. Lebih banyak worker berarti lebih banyak request I/O yang dikirim bersamaan ke disk yang sama, sehingga lebih banyak task berakhir di state D.
Persentase iowait terlihat mengecil. wa di top adalah porsi waktu CPU idle sementara masih ada I/O yang belum selesai, dirata-rata ke semua CPU. Kalau jumlah task yang menunggu disk sama tapi jumlah CPU-nya empat kali lipat, rata-ratanya jadi lebih kecil. Hasilnya, CPU tampak santai, iowait tampak rendah, tapi load average tetap tinggi.

Satu catatan khusus VPS: ada juga steal time (st), yaitu waktu ketika vCPU siap jalan tapi hypervisor sedang memberikan CPU fisik ke VM lain. Task yang terkena steal masih berstatus R, jadi tetap terhitung di load. Kalau st konsisten tinggi, masalahnya ada di kepadatan host, bukan di disk.

Membedakan antrean CPU dan antrean disk

Langkah pertama yang paling cepat adalah vmstat dengan interval satu detik. Kolom r menunjukkan jumlah task runnable, dan kolom b menunjukkan task yang terblokir (state D).

BASH

vmstat 1 5

Baris pertama berisi rata-rata sejak boot, jadi abaikan dan baca baris-baris berikutnya. Contoh format output (angka ilustratif, bukan dari server nyata):

TEXT

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1 12      0 204800  51200 1024000    0    0  4000  8000  900 1500  5  3 60 32  0
 2 11      0 201000  51200 1025000    0    0  3800  8200  950 1600  6  3 59 32  0

Cara membacanya: r kecil (di bawah jumlah vCPU) tapi b besar artinya antreannya ada di I/O. Kalau r konsisten melebihi jumlah vCPU dan us/sy tinggi, barulah itu antrean CPU. Perhatikan juga si dan so. Kalau nilainya tidak nol, sistem sedang swap, dan masalah intinya kemungkinan RAM, bukan disk. Kolom st di sini sama dengan steal time di top. Di top, lihat baris %Cpu(s) untuk nilai wa dan st. Kolom S di daftar proses menunjukkan state masing-masing proses. Untuk melihat proses apa saja yang sedang di state D beserta fungsi kernel yang ditunggunya, ps lebih praktis. Untuk melihat perangkat mana yang tertekan, pakai iostat -x dari paket sysstat:

BASH

# Proses di state D dan fungsi kernel yang sedang ditunggu (wchan)
ps -eo stat,pid,wchan:32,cmd | awk '$1 ~ /^D/'

# Statistik per disk, interval 1 detik, 3 kali (butuh paket sysstat)
iostat -x 1 3

Di output iostat -x, fokus ke latency per request (r_await dan w_await di versi baru, await di versi lama) dan panjang antrean (aqu-sz, atau avgqu-sz di versi lama). Latency yang naik bersamaan dengan antrean yang panjang adalah tanda disk tidak sanggup mengikuti permintaan. %util boleh dilihat, tapi jangan dipercaya mentah-mentah untuk SSD atau NVMe, karena perangkat jenis ini memproses banyak request paralel. %util yang mendekati 100 belum tentu berarti disk sudah mentok. Kalau kernelnya cukup baru dan fiturnya aktif, /proc/pressure/io (PSI, Pressure Stall Information) juga berguna. Isinya persentase waktu ketika task tertahan menunggu I/O. Angka ini lebih langsung daripada menebak dari load average.

Setelah ketemu antrean disk, apa yang dicek

Kolom cmd dari ps biasanya langsung menunjukkan pelakunya. Yang sering muncul: mysqld, proses backup atau kompresi, rsync, atau worker PHP yang semuanya menunggu di fungsi kernel yang sama. Kalau pelakunya database, cek apakah data aktif sudah muat di memori. Buffer pool yang terlalu kecil membuat MySQL terus membaca ke disk untuk data yang sebenarnya sering dipakai. Cara mengukurnya dibahas di Cara Memastikan Ukuran InnoDB Buffer Pool di Server Sudah Pas. Kalau polanya muncul di jam tertentu, cocokkan dengan jadwal cron, backup, atau tugas maintenance. Kalau beban aplikasinya wajar tapi latency disk tetap tinggi, masalahnya bisa ada di lapisan virtualisasi atau storage host. Controller disk virtual yang dipakai juga berpengaruh ke cara antrean I/O diproses. Penjelasannya ada di Perubahan Performa Disk Saat Beralih dari VirtIO Block ke VirtIO SCSI. Untuk VPS, data iostat dan vmstat ini juga bahan yang kuat saat bertanya ke provider soal performa storage atau steal time, karena isinya angka, bukan sekadar "server terasa lambat". Yang perlu diingat: load average Linux mengukur antrean, bukan pemakaian CPU. Sebelum memutuskan upgrade, jalankan vmstat 1 selama beberapa detik dan bandingkan kolom r dengan b. Kalau yang menumpuk adalah b, uangnya lebih berguna untuk RAM tambahan, storage yang lebih cepat, atau perbaikan pola I/O aplikasi, bukan untuk vCPU.