Saya tidak menulis ini sebagai ulasan negatif tentang REGXA, dan saya juga tidak mencoba memberi tahu orang apakah mereka sebaiknya membeli VPS dari sana atau tidak. Ini hanya salah satu hari saya sebagai developer.
Saya memindahkan workload normal ke VPS KVM dengan 2 vCPU, RAM 2 GB, dan NVMe 60 GB. Nginx berjalan. Backend berjalan. Tetapi mesin berperilaku seolah-olah sangat overload: request menumpuk, operasi TLS melambat, koneksi tetap terbuka, dan beberapa request akhirnya menghasilkan HTTP 504 setelah lebih dari dua menit.
Perhitungan CPU mengubah arah investigasi
Dugaan pertama saya sederhana: ada sesuatu di dalam VPS yang menghabiskan CPU. Lalu saya menjalankan mpstat.
Average CPU steal: 92.58%
CPU 0 steal: 90.62%
CPU 1 steal: 94.57%
CPU user: 4.02%
CPU system: 1.47%
CPU iowait: 0.41%
CPU idle: 0.53%Sample individual berulang kali menunjukkan sekitar 89–98% steal. Tekanan CPU juga sangat tinggi:
CPU PSI some avg10: 79.47
CPU PSI some avg60: 75.32
CPU PSI some avg300: 76.31
Load average: 5.85 / 5.75 / 5.73Ini hanya mesin dengan dua vCPU. Linux memiliki proses runnable yang menunggu CPU. Angka terpenting bukan penggunaan CPU normal oleh aplikasi, melainkan %steal.
CPU tinggi dan CPU steal adalah masalah yang berbeda
Jika aplikasi saya benar-benar membebani processor, saya akan mengharapkan nilai user atau system yang tinggi. Kenyataannya, VPS kurang lebih terlihat seperti ini:
user: 4%
system: 1%
steal: 93%CPU steal adalah waktu ketika virtual CPU siap berjalan tetapi hypervisor tidak menjadwalkannya. Jadi ketika saya mengatakan waktu CPU diambil dari VPS, saya menggunakan arti teknis dalam virtualisasi tersebut. Saya tidak bisa membuktikan bahwa REGXA sengaja memindahkan physical core yang secara eksklusif milik saya ke pelanggan lain, dan guest metrics juga tidak menunjukkan niat. Yang bisa saya buktikan adalah guest berulang kali memiliki pekerjaan yang siap dijalankan tetapi tidak mendapat CPU scheduling time.
Saya menghapus semua trafik produksi
Masih ada keberatan yang masuk akal: mungkin workload saya sendiri yang menyebabkan masalah. Jadi saya menghilangkan variabel itu. Saya memindahkan workload aktif ke tempat lain, menghentikan trafik produksi ke VPS ini, membiarkan queue kosong, lalu mengulang pengukuran.
Average CPU steal: 94.17%
CPU 0 steal: 95.56%
CPU 1 steal: 92.83%
CPU user: 1.95%
CPU system: 0.59%
CPU iowait: 0.59%
CPU idle: 2.18%Hasilnya malah lebih buruk. Sample vmstat tetap menunjukkan 91–98% steal, dan hingga 15 proses runnable menunggu CPU. Kombinasi terpentingnya adalah:
user: 1.95%
system: 0.59%
steal: 94.17%Aplikasi saya hampir tidak melakukan apa pun, tetapi VM masih kehilangan hampir seluruh waktu scheduling-nya. Trafik produksi normal tidak lagi menjadi penjelasan yang masuk akal.
Bahkan localhost menjadi sangat lambat
Saya juga menguji HTTPS melalui 127.0.0.1, sehingga public DNS, ISP saya, jarak geografis, dan jalur jaringan eksternal tidak ikut memengaruhi pengujian.
Saat ada trafik, empat dari sepuluh percobaan HTTPS localhost gagal saat TLS handshake. Request yang berhasil membutuhkan 29,30, 22,77, 12,25, 11,87, 11,12, dan 9,40 detik. Beberapa TLS handshake saja memakan waktu sekitar sembilan detik.
Setelah trafik produksi dihapus, localhost membaik tetapi tetap tidak stabil: 0,061, 0,745, 0,830, 0,873, 1,010, 1,117, 1,121, 2,188, dan 3,355 detik. Operasi lokal yang sama bisa selesai sekitar 61 ms sekali, lalu lebih dari 3,3 detik pada percobaan berikutnya.
Seluruh stack menunjukkan dampaknya
Pada satu titik saya melihat sekitar 450 koneksi established, 122 orphaned, 110 FIN-WAIT-1, dan 33 CLOSE-WAIT. Listen queue backend lokal mencapai sekitar 14–15, sementara queue HTTPS mencapai sekitar 40.
Nginx mencatat HTTP 504 setelah 142,857, 138,902, 135,064, 129,819, dan 128,657 detik. Request lain tetap terbuka sekitar 67–130 detik. Saya juga melihat secure-connect timeout sekitar 35–41 detik, database network timeout, dan operasi TLS yang terlambat.
Secara terpisah, gejala tersebut dapat terlihat seperti masalah Nginx, database, jaringan, atau backend yang berbeda. Tetapi menambah timeout tidak menciptakan CPU time yang tidak dijadwalkan oleh hypervisor.
RAM dan disk tidak menjelaskan masalah ini
VPS masih memiliki sekitar 1,0–1,1 GiB RAM tersedia, penggunaan swap nyaris nol, tidak ada OOM event, dan tidak ada aktivitas OOM killer. Filesystem hanya terisi sekitar 20%, dengan kira-kira 44 GB tersedia. I/O wait tetap di bawah 1% saat pengukuran CPU yang penting.
Memori tidak habis, disk tidak penuh, dan aplikasi saya tidak menghabiskan CPU yang hilang. Metric dominan tetap %steal.
VPS KVM yang sehat terlihat benar-benar berbeda
Saya menjalankan jenis diagnosis yang sama pada VPS KVM lain yang sedang menangani trafik normal:
Average CPU steal: 0.02%
CPU idle: 87.86%
CPU PSI avg10: 0.29
CPU PSI avg60: 0.63
CPU PSI avg300: 0.49
Load average: 0.47 / 0.33 / 0.14Sepuluh request HTTPS localhost selesai dalam sekitar 37–69 ms. Belakangan saya mengukur VPS produksi lain yang benar-benar sibuk dan mendapatkan 61,71% user CPU, 5,08% system CPU, 24,09% idle, dan hanya 0,13% steal.
Itulah perbedaan yang sekarang penting bagi saya. VPS bisa sibuk karena software saya memang menggunakan processor. Itu sangat berbeda dari guest yang menghabiskan lebih dari 90% waktu CPU terukur untuk menunggu hypervisor.
REGXA akhirnya mengonfirmasi contention pada infrastrukturnya
Dari dalam VM saya dapat mengukur guest, tetapi tidak dapat melihat physical host, konfigurasi scheduler, CPU quota, atau VM tetangga. REGXA dapat melihatnya.
Support akhirnya menjelaskan bahwa VPS berjalan pada shared CPU infrastructure, bahwa resource CPU dibagi di antara beberapa virtual machine, dan performa dapat berubah tergantung load pada physical node. Mereka juga mengatakan infrastruktur Frankfurt sedang mengalami demand yang sangat tinggi dan secara eksplisit mengaitkan CPU steal saya yang tinggi dengan resource contention on the underlying infrastructure.
Mereka mengatakan tidak bisa mengubah CPU quota atau scheduling policy maupun memberikan resource CPU dedicated tambahan untuk VPS shared tersebut pada infrastruktur saat ini. Solusi teknis yang ditawarkan adalah memindahkan VPS ke lokasi dengan utilization lebih rendah.
Penjelasan itu sulit saya selaraskan dengan bahasa produk yang pernah saya lihat tentang dedicated CPU cores dan guaranteed resources. Saya tidak dapat melihat konfigurasi host yang tepat, sehingga tidak bisa mengatakan apakah mekanisme langsungnya adalah CPU overcommitment, quota, scheduler weighting, throttling, atau kombinasi beberapa hal. Saya juga tidak bisa membuktikan niat. Itu tidak perlu: Linux menunjukkan steal 92–94% secara berkelanjutan, dan REGXA sendiri mengaitkannya dengan contention pada shared infrastructure mereka.
Mendapatkan refund juga membutuhkan perjuangan tambahan
Setelah masalah infrastrukturnya jelas, saya tidak ingin terus memindahkan VPS dan mencoba node lain. Saya ingin membatalkan layanan dan mendapatkan uang saya kembali.
Awalnya saya hanya ditawari sebagian dari jumlah pembayaran, dan refund yang diusulkan masuk ke saldo akun REGXA, bukan kembali ke kartu yang saya gunakan. Bagi saya, saldo internal provider tidak sama dengan refund ketika saya ingin meninggalkan layanan.
Jadi saya terus membalas dan meminta 100% pembayaran dikembalikan ke original payment method. Akhirnya REGXA setuju dan mengembalikan seluruh jumlah ke metode pembayaran awal, sambil menyebut full refund tersebut sebagai pengecualian.
Saya menghargai bahwa pada akhirnya mereka mengembalikan semuanya. Namun fakta bahwa saya masih harus terus mendorong penyelesaian finansial setelah support mengakui infrastructure contention juga merupakan bagian dari pengalaman saya.
Pelajaran yang saya bawa dari kejadian ini
Kesalahan termudah adalah terus mengoptimalkan aplikasi saya. Saya bisa mengubah Nginx, menaikkan timeout, menurunkan concurrency, menambah retry, memeriksa MongoDB, atau menulis ulang backend. Beberapa hal mungkin akan mengubah gejala tertentu. Tetapi tidak satu pun menjawab pertanyaan penting: mengapa CPU steal berada di atas 90%?
Sekarang saya tidak berhenti setelah memastikan SSH bekerja, Nginx start, dan health endpoint mengembalikan 200. Pada VPS baru saya juga memeriksa %user, %system, %iowait, %idle, %steal, CPU PSI, run queue, dan latency localhost.
Jika sesuatu terlihat mencurigakan, saya menghapus workload lalu mengukur ulang. Dalam kasus ini, langkah itu menghasilkan angka paling jelas dari seluruh insiden:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%Saya tidak mengatakan bahwa semua VPS REGXA berperilaku seperti ini. Saya menguji satu VPS dan mendokumentasikan apa yang terjadi pada mesin tersebut. Namun pada VPS itu buktinya sangat jelas: aplikasi saya hampir tidak menggunakan CPU, sementara Linux menunjukkan sebagian besar virtual CPU time hilang untuk menunggu penjadwalan hypervisor. REGXA kemudian mengaitkan perilaku yang sama dengan resource contention pada shared infrastructure mereka.
Itulah alasan saya mendokumentasikannya. Bukan sebagai skor atau rekomendasi, tetapi sebagai satu hari dalam kehidupan saya sebagai developer — dan satu metric yang tidak akan pernah lagi saya abaikan pada VPS.