CPU Steal Time dan Noisy Neighbour pada VPS

Pengukuran sebenarnya dari CPU steal time

CPU steal time adalah proporsi waktu saat CPU virtual Anda siap berjalan dan tidak menunggu apa pun, tetapi hypervisor memberikan core fisik tersebut kepada guest lain. Pekerjaan Anda berada dalam antrean. Core tersebut sedang digunakan di tempat lain. Linux menghitung siklus ini secara terpisah dan melaporkannya sebagai st. Dengan demikian, Anda dapat membedakan antara “server saya sedang sibuk” dan “server saya sedang menunggu giliran”.

Perbedaan tersebut adalah alasan utama counter ini tersedia. Waktu yang digunakan proses Anda pada CPU dilaporkan sebagai us (user) atau sy (system). Waktu yang dihabiskan task dalam keadaan terblokir karena storage dilaporkan sebagai wa (I/O wait). vCPU (virtual CPU) yang runnable, berada dalam run queue, tidak memiliki I/O yang masih berjalan, tetapi tetap tidak dieksekusi, dilaporkan sebagai st. Tidak ada hal di dalam server Anda yang dapat menghapus kondisi tersebut, karena keputusan penjadwalan dibuat satu lapisan di bawah Anda, pada host.

Hal ini merupakan konsekuensi langsung dari cara VPS berbagi satu mesin fisik dengan banyak guest. Penyebab yang umum adalah guest lain: guest lain pada node yang sama menggunakan CPU secara intensif, sehingga host membagi core di antara Anda. Ada penyebab kedua yang sering terlewatkan. Banyak provider membatasi shared vCPU hingga sebagian dari satu core fisik, dan pada beberapa hypervisor, batas yang diberlakukan tersebut dicatat sebagai steal di dalam guest. Jadi, nilai st yang tinggi menunjukkan bahwa core tidak diberikan kepada Anda. Nilai tersebut tidak selalu menunjukkan siapa yang menggunakannya.

Asal angka steal

Kernel tidak dapat mengukur steal secara mandiri karena kernel tidak dapat melihat host. Hypervisor yang melaporkan nilainya. Pada KVM, host menulis penghitung per-vCPU ke dalam halaman yang digunakan bersama guest, lalu guest menjumlahkannya jika kernel dibangun dengan CONFIG_PARAVIRT_TIME_ACCOUNTING, yang digunakan oleh semua kernel distribusi. Xen melaporkan nilai yang sama melalui area runstate-nya. Nilai total tersedia di userspace tepat pada satu tempat:

head -1 /proc/stat

Baris cpu tersebut memuat sepuluh penghitung dalam tick USER_HZ sejak boot, dengan urutan berikut: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal adalah nilai kedelapan setelah label. Semua alat di bawah ini, yaitu vmstat, top, mpstat, dan exporter Prometheus, membaca field yang sama lalu mengubah dua sampel menjadi persentase.

Ada satu konsekuensi yang lebih penting daripada yang lain. Jika hypervisor tidak pernah mengekspor penghitung tersebut, field akan tetap bernilai nol selamanya, dan setiap alat yang menggunakannya akan melaporkan 0.0 yang rendah meskipun host mengalami beban berlebih. KVM dan Xen mengekspor nilai tersebut. Guest pada VMware dan Hyper-V umumnya melaporkan nilai nol yang tetap. Periksa platform sebelum mempercayai nilai nol:

systemd-detect-virt

Perintah tersebut mencetak nama platform, seperti kvm, xen, vmware, atau microsoft, serta none pada bare metal. Di dalam container, perintah tersebut justru melaporkan runtime, seperti lxc, docker, atau podman. Nilai itu memberikan informasi tentang container, bukan tentang mesin di bawahnya. Pada kvm, nilai nol merupakan bukti nyata bahwa host memperlakukan Anda dengan baik. Pada platform yang tidak pernah mengisi field tersebut, nilai nol sama sekali bukan bukti, sehingga contention harus dinilai dengan mengukur waktu yang diperlukan untuk menjalankan pekerjaan nyata.

Bagaimana cara memeriksa waktu steal CPU pada VPS?

vmstat berasal dari paket procps. Paket ini tersedia pada hampir semua image VPS Ubuntu dan Debian, tetapi tidak tersedia pada beberapa image container minimal. Instal paket tersebut sebelum mengandalkannya.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version mencetak baris seperti vmstat from procps-ng 4.0.4. Jika baris tersebut tercetak, berarti tool sudah terinstal dan Anda sedang membaca counter kernel yang sebenarnya. Selanjutnya, vmstat 1 5 mengambil satu sampel per detik sebanyak lima kali.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

Cari kolom st di blok cpu di sebelah kanan. Build procps-ng saat ini mencetak kolom gu setelahnya untuk waktu guest KVM. Karena itu, st berada di posisi kedua dari kanan, bukan posisi terakhir. Baca kolom berdasarkan nama header-nya, karena posisinya berubah antar-rilis.

Dua kebiasaan membantu menjaga pembacaan tetap akurat. Baris data pertama adalah rata-rata sejak boot, jadi abaikan baris tersebut dan baca baris setelahnya. Satu sampel juga bukan pengukuran yang memadai karena steal terjadi dalam burst. Jalankan vmstat 1 60 dan monitor selama satu menit penuh sebelum menarik kesimpulan.

top melaporkan angka yang sama pada baris ringkasan %Cpu(s), di dalam field yang ditandai st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

Untuk melihat detail per core, tambahkan sysstat:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat mencetak satu baris per CPU dengan kolom %steal. Kolom ini menunjukkan apakah setiap vCPU terdampak atau hanya satu vCPU. Untuk menyimpan riwayat yang diperlukan dalam tiket dukungan, simpan sampelnya, bukan hanya membacanya dari layar:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

Jalankan perintah tersebut dari cron selama jam-jam yang Anda curigai bermasalah. Dengan demikian, file tersebut menjadi perbedaan antara mengatakan kepada provider, "tadi malam terasa lambat", dan menunjukkan sepuluh menit yang tepat.

Apa arti angka steal?

• 0.0 yang stabil. Kondisi sehat, atau platform tidak melaporkan steal sama sekali. Konfirmasikan dengan systemd-detect-virt sebelum menyimpulkan.
• Lonjakan beberapa persen selama beberapa detik. Normal pada node bersama mana pun. Build milik pengguna lain dimulai, atau host menjalankan pencadangan.
• 1 hingga 5 persen secara terus-menerus pada paket bersama. Wajar. CPU bersama tercermin dalam harga layanan.
• 5 hingga 10 persen secara terus-menerus. Perlambatan yang dapat diukur. Mulailah mengumpulkan bukti dan bandingkan jam yang sama selama beberapa hari.
• Di atas 10 persen selama berjam-jam. Node terlalu padat untuk beban kerja Anda. Tingkat ini cukup menjadi alasan untuk membuat tiket dukungan atau pindah layanan.

Gunakan rentang tersebut sebagai panduan pembacaan, bukan sebagai spesifikasi, karena tidak ada provider yang menerbitkan jaminan steal untuk paket bersama. Nilai hasilnya berdasarkan beban kerja yang Anda jalankan. Pekerjaan batch semalaman dapat menoleransi steal sebesar 15 persen tanpa disadari. Service yang sensitif terhadap latensi akan menunjukkannya pada p99 jauh sebelum nilai rata-rata terlihat mengkhawatirkan. Karena itu, beban kerja sensitif terhadap latensi seperti bot trading sebaiknya dijalankan pada core khusus.

Berapa biaya steal time bagi Anda?

Perhitungannya singkat. Jika sebagian s waktu CPU Anda diambil, tugas yang memerlukan jumlah CPU tetap akan memerlukan waktu 1 / (1 - s) kali lebih lama pada jam dinding. Untuk tugas yang memerlukan 60 detik CPU:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

Pada 3 persen, yang merupakan kondisi umum pada paket shared, tugas tersebut memerlukan 61.9 detik, bukan 60.0 detik. Tidak ada yang akan membuka tiket untuk perbedaan itu. Pada 8 persen, waktunya menjadi 65.2 detik. Pada 40 persen, tugas yang sama memerlukan 100.0 detik, dan antrean yang sebelumnya dapat dikosongkan mulai bertambah panjang.

Nilai tersebut adalah hasil perhitungan, bukan hasil pengukuran. Model ini mengasumsikan satu thread yang siap dijalankan dan steal time yang tersebar merata sepanjang interval. Layanan nyata sering terasa lebih lambat daripada yang ditunjukkan kurva karena jatah waktu yang diambil dapat terjadi di tengah pemrosesan request, lalu penundaan tersebut kembali dirasakan oleh semua proses yang menunggu request itu. Untuk memperoleh angka Anda sendiri, bukan sekadar rumus, lakukan benchmark pada VPS selama jam yang tenang lalu ulangi saat jam sibuk, dengan mencatat st untuk kedua periode tersebut.

Apakah ini steal, atau masalah lain?

Steal mudah tertukar dengan gejala lain. Baca penghitung tersebut secara bersamaan, pada baris vmstat yang sama.

• st tinggi, sedangkan r dan us tetap rendah: host tidak memberikan core kepada Anda. Itu adalah steal.
• r jauh di atas jumlah vCPU Anda, dengan us tinggi dan st mendekati nol: beban kerja Anda melebihi kemampuan CPU sendiri. Bandingkan r dengan output nproc. Ini adalah oversubscription dari sisi Anda sendiri, bukan dari tetangga.
• wa tinggi dengan st mendekati nol: task terblokir pada storage. Ini masalah yang berbeda dan memerlukan solusi yang berbeda.
• Load average tinggi, sedangkan st dan us sama-sama rendah: angka load juga menghitung task yang tidak dapat diinterupsi. Jadi, kondisi ini biasanya menunjukkan device yang macet atau network mount yang hang, bukan masalah CPU.

Paket burstable memerlukan penjelasan tersendiri. Paket ini menyediakan saldo kredit yang bertambah saat Anda idle dan berkurang saat Anda sibuk. Saat saldo habis, provider menahan Anda pada kecepatan baseline. Pada beberapa platform, throttle tersebut dilaporkan sebagai steal. Pada platform lain, kondisi ini tidak terlihat dari dalam instance, dan Anda hanya mendapatkan lebih sedikit siklus per detik. Baca deskripsi paket sebelum menyimpulkan bahwa penyebabnya adalah tetangga.

Mengapa container melaporkan steal time nol

Steal merupakan properti virtual machine, bukan container yang berjalan di dalamnya. Docker container pada VPS milik Anda sendiri berbagi /proc milik host, sehingga nilai st yang dibaca di dalamnya adalah steal milik VPS. Nilai tersebutlah yang Anda perlukan. Virtualisasi berbasis container yang dijual sebagai VPS berperilaku berbeda. Jika lxcfs digunakan, nilai /proc/stat di dalam container dibuat dari pencatatan cgroup, sehingga steal selalu bernilai nol. Stack pemantauan yang hanya mengambil metrik dari dalam container dapat menampilkan angka nol yang datar, sementara mesin fisik di bawahnya kekurangan sumber daya CPU.

Di dalam container, penghitung yang memiliki arti serupa adalah throttling CPU berdasarkan kuota. Pada cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled menghitung periode enforcement saat grup mencapai kuota CPU, sedangkan throttled_usec menjumlahkan waktu saat grup dibekukan. Nilai nr_throttled yang meningkat berarti proses Anda siap dijalankan tetapi tidak sedang berjalan. Pengalamannya sama seperti steal, tetapi penyebabnya adalah batas yang Anda tetapkan sendiri. Periksa batas Anda sendiri sebelum menyalahkan host, terutama jika Anda menjalankan service di Docker pada VPS dengan batas CPU di file compose. Virtualisasi berlapis menambah satu tempat lagi untuk hilangnya waktu, karena VM di dalam VPS Anda menanggung steal milik VPS serta penundaan penjadwalannya sendiri. Ingat hal ini jika Anda menjalankan virtualisasi bertingkat pada VPS.

Yang harus dilakukan terhadap steal yang berlangsung terus-menerus

Tidak ada pengaturan di dalam guest yang dapat memperbaiki steal, karena scheduler yang mengambil keputusan berjalan di luar guest. Ada empat tindakan yang benar-benar dapat dilakukan.

Kumpulkan bukti terlebih dahulu. Catat timestamp dalam UTC, durasi setiap kejadian, frekuensi pengulangannya, dan apakah mpstat menunjukkan hanya satu vCPU yang terdampak atau semuanya. Sampel yang dicatat selama seminggu lebih berguna daripada tangkapan layar.

Buat tiket dengan data tersebut. Ajukan dua pertanyaan langsung: apakah node ini mengalami oversubscription pada rentang waktu tersebut, dan apakah instance saya dapat dipindahkan. Sertakan output vmstat dan waktu yang tepat. Provider dapat menindaklanjuti rentang waktu yang dapat direproduksi, sedangkan tiket yang hanya menyatakan bahwa server lambat akan dibalas dengan permintaan untuk memberikan rentang waktu tersebut. Seberapa banyak pekerjaan ini dapat Anda serahkan kepada provider merupakan salah satu perbedaan praktis antara VPS terkelola dan tidak terkelola.

Minta migrasi. Memindahkan guest ke node yang bebannya lebih rendah merupakan pekerjaan rutin bagi provider dan biasanya hanya memerlukan reboot singkat. Ini adalah perbaikan tanpa biaya, serta menyelesaikan kasus umum ketika satu node kebetulan menampung beberapa neighbor yang berat pada saat yang sama.

Hilangkan contention dengan membeli paket yang sesuai. Paket vCPU khusus menyediakan core fisik yang dicadangkan untuk instance Anda, sehingga counter berada pada angka nol dan tetap demikian. Biayanya lebih tinggi setiap bulan, dan ini merupakan pilihan yang tepat untuk workload yang tidak dapat menoleransi variasi performa. Jika itu masih belum cukup, atau Anda juga ingin menggunakan memory bandwidth secara eksklusif, langkah berikutnya adalah menggunakan dedicated server, bukan VPS.

Sambil menunggu salah satu tindakan tersebut, kurangi dampak steal. Jalankan worker thread lebih sedikit daripada jumlah vCPU yang tersedia, karena thread yang tidak memperoleh core hanya menambah context switch. Pindahkan pekerjaan batch ke jam ketika node sedang sepi, berdasarkan informasi dari log Anda. Kemudian lakukan pengukuran ulang dengan command yang sama pada jam yang sama, sehingga Anda dapat memastikan apakah perubahan tersebut berhasil, bukan sekadar menebak.

FAQ

Berapa waktu steal CPU yang normal pada VPS?

Pada paket shared, lonjakan singkat dan nilai stabil di bawah sekitar 5 persen masih wajar karena CPU shared berarti host membagi core fisik di antara guest. Nilai dua digit yang bertahan selama berjam-jam tidak wajar dan layak dilaporkan melalui ticket. Pada paket vCPU dedicated, nilai yang diharapkan adalah 0.0. Nilai lain pada paket tersebut merupakan gangguan yang perlu dilaporkan. Nilai ini harus dinilai berdasarkan beban kerja Anda sendiri: tugas batch semalaman dapat menyerap steal yang tidak dapat ditoleransi oleh API yang sensitif terhadap latensi.

Apakah paket yang lebih besar akan memperbaiki waktu steal yang tinggi?

Tidak dengan sendirinya. Penambahan vCPU pada node shared yang sama berarti lebih banyak CPU virtual bersaing untuk core fisik yang sama-sama terbebani, sehingga persentasenya dapat tetap sama persis. Steal hanya dapat dihilangkan dengan alokasi CPU dedicated atau pemindahan ke node yang bebannya lebih rendah. Porsi yang lebih besar dari mesin yang sibuk tetap merupakan porsi dari mesin yang sibuk.

Mengapa VPS saya menunjukkan waktu steal 0 padahal jelas lambat?

Ada dua alasan umum. Hypervisor mungkin sama sekali tidak mengekspor counter tersebut. Kondisi ini umum pada platform VMware dan Hyper-V, sehingga nilainya tetap nol terlepas dari kondisi host. Jalankan systemd-detect-virt untuk melihat platform yang Anda gunakan. Jika bukan itu penyebabnya, bottleneck berada di tempat lain: periksa wa untuk melihat waktu tunggu storage, bandingkan r dengan nproc untuk memeriksa beban berlebih pada sistem Anda, dan baca /sys/fs/cgroup/cpu.stat di dalam container untuk memeriksa throttling kuota.

Bisakah saya mengurangi waktu steal dari dalam server?

Anda tidak dapat mengubah penjadwalan host dari dalam guest. Anda hanya dapat mengurangi dampaknya. Jalankan thread worker lebih sedikit daripada jumlah vCPU yang tersedia agar lebih sedikit pekerjaan mengantre di run queue untuk menunggu core yang belum tersedia. Pindahkan tugas batch ke jam ketika beban node lebih rendah. Cache hasil agar lebih sedikit request yang memerlukan CPU. Perubahan yang benar-benar menghilangkan steal, yaitu migrasi ke node lain atau penggunaan core dedicated, harus dilakukan oleh provider.