CPU Steal Time VPS dan Tetangga yang Bising

Hal yang sebenarnya diukur oleh CPU steal time

CPU steal time adalah persentase waktu ketika CPU virtual Anda siap dijalankan dan tidak menunggu apa pun, tetapi hypervisor memberikan core fisik kepada guest lain. Pekerjaan tersebut masuk ke antrean. Core sedang digunakan di tempat lain. Linux menghitung siklus tersebut secara terpisah dan melaporkannya sebagai st. Dengan demikian, Anda dapat membedakan "server saya sibuk" dari "server saya sedang menunggu giliran".

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

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

Sumber angka steal

Kernel Anda tidak dapat mengukur steal sendiri karena kernel tidak dapat melihat host. Hypervisor yang menyediakannya. Pada KVM, host menulis penghitung per-vCPU ke dalam halaman yang digunakan bersama guest, lalu guest menjumlahkannya ketika kernel dibangun dengan CONFIG_PARAVIRT_TIME_ACCOUNTING, yang digunakan oleh setiap kernel distribusi. Xen melaporkan hal yang sama melalui area runstate-nya. Nilai total sampai ke userspace tepat di satu tempat:

head -1 /proc/stat

Baris cpu tersebut memuat sepuluh penghitung, dalam satuan 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 tool di bawah ini, vmstat, top, mpstat, dan exporter Prometheus, membaca field yang sama lalu mengubah dua sampel menjadi persentase.

Satu konsekuensi lebih penting daripada yang lain. Jika hypervisor tidak pernah mengekspor penghitung tersebut, field akan tetap bernilai nol selamanya, dan setiap tool yang menggunakannya akan melaporkan 0.0 yang tenang meskipun host sedang kelebihan beban. KVM dan Xen mengekspornya. Guest pada VMware dan Hyper-V umumnya melaporkan nilai nol terus-menerus. Periksa platform sebelum mempercayai nilai nol:

systemd-detect-virt

Perintah tersebut mencetak nama platform, misalnya kvm, xen, vmware, atau microsoft, serta none pada bare metal. Di dalam container, perintah tersebut justru melaporkan runtime, misalnya lxc, docker, atau podman. Informasi itu menjelaskan container, bukan mesin yang mendasarinya. 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 eksekusi 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 ada 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 pada 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 kolom terakhir. Baca kolom berdasarkan nama header-nya, karena posisinya berubah antarrilis.

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

top melaporkan angka yang sama pada baris ringkas %Cpu(s), di 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 detail per core, tambahkan sysstat:

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

mpstat mencetak satu baris untuk setiap CPU dengan kolom %steal. Kolom ini menunjukkan apakah semua vCPU terdampak atau hanya satu. Untuk 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 begitu, file tersebut dapat membedakan antara sekadar memberi tahu provider bahwa "tadi malam terasa lambat" dan menunjukkan sepuluh menit yang tepat.

Apa arti angka steal?

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

Gunakan rentang tersebut sebagai panduan pembacaan, bukan sebagai spesifikasi, karena tidak ada provider yang memublikasikan jaminan steal pada shared plan. Nilai tersebut harus dibandingkan dengan beban kerja yang Anda jalankan. Batch job yang berjalan semalaman dapat menoleransi steal sebesar 15 persen tanpa terlihat oleh siapa pun. Service yang sensitif terhadap latensi akan menunjukkan dampaknya pada p99 jauh sebelum rata-rata terlihat mengkhawatirkan. Karena itu, beban kerja yang sensitif terhadap latensi seperti bot trading sebaiknya dijalankan pada core khusus.

Berapa biaya steal time bagi Anda?

Perhitungannya singkat. Jika sebagian s dari waktu CPU Anda diambil, pekerjaan yang memerlukan jumlah CPU tetap akan memerlukan waktu 1 / (1 - s) kali lebih lama pada jam dinding. Untuk pekerjaan 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 pembacaan umum pada paket shared, pekerjaan tersebut memerlukan 61.9 detik, bukan 60.0 detik. Tidak ada yang biasanya membuat tiket untuk selisih itu. Pada 8 persen, waktunya menjadi 65.2 detik. Pada 40 persen, pekerjaan yang sama memerlukan 100.0 detik, dan antrean yang sebelumnya dapat dikosongkan mulai bertambah panjang.

Itu adalah nilai hasil perhitungan, bukan hasil pengukuran. Model ini mengasumsikan satu thread yang dapat dijalankan dan steal time tersebar merata sepanjang interval. Layanan nyata sering terasa lebih lambat daripada kurva tersebut, karena bagian waktu yang diambil dapat terjadi di tengah pemrosesan sebuah request, lalu penundaan itu kembali dirasakan oleh semua proses yang menunggu request tersebut. Untuk memperoleh angka Anda sendiri, bukan sekadar formula, lakukan benchmark pada VPS selama jam yang tenang dan sekali lagi selama jam sibuk, lalu catat st untuk kedua periode tersebut.

Apakah ini steal, atau ada penyebab lain?

Steal mudah tertukar dengan gejala lain. Baca semua counter secara bersamaan pada baris vmstat yang sama.

• st tinggi sementara 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 kapasitas CPU sendiri. Bandingkan r dengan output nproc. Ini adalah oversubscription dari sisi Anda sendiri, bukan dari neighbour.
• wa tinggi dengan st mendekati nol: task terblokir pada storage. Ini masalah yang berbeda dan memerlukan perbaikan yang berbeda.
• Load average tinggi sementara 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.

Plan burstable memerlukan penjelasan tersendiri. Plan ini memberikan saldo kredit yang bertambah saat Anda idle dan berkurang saat Anda sibuk. Setelah saldo habis, provider membatasi Anda pada laju baseline. Pada sebagian platform, throttle tersebut dilaporkan sebagai steal. Pada platform lain, kondisi ini tidak terlihat dari dalam instance, dan Anda hanya mendapatkan lebih sedikit cycle per detik. Baca deskripsi plan sebelum menyimpulkan bahwa neighbour adalah penyebabnya.

Mengapa container melaporkan steal time nol

Steal merupakan properti virtual machine, bukan container yang berjalan di dalamnya. Container Docker pada VPS milik Anda sendiri berbagi /proc milik host, sehingga nilai st yang dibaca di dalamnya adalah steal VPS. Nilai tersebut memang yang Anda perlukan. Virtualisasi berbasis container yang dijual sebagai VPS berperilaku berbeda. Jika lxcfs digunakan, /proc/stat di dalam container dibuat berdasarkan akuntansi cgroup, dan steal selalu bernilai nol. Stack monitoring yang hanya mengambil metrik dari dalam container dapat menampilkan angka nol yang tetap dan seolah-olah normal, sementara mesin fisik di bawahnya kekurangan CPU.

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

cat /sys/fs/cgroup/cpu.stat

nr_throttled menghitung periode enforcement ketika grup mencapai kuota CPU-nya, sedangkan throttled_usec menjumlahkan waktu ketika grup tersebut 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 terlebih dahulu sebelum menyalahkan host, terutama jika Anda menjalankan service di Docker pada VPS dengan batas CPU di file compose. Virtualisasi berlapis menambah satu tempat lain untuk hilangnya waktu CPU, karena VM di dalam VPS menanggung steal VPS Anda ditambah penundaan penjadwalannya sendiri. Ingat hal ini jika Anda menjalankan virtualisasi bertingkat pada VPS.

Apa 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. Memutakhirkan kernel juga tidak mengubah hal itu: cache aware scheduling yang ditambahkan pada Linux kernel 7.2 mengatur ulang task Anda pada core yang benar-benar Anda dapatkan, tetapi tidak dapat mengembalikan siklus CPU yang sudah diambil oleh guest lain. Ada empat langkah yang dapat dilakukan.

Kumpulkan bukti terlebih dahulu. Catat timestamp dalam UTC, durasi setiap episode, frekuensi pengulangannya, dan apakah mpstat menunjukkan satu vCPU atau seluruh vCPU terdampak. Sampel yang dicatat selama satu minggu lebih berguna daripada sebuah screenshot.

Buka ticket dengan data tersebut. Ajukan dua pertanyaan langsung: apakah node mengalami oversubscription selama periode tersebut, dan apakah instance saya dapat dipindahkan. Sertakan output vmstat dan waktu yang tepat. Provider dapat menindaklanjuti periode yang dapat direproduksi, sedangkan ticket yang hanya menyatakan bahwa server lambat akan mendapat balasan yang meminta informasi tersebut. Seberapa banyak pekerjaan ini dapat Anda serahkan kepada provider merupakan salah satu perbedaan praktis antara VPS terkelola dan VPS 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, dan menyelesaikan kasus umum ketika satu node kebetulan menampung beberapa guest lain yang menggunakan banyak resource pada waktu yang sama.

Gunakan paket dengan vCPU dedicated. Paket vCPU dedicated mencadangkan core fisik untuk instance Anda, sehingga counter tetap bernilai nol. Biayanya lebih tinggi setiap bulan, tetapi ini adalah pilihan yang tepat untuk workload yang tidak dapat menoleransi variasi tersebut. Jika itu masih belum cukup, atau Anda juga ingin menggunakan memory bandwidth secara eksklusif, langkah berikutnya adalah server dedicated, bukan VPS.

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

FAQ

Berapa waktu steal CPU yang normal pada VPS?

Pada paket shared, lonjakan singkat dan nilai yang terus berada di bawah sekitar 5 persen masih umum karena CPU shared berarti host membagi core fisik di antara guest. Nilai dua digit yang bertahan selama berjam-jam tidak normal dan perlu dilaporkan melalui tiket. Pada paket vCPU dedicated, nilai yang diharapkan adalah 0.0. Jika nilainya berbeda, laporkan sebagai gangguan. Nilai tersebut harus dinilai berdasarkan beban kerja Anda sendiri: tugas batch semalaman dapat menyerap waktu 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. vCPU yang lebih banyak pada node shared yang sama berarti lebih banyak CPU virtual yang bersaing untuk mendapatkan core fisik yang sama-sama terbebani, sehingga persentasenya dapat tetap sama. Waktu steal berkurang jika Anda mendapatkan alokasi CPU dedicated atau dipindahkan 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 tidak mengekspor penghitung tersebut. Hal ini umum pada platform VMware dan Hyper-V, sehingga nilainya tetap 0 terlepas dari kondisi host. Jalankan systemd-detect-virt untuk mengetahui platform yang digunakan. Jika bukan itu penyebabnya, bottleneck berada di tempat lain: periksa wa untuk melihat waktu tunggu storage, bandingkan r dengan nproc untuk memeriksa overload pada sistem Anda, dan baca /sys/fs/cgroup/cpu.stat di dalam container untuk mendeteksi throttling akibat quota.

Apakah saya dapat 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 menunggu di run queue untuk mendapatkan 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 waktu steal, yaitu migrasi ke node lain atau penggunaan core dedicated, harus dilakukan oleh provider.