Kenapa VPS Terlihat Longgar tapi Website Lemot?

Kamu cek dashboard VPS saat klien lapor website lambat. CPU 8%, RAM terpakai 1,2 GB dari 4 GB, bandwidth nyaris tidak bergerak. Semua angka aman.

Tapi websitenya memang lambat.

Ini salah satu situasi yang paling membingungkan: VPS terlihat longgar, tapi performa tidak mencerminkan itu. CPU dan RAM hanyalah dua variabel dari banyak yang menentukan seberapa cepat server merespons request. Yang sering jadi masalah justru tidak tampil di panel utama: kecepatan baca-tulis disk, apakah CPU kamu benar-benar dedicated, bagaimana PHP menangani antrian request, dan apakah ada query database yang memakan waktu lebih dari seharusnya.

Artikel ini membahas cara investigasi keempat area itu, termasuk cara baca outputnya dan langkah setelah ketemu sumbernya.

Kenapa Dashboard VPS Bisa “Berbohong”?

Panel monitoring VPS menampilkan apa yang mudah diukur, bukan apa yang paling relevan untuk mendiagnosis performa. CPU usage, RAM, dan bandwidth tersedia secara default karena mudah dikumpulkan, bukan karena ketiganya cukup untuk menggambarkan kondisi server secara utuh.

Masalahnya, sebagian besar bottleneck tidak tinggal di sana.

Disk I/O throttling tidak tampil di panel standar. CPU steal, yaitu waktu di mana CPU kamu menunggu karena hypervisor sedang melayani VPS lain di host yang sama, juga tidak. PHP-FPM yang kehabisan worker tidak akan terlihat dari RAM usage. Query database yang lambat tidak akan menggerakkan satu pun grafik di dashboard.

Jadi saat VPS terlihat longgar di semua indikator yang tersedia, bukan berarti server sedang santai. Bisa jadi server sedang menunggu disk, menunggu giliran CPU, atau mengantri request yang tidak terselesaikan. Dashboard hanya tidak menampilkan itu.

Ini bukan soal dashboard yang cacat. Memang begitu cara kerja monitoring generik: cukup untuk memantau, tidak cukup untuk mendiagnosis. Untuk tahu apa yang sebenarnya terjadi, kamu perlu masuk ke level yang lebih dalam dari sekadar angka persentase.

IOPS: Kenapa Disk Bisa Jadi Bottleneck di VPS yang Terlihat Longgar

IOPS (Input/Output Operations Per Second) mengukur seberapa banyak operasi baca-tulis yang bisa dilakukan disk per detik. Di VPS, ini resource yang dibagi antar pengguna di host yang sama, dan provider yang overselling storage bisa membuat kamu kena throttle meski CPU dan RAM masih rendah.

Gejalanya tidak selalu jelas: response time naik di jam tertentu, server terasa stuck sebentar lalu jalan lagi, tapi tidak sampai timeout.

Untuk cek langsung:

Perhatikan kolom %util dan await. Di atas 80% untuk %util dan 20ms untuk await saat CPU masih rendah, bottleneck nya hampir pasti di I/O. Untuk tahu proses mana yang paling banyak makan IOPS:

Kalau VPS terlihat longgar di CPU dan RAM tapi %util disknya tinggi, tuning konfigurasi aplikasi tidak akan banyak membantu selama IOPS nya terbatas di level infrastruktur.

CPU Steal: Ketika CPU Kamu Tidak Sepenuhnya Milik Kamu

Di environment virtualisasi, satu server fisik menjalankan banyak VPS sekaligus. CPU steal adalah waktu di mana proses kamu siap dieksekusi, tapi hypervisor sedang melayani VPS lain di host yang sama. Hasilnya: aplikasi terasa lambat meski tidak ada proses berat yang berjalan.

Bedanya dengan CPU wait: wa terjadi karena proses menunggu I/O selesai, st terjadi karena CPU nya yang tidak tersedia. Keduanya bisa muncul bersamaan tapi penyebabnya berbeda.

Cara cek:

Cari angka di belakang st pada baris breakdown CPU. Steal di bawah 2% masih wajar. Kalau angkanya konsisten di atas 5%, perlu dicurigai server fisiknya memang sedang terlalu padat. Untuk data per interval yang lebih informatif dari sekadar snapshot:

Kolom st di output vmstat menunjukkan steal per detik selama 10 detik pengamatan, cukup untuk membedakan spike sesaat dari masalah yang persisten.

Kalau VPS terlihat longgar dari sisi CPU usage tapi steal nya tinggi dan konsisten, ini biasanya bukan sesuatu yang bisa diselesaikan dari sisi konfigurasi saja.

PHP-FPM: Antrian Request yang Tidak Terlihat di Dashboard

PHP-FPM mengelola proses PHP melalui sistem pool: setiap request masuk ditangani oleh satu worker. Kalau semua worker sedang sibuk dan request baru terus datang, request itu masuk antrian. Antrean penuh, server kembalikan 502 atau 504.

Yang tidak terlihat di dashboard: RAM masih ada, CPU masih rendah, tapi website tidak merespons karena workernya habis.

Ada dua mode pool:

• static – jumlah worker tetap sejak awal, cocok untuk traffic yang polanya stabil
• dynamic – menyesuaikan jumlah worker sesuai kebutuhan, tapi batas atasnya perlu dikonfigurasi dengan hati-hati

Masalah paling umum di VPS kecil: pm.max_children diset terlalu tinggi dengan asumsi lebih banyak worker lebih baik. Padahal setiap worker PHP-FPM bisa makan 20-50 MB RAM tergantung aplikasinya. Kalau RAM habis, sistem pakai swap, dan di situlah performa benar-benar turun.

Untuk cek status pool, aktifkan pm.status_path di konfigurasi PHP-FPM lalu akses endpointnya. Perhatikan dua nilai ini:

• active processes – berapa worker yang sedang aktif menangani request
• listen queue – berapa request yang sedang menunggu worker kosong

Kalau listen queue tidak pernah nol saat traffic normal, jumlah workernya kurang.

Cara hitung pm.max_children yang lebih realistis: bagi RAM yang dialokasikan untuk PHP dengan rata-rata konsumsi per proses. Rata-rata proses makan 40 MB, RAM tersedia 800 MB, maksimalnya sekitar 20 worker.

Database Query: Masalah yang Sering Disalahkan ke Server

Sebelum tuding server, cek querynya dulu.

Database yang lambat tidak selalu butuh RAM lebih besar atau CPU lebih kencang. Sering kali masalahnya ada di cara query ditulis atau di struktur tabel yang tidak dioptimasi. Dua penyebab paling umum:

Missing index. MySQL harus baca seluruh tabel untuk menemukan baris yang dicari. Makin besar tabel, makin lama. Ini yang disebut full table scan.

N+1 query. Aplikasi menjalankan satu query untuk ambil daftar data, lalu satu query lagi untuk setiap item di daftar itu. 100 produk di halaman = 101 query ke database.

Cara paling cepat untuk investigasi: aktifkan slow query log di MySQL.

Query yang butuh lebih dari 1 detik akan tercatat. Dari sana, jalankan EXPLAIN di query yang mencurigakan:

Perhatikan kolom type di outputnya:

Nilai type	Artinya
ALL	Full table scan, perlu diperhatikan
ref atau eq_ref	Pakai index, sudah lebih baik
const	Paling efisien

Kalau type nya ALL di tabel yang besar, tambah index di kolom yang sering jadi filter. Seringkali ini saja sudah cukup untuk memotong waktu query secara signifikan.

Yang perlu diingat: query lambat mengunci koneksi lebih lama. Kalau koneksi habis, request berikutnya menunggu, dan website terasa lambat meski VPS terlihat longgar di semua metrik lainnya.

Urutan Investigasi yang Masuk Akal

Keempat area yang sudah dibahas bisa muncul bersamaan, tapi hampir selalu ada satu yang paling dominan. Masalahnya, kalau langsung loncat ke PHP-FPM atau database padahal bottlenecknya ada di CPU steal, tuning yang dilakukan tidak akan terasa hasilnya.

Urutan di bawah ini dimulai dari yang paling susah diperbaiki sendiri, turun ke yang bisa langsung ditangani.

Langkah 1: CPU steal

Ini yang paling perlu dicek pertama karena kalau steal nya tinggi, semua investigasi lain perlu mempertimbangkan konteks itu. Steal tinggi artinya ada resource contention di level host, bukan di VPS kamu.

Lihat nilai st. Konsisten di atas 5% perlu dicurigai.

Langkah 2: IOPS

Setelah steal, cek apakah disk jadi bottleneck. Ini relevan terutama kalau aplikasi kamu banyak melakukan operasi baca-tulis file, seperti WordPress dengan banyak plugin aktif.

%util tinggi dengan await di atas 20ms saat CPU masih rendah adalah tanda yang cukup jelas.

Langkah 3: PHP-FPM

Kalau dua langkah pertama tidak menunjukkan masalah signifikan, masuk ke PHP-FPM. Cek apakah workernya cukup untuk menampung traffic yang masuk.

Akses pm.status_path yang sudah diaktifkan sebelumnya. Fokus ke nilai listen queue. Tidak pernah nol saat traffic normal artinya worker kurang.

Langkah 4: Database

Langkah terakhir karena masalah query biasanya lebih mudah diisolasi dibanding tiga area sebelumnya. Aktifkan slow query log, cari query yang butuh lebih dari 1 detik, jalankan EXPLAIN untuk melihat apakah ada full table scan.

Kalau semua langkah sudah dijalankan dan hasilnya tidak konklusif, kemungkinan masalahnya kombinasi dari beberapa faktor. Itu butuh pendekatan berbeda dari investigasi satu per satu, dan biasanya perlu dilihat secara bersamaan dalam satu sesi monitoring.

Opsi Perbaikan: Dari yang Bisa Langsung Dilakukan sampai yang Perlu Dipertimbangkan

Hasil investigasi menentukan langkah berikutnya. Tidak semua masalah butuh solusi yang sama.

Kalau masalahnya di PHP-FPM atau database, perbaikan bisa langsung dikerjakan tanpa menyentuh infrastruktur:

• Hitung ulang pm.max_children berdasarkan RAM aktual
• Aktifkan OPcache untuk mengurangi operasi baca file PHP
• Tambah index di kolom yang sering jadi filter query
• Review query dengan EXPLAIN, fokus ke yang type nya ALL di tabel besar

Perubahan ini sering cukup membuat perbedaan yang terasa, terutama kalau konfigurasi PHP-FPM belum pernah disentuh dari nilai default.

Kalau masalahnya di IOPS atau CPU steal, ruangnya lebih terbatas. Caching di level aplikasi, Redis atau Memcached untuk session dan object cache, dan penjadwalan ulang cron job bisa mengurangi dampaknya. Tapi kalau throttle nya dari sisi provider, optimasi aplikasi tidak menghilangkan sumbernya.

Kalau setelah semua itu VPS terlihat longgar di dashboard tapi performa tidak membaik, resource yang kamu bayar kemungkinan tidak sepenuhnya sampai ke aplikasi. VPS dengan alokasi resource dedicated memastikan IOPS dan CPU yang dijanjikan memang tersedia saat dibutuhkan, bukan bergantian dengan pengguna lain di host yang sama.

DomaiNesia Cloud VPS Lite bisa jadi opsi yang perlu dilihat kalau kamu sedang di tahap evaluasi ini.

Cek Paket VPS

Sudah Investigasi, Lalu Apa?

Investigasi performa VPS bukan tentang menemukan satu angka yang salah. Lebih sering, masalahnya tersebar di beberapa area sekaligus dan baru terasa setelah traffic naik atau aplikasi makin kompleks.

Yang perlu diingat: kalau sudah jalankan semua langkah investigasi di atas dan hasilnya masih tidak konklusif, bukan berarti tidak ada masalah. Bisa jadi masalahnya memang kombinasi, atau infrastrukturnya sendiri yang sudah tidak sesuai dengan kebutuhan sekarang.

VPS terlihat longgar bukan selalu tanda bahwa server kamu baik-baik saja. Kadang itu tanda bahwa metrik yang kamu pantau belum cukup mewakili kondisi sebenarnya.

Kalau investigasi sudah selesai dan masalahnya memang ada di level infrastruktur, langkah selanjutnya cukup jelas: cari VPS yang IOPS nya terdefinisi dan CPU nya tidak berbagi dengan siapa pun di host yang sama.

DomaiNesia Cloud VPS Lite bisa jadi pilihan yang layak dievaluasi. Spesifikasi dan harganya bisa langsung dicek di sini: Cloud VPS Lite.