---
title: "Server Lambat Padahal CPU Rendah? Ini Penyebabnya"
description: "CPU rendah tapi website lambat? Kenali iowait, CPU steal, tekanan memori, DNS lambat, lock database, dan latensi jaringan, plus cara mengeceknya."
url: "https://nivelva.com/insight/server-lambat-cpu-rendah"
category: "Server \u0026 Infrastruktur"
tags: ["server lambat","iowait","cpu steal","troubleshooting linux","vps"]
author: "Theresia Candiawan"
published: "2026-11-07T05:22:00+07:00"
updated: "2026-11-07T05:22:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Server Lambat Padahal CPU Rendah? Ini Penyebabnya

> **Jawaban singkat:** CPU rendah tidak berarti server sehat. Penyebab lambat yang umum adalah antrean disk (iowait), CPU steal di VPS, memori yang memaksa swap, lookup DNS yang lambat, lock di database, dan latensi jaringan. Masing-masing bisa dicek dengan top, iostat, vmstat, dig, dan log database.

Tim penjualan mengeluh dasbor internal butuh lima detik untuk terbuka. Kamu membuka `top`, dan angka CPU hanya belasan persen. Load average tidak menakutkan, tidak ada proses yang rakus. Godaan pertama adalah menyalahkan internet kantor, padahal pengguna dari rumah mengeluhkan hal yang sama.

Situasi ini membingungkan karena kita terbiasa menyamakan "server berat" dengan "CPU tinggi". Kenyataannya, waktu tunggu di server web sering bukan dihabiskan untuk menghitung, melainkan untuk menunggu: menunggu disk, menunggu jatah CPU dari hypervisor, menunggu database melepas kunci, atau menunggu jawaban DNS. Selama menunggu, CPU tampak santai.

## Mulai dari satu baris di top

Baris `%Cpu(s)` di `top` lebih informatif daripada angka persen di bagian proses. Perhatikan tiga kolom: `us` dan `sy` (kerja nyata), `wa` (iowait, CPU menganggur karena menunggu disk), dan `st` (steal, waktu yang diambil hypervisor untuk mesin virtual lain). Dua kolom terakhir inilah yang sering menjelaskan server lambat dengan CPU rendah.

Jalankan juga `vmstat 1` selama setengah menit. Kolom `r` menunjukkan proses yang sedang berjalan atau menunggu giliran CPU, `b` menunjukkan proses yang tertahan menunggu I/O, dan `si`/`so` menunjukkan aktivitas swap. Pola dari beberapa detik ini sering langsung menunjuk arah penyelidikan.

| Penyebab | Gejala yang terlihat | Perintah untuk mengecek |
|:--|:--|:--|
| Antrean disk (iowait) | `wa` tinggi, kolom `b` di vmstat terisi | `iostat -x 1`, `iotop` |
| CPU steal | `st` di top konsisten di atas beberapa persen | `top`, `vmstat 1` (kolom `st`) |
| Tekanan memori | Swap terpakai, `si`/`so` aktif | `free -h`, `vmstat 1` |
| DNS lambat | Permintaan ke layanan luar lama di awal | `dig domain.com`, `cat /etc/resolv.conf` |
| Lock database | Query menumpuk dengan status menunggu | `SHOW PROCESSLIST`, slow query log |
| Latensi jaringan | Waktu koneksi tinggi, paket hilang | `mtr`, `curl -w`, `ss -s` |

## Disk yang tidak sanggup mengikuti

Iowait tinggi berarti proses menunggu disk membaca atau menulis data. Pemicunya bisa backup yang berjalan di jam sibuk, database yang tidak muat di RAM sehingga terus membaca dari disk, log yang ditulis sangat sering, atau disk VPS dengan kuota IOPS kecil.

`iostat -x 1` (dari paket sysstat) menampilkan kolom `%util` dan `await`. Kalau `%util` mendekati 100 dan `await` naik, disk sedang jenuh. `iotop` membantu menemukan proses mana yang paling banyak menulis. Solusinya tergantung pelaku: pindahkan backup ke jam sepi, perbesar buffer database agar data aktif ada di RAM, atau pindah ke penyimpanan yang lebih cepat.

## CPU steal di VPS bersama

Di VPS, CPU fisik dibagi beberapa mesin virtual. Kolom `st` menunjukkan berapa lama vCPU-mu siap bekerja tetapi tidak mendapat giliran dari hypervisor. Nilai kecil yang sesekali muncul itu wajar. Nilai yang konsisten tinggi berarti server fisik sedang sibuk melayani tamu lain, dan aplikasimu ikut tertahan walau bebannya ringan.

Kamu tidak bisa memperbaiki steal dari dalam VPS. Yang bisa dilakukan adalah mencatat polanya (jam berapa, berapa persen) lalu melaporkannya ke penyedia, atau mempertimbangkan paket dengan vCPU dedicated. Perbedaan jenis layanan ini juga disinggung di [memilih spesifikasi VPS](https://nivelva.com/insight/memilih-spesifikasi-vps).

## Memori yang diam-diam habis

Server bisa tampak santai sementara RAM sudah penuh dan kernel memindahkan memori ke swap. Setiap kali aplikasi butuh data yang sudah dipindah, ia harus menunggu disk. Hasilnya mirip iowait, tapi akarnya kekurangan RAM.

`free -h` menunjukkan pemakaian swap, dan `vmstat 1` menunjukkan apakah swap aktif bergerak. Perhatikan juga kolom `available`, bukan `free`, karena Linux memakai RAM kosong untuk cache. Pembahasan lengkapnya ada di artikel [swap di Linux untuk VPS kecil](https://nivelva.com/insight/swap-linux-vps-kecil).

## Penyebab di luar server: DNS dan jaringan

Aplikasi modern sering memanggil layanan lain: API pembayaran, server email, layanan penyimpanan. Setiap panggilan diawali lookup DNS. Kalau resolver yang dipakai server lambat atau salah satu server di `/etc/resolv.conf` tidak menjawab, setiap permintaan bisa tertahan beberapa detik sebelum mencoba resolver berikutnya. Uji dengan `dig domain-tujuan.com` dan lihat baris `Query time`.

Untuk jaringan, `curl -o /dev/null -s -w "%{time_connect} %{time_starttransfer}\n" https://alamat` memisahkan waktu koneksi dan waktu menunggu jawaban. Waktu koneksi tinggi menunjuk ke jaringan, waktu menunggu tinggi menunjuk ke aplikasi di sisi tujuan. `mtr alamat` memperlihatkan di titik mana paket mulai hilang. `ss -s` membantu melihat apakah jumlah koneksi menumpuk tidak wajar.

## Bagaimana kalau ternyata database yang mengunci?

Database bisa membuat seluruh aplikasi menunggu tanpa memakai banyak CPU. Satu query panjang yang mengunci tabel membuat query lain antre di belakangnya. Di MySQL atau MariaDB, `SHOW FULL PROCESSLIST` menampilkan query yang sedang berjalan beserta statusnya, dan status seperti menunggu lock adalah petunjuk kuat. Aktifkan slow query log untuk menemukan query yang perlu dibenahi, misalnya karena tidak memakai index. Setelan yang paling berpengaruh dibahas di [optimasi MySQL dan MariaDB](https://nivelva.com/insight/optimasi-mysql-mariadb).

Hal serupa berlaku di sisi aplikasi: jumlah worker PHP-FPM yang terlalu sedikit membuat permintaan antre walau server menganggur. Log PHP-FPM biasanya mencatat peringatan ketika batas `max_children` tercapai. Menaikkan batas itu tanpa melihat sisa RAM justru bisa memindahkan masalah ke memori, jadi hitung dulu rata-rata memori per worker dengan `ps` atau `top` sebelum mengubahnya. Hal yang sama berlaku untuk pool koneksi database di aplikasi: terlalu kecil membuat permintaan antre, terlalu besar membebani database.

Jadi, kalau server lambat tapi CPU rendah, periksa berurutan: `top` untuk `wa` dan `st`, `vmstat 1` untuk swap dan antrean, `iostat -x 1` untuk disk, lalu log aplikasi dan database, dan terakhir DNS serta jaringan. Catat jam kejadian, karena banyak masalah hanya muncul saat backup, cron, atau jam ramai. Dengan alat pemantauan yang merekam riwayat, pola seperti ini jauh lebih mudah ditemukan daripada menebak saat keluhan datang.

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/server-lambat-cpu-rendah
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com