VPS AVA Hosting Saya Mencatat Rata-rata CPU Steal 32,73% Meski Mengiklankan “Guaranteed Resources — No Sharing”

Saya tidak menulis ini sebagai ulasan negatif tentang AVA Hosting.

Ini hanya salah satu hari kerja saya sebagai developer: sebuah server bermasalah, penjelasan yang paling jelas tidak cocok, dan akhirnya Linux menunjukkan apa yang sebenarnya terjadi.

Saya memiliki VPS KVM kecil dari AVA Hosting dengan:

1 vCPU
2 GB RAM
25 GB NVMe

VPS tersebut menjalankan workload produksi normal. Nginx aktif. Backend aktif. Memori masih tersedia. Disk tidak penuh.

Namun server tidak mampu mengejar beban.

Saya kemudian menjalankan observasi pasif selama 60 detik di bawah trafik produksi normal. Tidak ada stress test, synthetic HTTP flood, atau benchmark disk.

Hasilnya:

vCPU count:             1

Average CPU user:       52.52%
Average CPU system:      8.07%
Average CPU softirq:     6.69%
Average CPU steal:      32.73%
Average CPU iowait:      0.00%
Average CPU idle:        0.00%

Maximum runnable queue: 11

Angka yang paling penting adalah 32,73% CPU steal. Dari sini diagnosis berubah total.

Mengapa hasil ini mengejutkan

AVA Hosting saat ini mengiklankan produk VPS-nya dengan frasa “Guaranteed resources — no sharing”. Halaman VPS mereka juga menggambarkan alokasi vCPU sebagai fixed atau dedicated dan menyebut performa seharusnya tidak dipengaruhi pelanggan lain. Dalam materi Linux VPS, AVA bahkan menyatakan workload CPU-intensive milik tenant lain pada host yang sama tidak dapat menimbulkan steal time pada instance Anda. Halaman lainnya mengatakan CPU steal dieliminasi pada level hypervisor.

Itu klaim yang sangat spesifik. Ini bukan sekadar halaman VPS yang menampilkan 1 vCPU tanpa menjelaskan model alokasi CPU. AVA secara eksplisit mengiklankan perlindungan dari jenis CPU contention yang justru tampak sedang dilaporkan Linux di dalam VM saya.

Apa arti CPU steal

steal adalah metrik CPU Linux yang normal dalam lingkungan virtualisasi. Metrik ini menunjukkan waktu ketika guest memiliki pekerjaan runnable, tetapi CPU virtual tidak benar-benar berjalan.

Ini berbeda dengan aplikasi saya sekadar menggunakan seluruh CPU yang tersedia. Jika saya melihat sekitar 100% user/system, 0% steal, dan 0% idle, saya akan menyimpulkan workload memang membutuhkan daya komputasi lebih besar.

Dalam kasus saya, sekitar sepertiga pencatatan waktu CPU justru berupa steal.

Dari dalam guest saya tidak dapat melihat hypervisor AVA. Saya tidak tahu beban physical node, jumlah VM tetangga, kebijakan CPU pinning, atau rasio overcommit. Yang dapat saya lihat adalah apa yang dilaporkan Linux kepada VM saya: vCPU berulang kali tidak berjalan saat masih ada pekerjaan yang menunggu.

Ini bukan lonjakan satu detik

Satu sampel CPU yang buruk tidak akan cukup meyakinkan. Karena itu saya mengukur mesin secara terus-menerus selama 60 detik. Saya sengaja tidak menjalankan stress test, synthetic HTTP flood, ataupun benchmark disk.

Sampel per detik berulang kali terlihat seperti ini:

%usr    %sys   %soft   %steal   %idle
53.54   10.10   5.05    31.31     0.00
56.44    6.93   5.94    30.69     0.00
51.52    7.07   6.06    35.35     0.00
55.45    6.93   5.94    31.68     0.00
51.49    8.91   5.94    33.66     0.00
52.53    7.07   7.07    33.33     0.00
52.48    6.93   7.92    32.67     0.00

Menjelang akhir observasi, pola yang sama masih terlihat:

50.98   10.78   6.86    31.37     0.00
48.48    8.08   9.09    34.34     0.00
55.00    5.00   7.00    33.00     0.00

Rata-rata keseluruhan:

user:       52.52%
system:      8.07%
softirq:     6.69%
steal:      32.73%
iowait:      0.00%
idle:        0.00%

Jadi ini bukan anomali scheduling singkat. Selama sebagian besar menit tersebut, steal tetap berada di sekitar 30% atau lebih, sementara CPU idle terus berada di nol.

Untuk gambaran, 32,73% dari satu menit setara sekitar 19,64 detik. Ini tidak berarti VPS membeku selama 19,64 detik berturut-turut; artinya interval kecil ketika vCPU tidak dijadwalkan terakumulasi hingga kira-kira sejumlah itu.

Backend tidak mampu mengejar antrean

Masalah CPU juga terlihat di level aplikasi. Sebelum observasi, listen queue backend adalah:

Recv-Q: 168
Send-Q: 511

Setelah 60 detik:

Recv-Q: 166
Send-Q: 511

Angka tepatnya bukan hal utama. Yang penting, antrean praktis tidak berkurang. Aplikasi memiliki satu menit penuh untuk mengejar backlog tetapi tetap tertinggal.

Ada juga banyak koneksi CLOSE-WAIT. Saya tidak akan menyalahkan host hanya berdasarkan kondisi itu, karena penanganan koneksi di sisi aplikasi juga dapat menyebabkannya. Namun gambaran keseluruhannya konsisten:

1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not draining

Server hidup, tetapi tidak sehat.

RAM dan disk bukan bottleneck yang jelas

Saya memeriksa penyebab umum lainnya. Kondisi memori:

RAM total:      ~1.9 GiB
RAM available:  ~959 MiB
Swap total:     2 GiB
Swap used:      ~33 MiB

Masih ada cukup banyak memori tersedia dan tidak ada kejadian OOM yang jelas untuk menjelaskan perilaku tersebut.

Kondisi filesystem:

24 GB total
14 GB used
9.4 GB available
60% used

Rata-rata CPU I/O wait adalah 0.00%. Sementara itu CPU pressure tetap mendekati 99%, load average berada di sekitar 3,5–4 pada VM satu-vCPU, dan runnable queue mencapai 11.

Semua pengukuran mengarah ke kesimpulan yang sama: mesin kekurangan waktu CPU, bukan jelas-jelas terhambat RAM atau storage.

Kontradiksi dengan pernyataan AVA

Inilah bagian yang paling menarik bagi saya.

AVA mengatakan “Guaranteed resources — no sharing”. Mereka mengatakan performa tidak seharusnya dipengaruhi pelanggan lain. Materi Linux VPS mereka mengatakan tenant lain tidak dapat menimbulkan steal time, dan halaman lain menyebut CPU steal dieliminasi pada level hypervisor.

VPS AVA saya menunjukkan:

Average CPU steal: 32.73%

Dari dalam VM saya tidak dapat membuktikan secara pasti mengapa hal itu terjadi. Saya tidak dapat membuktikan overselling yang disengaja, menunjuk workload tetangga tertentu, atau merekonstruksi konfigurasi CPU di host AVA.

Saya juga tidak menyatakan semua VPS AVA Hosting berperilaku seperti ini. Saya menguji satu VPS.

Namun saya dapat mengatakan bahwa perilaku yang saya ukur sangat sulit diselaraskan dengan klaim spesifik tentang isolasi CPU tersebut. Itu sudah cukup untuk artikel ini.

Mengapa saya tidak upgrade

Respons yang paling jelas tentu membeli lebih banyak vCPU.

Jika VPS memberikan steal nyaris nol dan aplikasi saya memang menghabiskan satu core penuh, upgrade akan masuk akal. Namun sekitar sepertiga pencatatan CPU yang saya amati justru berupa steal.

Saya tidak ingin membayar CPU virtual tambahan sebelum memahami mengapa sebagian besar waktu eksekusi vCPU pertama sudah dilaporkan tidak tersedia. Jadi saya membatalkan VPS dan meminta refund.

AVA mengembalikan seluruh uang dengan cepat

Bagian pengalaman ini berjalan baik.

AVA Hosting mengembalikan seluruh jumlah pembayaran. Refund diproses cepat dan mereka tidak menghabiskan berhari-hari memperdebatkan pengukuran CPU saya. Saya menjelaskan masalahnya, meminta uang kembali, dan mereka mengembalikannya.

Saya menghargai itu.

Jadi ada dua kesimpulan terpisah dari pengalaman saya: VPS yang saya terima memiliki masalah serius pada ketersediaan CPU, dan AVA menangani refund saya dengan baik. Keduanya benar.

Hal yang saya pelajari

Saya tidak lagi menilai VPS hanya dari spesifikasi seperti 1 vCPU / 2 GB RAM / NVMe / KVM. Angka tersebut menunjukkan apa yang diprovisioning, tetapi tidak menunjukkan seberapa konsisten CPU akan tersedia di bawah workload nyata.

Sekarang salah satu pemeriksaan pertama saya pada VM baru adalah:

mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60

Pelajaran paling berguna dari pengalaman saya dengan AVA Hosting bukan bahwa satu vCPU terlalu kecil. Pelajarannya adalah proses yang tetap berjalan, RAM yang masih tersedia, dan disk yang terlihat sehat dapat menyembunyikan masalah yang sama sekali berbeda.

Dalam kasus saya, Linux membuatnya sangat jelas:

CPU steal:    32.73%
CPU idle:      0.00%
CPU pressure: ~99%

AVA Hosting mengiklankan resource CPU tanpa sharing dan mengatakan steal akibat workload tetangga seharusnya tidak terjadi. VPS saya melaporkan hal yang berbeda.

Saya membatalkannya. AVA mengembalikan seluruh uang saya dengan cepat dan tanpa perdebatan.

Dan di situlah hari debugging ini berakhir.