Server Solusi – Salah satu hal yang bisa membingungkan ketika mengelola VPS adalah melihat load average tinggi, padahal jumlah pengunjung website sedang sedikit. Penggunaan CPU bahkan bisa terlihat rendah ketika kamu membuka top.

Kondisi ini tidak otomatis berarti server mengalami serangan atau kekurangan CPU. Linux menghitung load average berdasarkan jumlah tugas yang sedang berjalan atau siap dijalankan, serta tugas yang menunggu operasi I/O dalam kondisi uninterruptible sleep. Artinya, proses yang tertahan menunggu akses disk juga dapat berkontribusi terhadap load average.

Untuk mengetahui penyebab sebenarnya, saya menyarankan memulai dari pemeriksaan proses, aktivitas disk, penggunaan memori, dan log sistem. Jangan langsung menambah CPU atau me-restart server sebelum kamu menemukan petunjuk yang lebih jelas.

Apa yang harus diperiksa terlebih dahulu?

Jika Linux server mengalami load average tinggi saat trafik rendah, lakukan pemeriksaan berikut:

1. Jalankan uptime untuk melihat tren load average selama 1, 5, dan 15 menit.

2. Jalankan nproc untuk mengetahui jumlah CPU yang tersedia bagi lingkungan server.

3. Gunakan top dan ps untuk mencari proses yang menggunakan CPU atau berstatus D.

4. Periksa vmstat dan iostat untuk mencari indikasi antrean proses, tekanan memori, atau hambatan disk.

5. Periksa log kernel dan service untuk mencari error I/O, masalah storage, atau proses yang terus gagal.

Perlu diingat bahwa load average bukan persentase penggunaan CPU. Nilai 4 pada server dengan empat CPU memiliki arti yang berbeda dibandingkan nilai yang sama pada VPS dengan satu CPU. Bahkan perbandingan ini hanya menjadi petunjuk awal, bukan bukti tunggal bahwa server mengalami bottleneck.

Mengenali gejala dan kemungkinan penyebabnya

Load average tinggi bisa muncul dalam beberapa kondisi berbeda. Setiap kondisi membutuhkan pendekatan diagnosis yang berbeda pula.

Tabel tersebut merupakan panduan awal, bukan diagnosis final. Misalnya, CPU idle yang tinggi bersamaan dengan load average tinggi bisa mengarah pada hambatan I/O, tetapi kamu tetap perlu memeriksa status proses dan statistik perangkat sebelum menyimpulkan penyebabnya.

Baca JugaVPS Tidak Bisa Diakses Setelah Restart? Ini Cara Diagnosisnya

Apa arti load average 1, 5, dan 15 menit?

Linux menampilkan tiga nilai load average untuk menunjukkan kondisi selama tiga rentang waktu yang berbeda.

• Load 1 menit: membantu melihat perubahan beban terbaru.

• Load 5 menit: membantu memahami apakah beban bertahan selama beberapa menit.

• Load 15 menit: membantu melihat apakah server sebelumnya mengalami beban yang berkepanjangan.

Jika load 1 menit lebih tinggi daripada load 15 menit, beban mungkin sedang meningkat. Sebaliknya, jika load 1 menit sudah turun tetapi load 15 menit masih tinggi, server mungkin baru saja melewati periode beban berat.

Interpretasi tersebut tetap perlu dikonfirmasi dengan metrik lain karena load average merupakan nilai rata-rata, bukan gambaran lengkap kondisi server pada detik ini.

Periksa load average dan jumlah CPU yang tersedia

Langkah pertama adalah memastikan seberapa tinggi load average dibandingkan kapasitas CPU server.

Jalankan:

uptimenproccat /proc/loadavg

Perintah uptime menampilkan load average selama 1, 5, dan 15 menit. nproc menunjukkan jumlah unit pemrosesan yang tersedia bagi proses saat ini, sedangkan /proc/loadavg memberikan informasi tambahan tentang tugas yang sedang berjalan atau ada dalam antrean.

Contoh ilustrasi hasil uptime:

load average: 6.20, 5.80, 4.90

Angka tersebut hanya contoh, bukan hasil pengujian server tertentu.

Jika VPS menyediakan empat CPU, load average 6,20 patut diperiksa lebih lanjut karena rata-rata jumlah tugas yang runnable atau berada dalam kondisi uninterruptible cukup tinggi dibandingkan kapasitas CPU tersebut.

Namun, angka itu tidak membuktikan bahwa CPU menjadi penyebab utama.

Bagaimana membaca hasilnya?

• Jika load tinggi dan penggunaan CPU juga tinggi, cari proses yang menghabiskan waktu CPU.

• Jika load tinggi tetapi CPU banyak idle, periksa proses yang menunggu I/O.

• Jika load meningkat pada waktu tertentu, bandingkan dengan jadwal backup, cron job, dan maintenance database.

Jangan menggunakan nproc sebagai satu-satunya sumber untuk memahami batas CPU VPS. Pada lingkungan virtualisasi atau container, kuota CPU dan batas resource lain dapat memengaruhi kapasitas efektif yang tersedia.

Identifikasi proses yang menyebabkan beban

Setelah mengetahui kondisi load average, cari proses yang aktif. Tujuannya bukan sekadar menemukan proses dengan penggunaan CPU tertinggi, melainkan memahami apakah ada tugas yang terus berjalan, menunggu I/O, atau menghasilkan banyak worker.

Baca JugaCara Mengatasi Out of Memory di Linux VPS

Jalankan:

top

Perhatikan beberapa bagian berikut:

• %CPU: aktivitas CPU proses.

• %MEM: penggunaan memori proses.

• load average: nilai load pada bagian atas tampilan.

• wa atau iowait: waktu CPU menunggu operasi I/O, jika ditampilkan pada ringkasan CPU.

Tekan q untuk keluar dari top.

Jika kamu membutuhkan daftar proses yang lebih mudah dibaca, gunakan:

ps -eo pid,ppid,stat,%cpu,%mem,etime,comm \--sort=-%cpu | head -20

Perintah ini menampilkan hingga 20 baris teratas berdasarkan penggunaan CPU, termasuk PID, proses induk, status, penggunaan memori, dan waktu berjalan.

Perhatikan apakah ada proses seperti mysqld, mariadbd, php-fpm, lshttpd, nginx, backup, atau tar yang menghabiskan resource. Nama proses hanya petunjuk awal; jangan langsung menganggap aplikasi tertentu sebagai penyebab tanpa memeriksa aktivitasnya.

Mengapa proses berstatus D perlu diperhatikan?

Salah satu petunjuk penting saat load average tinggi adalah proses dengan status D.

Jalankan:

ps -eo pid,ppid,stat,wchan:32,comm,args \| awk 'NR == 1 || $3 ~ /^D/'

Status D menunjukkan proses berada dalam uninterruptible sleep. Kondisi ini sering berkaitan dengan penantian operasi I/O, misalnya akses storage, tetapi penyebab spesifiknya bergantung pada kernel dan lingkungan server.

Jika hasilnya menunjukkan beberapa proses berstatus D, perhatikan kolom WCHAN dan nama prosesnya. Informasi tersebut bisa membantu mengarahkan pemeriksaan berikutnya.

Contohnya, jika proses database atau worker web berulang kali tertahan, periksa perangkat penyimpanan, filesystem, dan log kernel. Jangan langsung menghentikan proses secara paksa karena proses yang sedang menunggu operasi kernel belum tentu bisa dihentikan dengan aman.

Penjelasan status load dan tugas yang menunggu I/O tersedia dalam dokumentasi /proc/loadavg Linux.

Periksa apakah disk I/O menjadi bottleneck

Disk I/O merupakan salah satu penyebab yang perlu dipertimbangkan ketika load average tinggi, tetapi penggunaan CPU tidak terlalu besar.

Aktivitas disk tidak hanya berasal dari pengunjung website. Database, proses backup, kompresi file, pemindaian malware, rotasi log, dan tugas pemeliharaan dapat menghasilkan operasi baca-tulis meskipun trafik HTTP sedang rendah.

Baca JugaCara Mengatasi Disk Full di Ubuntu Server Tanpa Menghapus Data Penting

Periksa antrean proses dan aktivitas I/O

Jalankan:

vmstat 1 5

Perintah ini mengambil lima laporan dengan interval satu detik. Baris pertama biasanya berisi rata-rata sejak boot, sedangkan baris berikutnya menunjukkan aktivitas selama interval pengamatan.

Fokus pada kolom berikut:

Kolom tersebut membantu membedakan antrean CPU, aktivitas memori, dan aktivitas I/O. Namun, nilai wa yang rendah tidak otomatis menyingkirkan semua kemungkinan masalah I/O.

Periksa latensi dan utilisasi perangkat disk

Jika tersedia, jalankan:

iostat -xz 1 5

Perintah ini menampilkan statistik CPU dan perangkat penyimpanan secara berkala.

Perhatikan:

• await: rata-rata waktu penyelesaian permintaan I/O, termasuk waktu antre.

• aqu-sz: rata-rata panjang antrean permintaan I/O.

• %util: proporsi waktu perangkat tercatat sibuk melayani permintaan.

Nilai await yang meningkat bersamaan dengan antrean yang bertambah bisa mengindikasikan masalah performa storage. Sementara itu, %util perlu ditafsirkan sesuai jenis perangkat dan arsitektur penyimpanan; pada SSD modern, perangkat virtual, atau storage paralel, nilai tersebut tidak selalu cukup untuk menyatakan perangkat sudah mencapai batas kapasitas.

Jika iostat belum tersedia, kamu dapat memasang paket sysstat pada distribusi yang sesuai:

# Debian / Ubuntusudo apt-get install sysstat# RHEL / Rocky Linux / AlmaLinuxsudo dnf install sysstat

Sesuaikan perintah dengan distribusi Linux dan kebijakan administrasi server kamu.

Apa yang harus dilakukan jika disk menjadi sumber masalah?

Jika ditemukan latensi tinggi atau antrean I/O yang tidak wajar, lanjutkan dengan pemeriksaan berikut:

1. Identifikasi proses yang sedang membaca atau menulis data secara intensif.

2. Periksa apakah backup, kompresi, atau pemindaian file sedang berlangsung.

3. Cari error storage dan filesystem di log kernel.

   Baca JugaCara Mengatasi Permission Denied Saat SSH di Linux

4. Periksa metrik storage dari penyedia VPS jika disk yang digunakan merupakan storage virtual.

Jangan langsung menghapus file log atau menjalankan pembersihan disk secara agresif. Tindakan tersebut belum tentu menyelesaikan masalah latensi dan justru dapat menghilangkan bukti yang diperlukan untuk diagnosis.

Periksa penggunaan RAM dan aktivitas swap

Ketika memori tidak mencukupi, Linux dapat memindahkan sebagian halaman memori ke swap. Jika aktivitas ini berlangsung intensif, akses disk tambahan dapat memperburuk performa aplikasi.

Meski demikian, swap yang terpakai tidak selalu menandakan masalah. Linux dapat mempertahankan halaman memori yang jarang digunakan di swap meskipun kondisi server masih normal.

Untuk memeriksa kondisi memori, jalankan:

free -h

Lalu periksa aktivitas swap selama beberapa detik:

vmstat 1 5

Perhatikan nilai si dan so. Nilai yang terus aktif selama pengamatan, terutama ketika aplikasi melambat dan tekanan memori tinggi, merupakan alasan untuk melakukan pemeriksaan lebih lanjut.

Kamu juga bisa melihat proses yang menggunakan memori paling besar:

ps -eo pid,ppid,%mem,rss,comm,args \--sort=-%mem | head -20

Solusi jika masalah berkaitan dengan RAM

Jika ditemukan tekanan memori:

• Periksa apakah jumlah worker PHP, proses database, atau aplikasi lain terlalu besar untuk kapasitas VPS.

• Tinjau konfigurasi buffer dan cache database sesuai kebutuhan workload.

• Kurangi concurrency secara terukur jika terlalu banyak worker berjalan bersamaan.

• Pertimbangkan penambahan RAM jika beban normal memang melampaui kapasitas yang tersedia.

Jangan langsung mematikan swap atau membersihkan page cache untuk menurunkan angka load average. Tindakan tersebut tidak menyelesaikan penyebab dasarnya dan dapat memperburuk performa.

Periksa cron job, backup, dan service yang berjalan otomatis

Website dengan trafik rendah tetap dapat menghasilkan beban server yang tinggi akibat proses internal.

Contohnya meliputi:

• Backup database dan file website.

• Pemindaian keamanan atau malware.

• Kompresi dan rotasi log.

• Scheduled task dari aplikasi web.

• Cron job yang mengalami kegagalan berulang.

• Worker antrean yang terus memproses tugas.

• Maintenance database.

Jika load average sering naik pada waktu yang sama, jadwal pekerjaan otomatis patut diperiksa.

Periksa cron milik pengguna saat ini

crontab -l

Untuk memeriksa cron milik root:

sudo crontab -l

Periksa juga konfigurasi cron sistem:

ls -la /etc/cron.d/ls -la /etc/cron.hourly/ls -la /etc/cron.daily/

Tidak semua pekerjaan otomatis dijalankan melalui cron. Pada sistem yang menggunakan systemd, periksa timer dengan:

systemctl list-timers --all

Jika ditemukan jadwal backup yang bertepatan dengan lonjakan load, cocokkan waktu tersebut dengan log dan metrik disk. Jangan langsung menonaktifkan tugas karena pekerjaan itu mungkin penting untuk pemulihan data atau keamanan server.

Solusi yang lebih aman adalah menjadwalkan ulang pekerjaan berat ke waktu yang sesuai, mengurangi konkurensi, atau membatasi penggunaan resource jika software yang digunakan mendukungnya.

Periksa log kernel dan service

Jika pemeriksaan CPU, disk, dan memori belum menemukan penyebab, log sistem dapat memberikan petunjuk tambahan.

Periksa pesan kernel terbaru:

sudo journalctl -k -p warning --since "1 hour ago"

Perintah tersebut menampilkan pesan kernel dengan tingkat warning atau lebih serius selama satu jam terakhir, jika tersedia dalam journal.

Untuk melihat log service tertentu:

sudo journalctl -u nama-service --since "1 hour ago"

Ganti nama-service dengan nama unit yang benar, misalnya service database atau web server yang digunakan.

Cari pesan yang berkaitan dengan:

• Timeout atau kegagalan operasi I/O.

• Error filesystem atau perangkat penyimpanan.

• Proses yang dihentikan oleh mekanisme Out of Memory (OOM).

• Restart service berulang.

• Kegagalan koneksi ke storage atau resource eksternal.

Log yang tidak menunjukkan error bukan bukti bahwa server sehat. Sebagian masalah performa tidak menghasilkan pesan warning, sehingga hasil log tetap perlu dibandingkan dengan metrik dan status proses.

Terapkan perbaikan sesuai hasil diagnosis

Setelah pemeriksaan awal selesai, pilih tindakan berdasarkan bukti yang ditemukan.

Hindari restart sebagai langkah diagnosis pertama

Me-restart server atau seluruh service dapat menghilangkan kondisi sementara yang sebenarnya membantu mengungkap penyebab masalah. Restart juga dapat mengganggu website, koneksi database, dan pekerjaan yang sedang berlangsung.

Jika service memang mengalami kegagalan dan restart diperlukan, pastikan kamu sudah memeriksa log yang relevan, memahami dampaknya, dan memiliki rencana pemulihan.

Jangan menjalankan kill -9 secara massal atau mengubah permission sistem secara sembarangan hanya untuk menurunkan load average. Tindakan seperti itu tidak mengatasi masalah storage atau antrean proses yang mendasarinya.

Verifikasi apakah masalah sudah teratasi

Sesudah melakukan perubahan, ulangi pemeriksaan dalam kondisi yang sebanding dengan kondisi awal.

Jalankan:

uptimevmstat 1 5free -h

Jika masalah awal berkaitan dengan disk, ulangi:

iostat -xz 1 5

Bandingkan hasil sebelum dan sesudah perubahan. Periksa apakah antrean proses menurun, aktivitas swap membaik, latensi disk berkurang, atau penggunaan CPU menjadi lebih wajar.

Jika service aplikasi terkait, periksa statusnya:

systemctl status nama-service

Kemudian uji website dari sisi server:

curl -sS -o /dev/null \-w 'HTTP %{http_code} | Total %{time_total}s\n' \https://domainkamu.com/

Ganti https://domainkamu.com/ dengan domain yang kamu kelola.

Perintah curl tersebut mengukur waktu respons permintaan dari lingkungan server tempat perintah dijalankan. Hasilnya tidak selalu mewakili pengalaman pengunjung dari jaringan eksternal, sehingga pengujian dari luar server tetap berguna.

Perbaikan dapat dianggap menjanjikan jika metrik yang sebelumnya bermasalah membaik dan website tetap berfungsi normal. Namun, satu pengukuran sesaat belum cukup untuk memastikan masalah tidak akan muncul kembali.

Cara mencegah load average tinggi terulang

Pencegahan yang paling berguna adalah memantau metrik yang berkaitan langsung dengan penyebab masalah.

Saya menyarankan beberapa langkah berikut:

1. Simpan metrik historis. Pantau load average, CPU, RAM, swap, disk I/O, dan latensi aplikasi agar lonjakan dapat dibandingkan dengan kondisi normal.

2. Evaluasi jadwal pekerjaan otomatis. Pastikan backup, pemindaian, dan maintenance tidak menumpuk pada waktu yang sama.

3. Sesuaikan jumlah worker. Pastikan konfigurasi PHP-FPM, database, dan aplikasi sesuai dengan kapasitas VPS.

4. Pantau kapasitas storage. Periksa ruang disk dan inode, serta error perangkat penyimpanan jika tersedia.

5. Pertahankan log yang relevan. Atur rotasi log agar penyimpanan tidak penuh dan informasi diagnostik tetap tersedia.

6. Uji perubahan konfigurasi secara bertahap. Catat perubahan yang dilakukan sehingga dampaknya dapat dievaluasi dan dikembalikan jika diperlukan.

Jika server berada di lingkungan VPS, jangan lupa bahwa sebagian metrik hardware berada di bawah kendali penyedia hosting. Ketika proses di dalam VPS terlihat normal tetapi performa storage atau CPU tetap tidak konsisten, data metrik tersebut dapat menjadi dasar untuk meminta pemeriksaan lebih lanjut kepada penyedia.

FAQ: Linux server load average tinggi padahal trafik rendah

1. Apakah load average tinggi selalu berarti CPU penuh?

Tidak. Load average mencakup tugas yang runnable serta tugas dalam kondisi uninterruptible sleep. Karena itu, masalah I/O dapat meningkatkan load average meskipun penggunaan CPU tidak mencapai 100%.

2. Mengapa CPU usage rendah tetapi load average tinggi?

Salah satu kemungkinan adalah banyak proses sedang menunggu operasi I/O, misalnya akses storage. Namun, kondisi tersebut perlu dikonfirmasi dengan memeriksa status proses, statistik vmstat, latensi disk, dan log kernel.

3. Apakah load average 5 berbahaya untuk VPS?

Tidak bisa ditentukan hanya dari angkanya. Load average 5 perlu ditafsirkan berdasarkan jumlah CPU yang tersedia, tren waktunya, dan kondisi workload. Nilai tersebut dapat menunjukkan antrean yang perlu diperiksa pada VPS kecil, tetapi belum tentu menandakan masalah pada server dengan kapasitas CPU lebih besar.

4. Apakah restart VPS bisa menurunkan load average?

Restart dapat menghilangkan proses tertentu atau kondisi sementara, tetapi tidak otomatis menyelesaikan akar masalah. Jika penyebabnya adalah storage yang lambat, konfigurasi worker yang berlebihan, atau scheduled task, masalah bisa muncul kembali.

5. Perintah apa yang paling berguna untuk diagnosis awal?

Mulai dengan uptime, top, vmstat 1 5, dan free -h. Jika ada indikasi masalah disk, lanjutkan dengan iostat -xz 1 5. Gunakan hasilnya untuk menentukan pemeriksaan berikutnya, bukan sebagai dasar untuk langsung mengubah konfigurasi.

Penutup

Linux server load average tinggi padahal trafik rendah bukan berarti website sedang menerima terlalu banyak pengunjung. Beban tersebut juga dapat berasal dari proses internal, antrean CPU, tekanan memori, aktivitas disk, atau tugas yang tertahan menunggu I/O.

Mulailah dengan memeriksa load average dan jumlah CPU, lalu identifikasi proses, amati aktivitas disk dan memori, serta cocokkan temuan dengan log sistem dan jadwal pekerjaan otomatis. Setelah penyebabnya lebih jelas, lakukan perubahan yang sesuai dan verifikasi hasilnya dengan pengukuran berulang.

Jika load average tetap tinggi tanpa penyebab yang jelas, kumpulkan output uptime, top, vmstat, iostat, dan log yang relevan. Data tersebut akan jauh lebih membantu untuk diagnosis lanjutan daripada sekadar mengandalkan angka load average.