Apa itu CPU steal time pada VPS dan cara mengesannya

Apa yang sebenarnya diukur oleh CPU steal time

CPU steal time ialah bahagian masa vCPU anda sedia untuk berjalan, tanpa perlu menunggu apa-apa, sementara hypervisor memberikan teras fizikal kepada tetamu lain. Kerja tersebut telah diletakkan dalam baris gilir. Teras tersebut berada di tempat lain. Linux mengira kitaran tersebut secara berasingan dan melaporkannya sebagai st, iaitu cara anda membezakan antara "pelayan saya sibuk" dengan "pelayan saya sedang menunggu giliran".

Perbezaan itulah sebab utama pembilang ini wujud. Masa yang digunakan oleh proses anda sendiri pada CPU dilaporkan sebagai us (user) atau sy (system). Masa yang digunakan oleh tugasan yang disekat pada storan dilaporkan sebagai wa (I/O wait). vCPU (virtual CPU) yang boleh dijalankan, berada dalam run queue, tanpa I/O yang tertunggak, namun masih tidak melaksanakan arahan, dilaporkan sebagai st. Tiada apa-apa di dalam pelayan anda yang boleh membersihkan status tersebut, kerana keputusan penjadualan dibuat satu lapisan di bawah anda, pada hos.

Ini berpunca secara langsung daripada bagaimana VPS berkongsi satu mesin fizikal antara banyak tetamu. Punca biasa ialah jiran: tetamu lain pada nod yang sama sedang berjalan dengan beban tinggi, jadi hos membahagikan teras antara anda. Terdapat punca kedua yang sering terlepas pandang. Banyak penyedia mengehadkan vCPU kongsi pada sebahagian kecil daripada teras fizikal, dan pada beberapa hypervisor, had yang dikuatkuasakan itu dikira sebagai steal di dalam tetamu. Jadi, bacaan st yang tinggi memberitahu anda bahawa teras tersebut tidak diberikan kepada anda. Ia tidak selalunya memberitahu anda siapa yang mengambilnya.

Dari mana datangnya nilai steal

Kernel anda tidak boleh mengukur steal secara sendirian kerana ia tidak dapat melihat hos. Hypervisor yang memberitahunya. Pada KVM, hos menulis pembilang per-vCPU ke dalam halaman yang dikongsi dengan guest, dan guest menjumlahkannya apabila kernel dibina dengan CONFIG_PARAVIRT_TIME_ACCOUNTING, iaitu tetapan bagi setiap kernel pengedaran. Xen melaporkan perkara yang sama melalui kawasan runstate-nya. Jumlah tersebut sampai ke ruang pengguna (userspace) di satu tempat sahaja:

head -1 /proc/stat

Baris cpu itu membawa sepuluh pembilang, dalam tick USER_HZ sejak but, mengikut urutan ini: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal ialah nilai kelapan selepas label. Setiap alat di bawah, vmstat, top, mpstat dan mana-mana Prometheus exporter, membaca medan yang sama itu dan menukarkan dua sampel kepada peratusan.

Satu akibat adalah lebih penting daripada yang lain. Jika hypervisor tidak pernah mengeksport pembilang tersebut, medan itu kekal pada sifar selama-lamanya, dan setiap alat yang dibina di atasnya melaporkan 0.0 yang tenang walaupun hos sedang terlebih beban. KVM dan Xen mengeksportnya. Guest pada VMware dan Hyper-V biasanya melaporkan sifar mutlak. Semak platform sebelum anda mempercayai nilai sifar:

systemd-detect-virt

Ia mencetak nama platform, seperti kvm, xen, vmware atau microsoft, dan none pada bare metal. Di dalam container, ia melaporkan runtime sebaliknya, seperti lxc, docker atau podman, yang memberitahu anda tentang container tersebut dan bukan tentang mesin di bawahnya. Pada kvm, nilai sifar adalah bukti sebenar bahawa hos melayan anda dengan baik. Pada platform yang tidak pernah mengisi medan tersebut, nilai sifar bukanlah sebarang bukti, dan pertikaian sumber (contention) perlu dinilai dengan mengukur masa kerja sebenar.

Bagaimanakah cara menyemak CPU steal time pada VPS?

vmstat datang daripada pakej procps. Ia tersedia pada hampir setiap imej VPS Ubuntu dan Debian, namun tiada pada beberapa imej kontena minimal, jadi pasang ia sebelum anda bergantung kepadanya.

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 ia mencetak output tersebut, alat ini telah dipasang dan anda sedang membaca pembilang kernel yang sebenar. vmstat 1 5 kemudian mengambil satu sampel sesaat, 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 lajur st dalam blok cpu di sebelah kanan. Binaan procps-ng semasa mencetak lajur gu selepasnya untuk masa tetamu KVM, jadi st berada di kedudukan kedua dari kanan dan bukannya yang terakhir. Baca lajur berdasarkan nama pengepala, kerana kedudukannya telah berubah antara keluaran.

Dua tabiat memastikan bacaan anda tepat. Baris data pertama adalah purata sejak but, jadi abaikan baris tersebut dan baca baris-baris selepasnya. Selain itu, satu sampel bukanlah satu ukuran, kerana steal time berlaku secara berkala: jalankan vmstat 1 60 dan perhatikan selama seminit penuh sebelum anda membuat kesimpulan.

top melaporkan nombor yang sama pada baris ringkasan %Cpu(s), dalam medan yang ditandakan 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 perincian setiap teras (per-core), tambahkan sysstat:

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

mpstat mencetak satu baris bagi setiap CPU dengan lajur %steal, yang menunjukkan sama ada setiap vCPU terjejas atau hanya satu sahaja. Untuk sejarah yang diperlukan oleh tiket sokongan, simpan sampel tersebut daripada hanya membacanya pada skrin:

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

Jalankan arahan tersebut melalui cron sepanjang jam yang anda syaki, dan fail tersebut akan menjadi perbezaan antara memberitahu penyedia "ia terasa perlahan malam tadi" dengan menunjukkan kepada mereka tempoh sepuluh minit yang tepat.

Apakah maksud angka steal?

• 0.0 yang stabil. Sihat, atau platform tidak melaporkan steal sama sekali. Sahkan dengan systemd-detect-virt sebelum anda berpuas hati.
• Lonjakan beberapa peratus yang berlangsung selama beberapa saat. Normal pada mana-mana nod kongsi. Binaan jiran bermula, atau hos menjalankan sandarannya.
• 1 hingga 5 peratus yang berterusan pada pelan kongsi. Dijangka. CPU kongsi adalah apa yang dicerminkan oleh harga tersebut.
• 5 hingga 10 peratus yang berterusan. Kelembapan yang boleh anda ukur. Mula merekodkan bukti, dan bandingkan waktu yang sama merentasi beberapa hari.
• Melebihi 10 peratus untuk tempoh berjam-jam. Nod tersebut terlebih langgan (oversubscribed) untuk beban kerja anda. Ini adalah tahap yang mewajarkan tiket sokongan atau perpindahan.

Anggap jalur tersebut sebagai panduan bacaan dan bukannya spesifikasi, kerana tiada penyedia menerbitkan jaminan steal pada pelan kongsi. Timbangkan ia dengan apa yang anda jalankan. Kerja kelompok (batch job) semalaman boleh menyerap 15 peratus steal dan tiada siapa yang perasan. Servis yang sensitif terhadap latensi akan menunjukkannya dalam p99 jauh sebelum purata kelihatan membimbangkan, itulah sebabnya beban kerja sensitif latensi seperti bot dagangan perlu menggunakan teras berdedikasi.

Berapakah kos steal time kepada anda?

Pengiraannya ringkas. Jika pecahan s daripada masa CPU anda diambil, tugasan yang memerlukan jumlah CPU tetap akan mengambil masa 1 / (1 - s) kali ganda lebih lama pada jam dinding. Bagi tugasan yang memerlukan 60 saat masa 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 peratus, bacaan biasa bagi pelan kongsi, tugasan tersebut mengambil masa 61.9 saat berbanding 60.0. Tiada siapa yang akan membuka tiket aduan untuk perkara itu. Pada 8 peratus, ia menjadi 65.2 saat. Pada 40 peratus, tugasan yang sama memerlukan 100.0 saat, dan baris gilir yang dahulunya kosong mula bertambah.

Ini adalah nilai yang dikira, bukan ukuran. Model ini mengandaikan satu thread yang boleh dijalankan dan steal yang tersebar secara sekata sepanjang selang masa. Servis sebenar sering terasa lebih perlahan daripada lengkung tersebut, kerana potongan masa yang dicuri berlaku di tengah-tengah permintaan dan kelewatan tersebut kemudiannya ditanggung semula oleh semua proses yang menunggu permintaan itu. Untuk mendapatkan angka anda sendiri dan bukannya formula, lakukan penanda aras pada VPS semasa waktu tenang dan sekali lagi semasa waktu sibuk, dengan merekodkan st untuk kedua-dua tempoh tersebut.

Adakah ia steal, atau sesuatu yang lain?

Steal mudah dikelirukan dengan simptom lain. Baca kaunter-kaunter tersebut bersama-sama, pada baris vmstat yang sama.

• st tinggi sementara r dan us kekal rendah: hos tidak memberikan teras kepada anda. Itu adalah steal.
• r jauh melebihi kiraan vCPU anda, dengan us tinggi dan st hampir sifar: anda menjalankan lebih banyak kerja daripada yang mampu ditampung oleh CPU anda sendiri. Bandingkan r dengan output nproc. Ini adalah oversubscription anda sendiri, bukan jiran.
• wa tinggi dengan st hampir sifar: tugas disekat pada storan, yang merupakan masalah berbeza dengan penyelesaian berbeza.
• Load average tinggi sementara st dan us kedua-duanya rendah: angka beban juga mengira tugas yang tidak boleh diganggu (uninterruptible), jadi ini biasanya menunjukkan peranti yang tersangkut atau network mount yang tergantung dan bukannya masalah CPU.

Pelan boleh lonjak (burstable) memerlukan nota tersendiri. Ia memberikan anda baki kredit yang terkumpul semasa anda melahu dan berkurang semasa anda sibuk, dan apabila ia habis, penyedia akan mengehadkan anda pada kadar asas. Pada sesetengah platform, pendikit (throttle) tersebut dilaporkan sebagai steal. Pada platform lain, ia tidak kelihatan dari dalam, dan anda hanya mendapat lebih sedikit kitaran sesaat. Baca perihalan pelan sebelum membuat keputusan bahawa jiran adalah puncanya.

Mengapa kontena melaporkan sifar steal time

Steal ialah sifat bagi mesin maya, bukan kontena yang berjalan di dalamnya. Kontena Docker pada VPS anda berkongsi /proc hos, jadi nilai st yang dibaca di dalamnya adalah steal bagi VPS tersebut, iaitu nilai yang anda perlukan. Virtualisasi berasaskan kontena yang dijual sebagai VPS berkelakuan berbeza. Dengan lxcfs digunakan, /proc/stat di dalam kontena disintesis daripada perakaunan cgroup, dan nilai steal adalah sifar secara binaan. Stak pemantauan yang hanya mengumpul data dari dalam boleh menunjukkan nilai sifar yang mendatar dan tenang, sedangkan mesin fizikal di bawahnya sedang mengalami kekurangan sumber.

Di dalam kontena, pembilang yang membawa maksud yang sama ialah CPU quota throttling. Pada cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled mengira tempoh penguatkuasaan di mana kumpulan tersebut mencapai kuota CPU, dan throttled_usec menjumlahkan masa yang dihabiskan dalam keadaan beku. Nilai nr_throttled yang meningkat bermakna proses anda boleh dijalankan tetapi tidak berjalan; ini pengalaman yang sama seperti steal, tetapi disebabkan oleh had yang anda tetapkan sendiri. Semak had anda sebelum menyalahkan hos, terutamanya jika anda menjalankan servis dalam Docker pada VPS dengan had CPU dalam fail compose. Virtualisasi berlapis menambah satu lagi tempat di mana masa boleh hilang, kerana VM di dalam VPS anda menanggung steal anda ditambah dengan kelewatan penjadualan miliknya sendiri. Ingat perkara ini jika anda menjalankan virtualisasi bersarang pada VPS.

Tindakan terhadap steal yang berterusan

Tiada tetapan di dalam guest yang boleh membaiki steal, kerana penjadual yang membuat keputusan tersebut berjalan di luar guest. Menaik taraf kernel juga tidak mengubah keadaan ini: penjadualan peka cache yang ditambah dalam Linux kernel 7.2 menyusun semula tugas anda merentas teras yang diberikan kepada anda, dan tidak dapat memulihkan kitaran yang telah diambil oleh jiran. Terdapat empat langkah yang nyata.

Kumpul bukti dahulu. Rekodkan cap masa dalam UTC, tempoh setiap episod, kekerapan ia berulang, dan sama ada mpstat menunjukkan satu vCPU terjejas atau kesemuanya. Sampel log selama seminggu adalah lebih bernilai daripada sekadar tangkapan skrin.

Buka tiket dengan data tersebut. Ajukan dua soalan terus: adakah nod ini terlebih langgan (oversubscribed) semasa tempoh ini, dan bolehkah instance saya dipindahkan. Tampal output vmstat dan waktu yang tepat. Penyedia akan bertindak berdasarkan tempoh yang boleh dihasilkan semula, dan tiket yang hanya menyatakan pelayan perlahan akan mendapat balasan yang meminta maklumat tersebut. Sejauh mana kerja ini boleh diserahkan adalah salah satu perbezaan praktikal antara VPS terurus dan tidak terurus.

Minta migrasi. Memindahkan guest ke nod yang kurang beban adalah kerja rutin bagi penyedia, dan ia biasanya hanya memerlukan reboot yang singkat. Ini adalah penyelesaian yang tidak menelan kos, dan ia menyelesaikan kes biasa di mana satu nod kebetulan menempatkan beberapa jiran yang berat pada masa yang sama.

Atasi contention dengan pembelian. Pelan vCPU khusus (dedicated) menempah teras fizikal untuk instance anda, jadi pembilang akan berada pada sifar dan kekal di situ. Ia menelan kos lebih tinggi setiap bulan, dan ia merupakan jawapan yang jujur untuk beban kerja yang tidak dapat menampung varians. Jika itu masih tidak mencukupi, atau anda mahukan lebar jalur memori untuk diri sendiri juga, langkah seterusnya ialah pelayan khusus (dedicated server) dan bukannya VPS.

Sementara menunggu tindakan tersebut, kurangkan kesan buruk steal. Jalankan thread pekerja yang lebih sedikit daripada jumlah vCPU yang anda miliki, kerana thread yang tidak mendapat teras hanya akan menambah penukaran konteks (context switches). Pindahkan kerja kelompok (batch work) ke waktu apabila nod tidak sibuk, yang kini diketahui melalui log anda sendiri. Kemudian, ukur semula dengan arahan yang sama pada waktu yang sama, supaya anda boleh menyatakan sama ada perubahan tersebut berkesan dan bukannya meneka.

FAQ

Berapakah nilai CPU steal time yang normal pada VPS?

Pada pelan kongsi, lonjakan singkat dan nilai berterusan di bawah kira-kira 5 peratus adalah perkara biasa, kerana CPU kongsi bermakna hos membahagikan teras fizikal antara tetamu. Nilai dua angka yang berterusan selama berjam-jam adalah tidak normal dan wajar dilaporkan melalui tiket sokongan. Pada pelan vCPU khusus, bacaan yang dijangkakan ialah 0.0, jadi sebarang nilai lain di situ merupakan satu kerosakan yang perlu dilaporkan. Nilai ini perlu dinilai berdasarkan beban kerja anda sendiri: tugasan kelompok (batch job) waktu malam boleh menyerap steal yang tidak dapat ditanggung oleh API yang sensitif terhadap latensi.

Adakah pelan yang lebih besar akan menyelesaikan masalah steal time yang tinggi?

Tidak secara sendirinya. Lebih banyak vCPU pada nod kongsi yang sama bermakna lebih banyak CPU maya bersaing untuk teras fizikal yang sama, dan peratusannya mungkin kekal sama. Perkara yang menghilangkan steal ialah peruntukan CPU khusus, atau berpindah ke nod yang kurang beban. Bahagian yang lebih besar pada mesin yang sibuk tetap merupakan bahagian pada mesin yang sibuk.

Mengapa VPS saya menunjukkan 0 steal time sedangkan ia jelas perlahan?

Terdapat dua sebab biasa. Hypervisor mungkin tidak mengeksport pembilang tersebut sama sekali, yang merupakan perkara biasa pada platform VMware dan Hyper-V, jadi medan tersebut kekal pada sifar walau apa pun yang dilakukan oleh hos. Jalankan systemd-detect-virt untuk melihat platform yang anda gunakan. Jika tidak, kesesakan berlaku di tempat lain: semak wa untuk masa menunggu storan, bandingkan r dengan nproc untuk beban lampau anda sendiri, dan baca /sys/fs/cgroup/cpu.stat di dalam kontena untuk pengehadan kuota (quota throttling).

Bolehkah saya mengurangkan steal time dari dalam pelayan saya?

Anda tidak boleh mengubah penjadualan hos dari dalam tetamu. Anda hanya boleh mengurangkan kesannya. Jalankan bilangan worker thread yang lebih sedikit daripada vCPU yang anda miliki, supaya kurang kerja yang tertangguh dalam baris gilir menunggu teras yang tidak tersedia. Pindahkan tugasan kelompok ke waktu apabila nod lebih lengang. Lakukan caching pada hasil supaya kurang permintaan yang memerlukan CPU. Perubahan yang benar-benar menghilangkan steal, seperti migrasi ke nod lain atau penggunaan teras khusus, terletak di bawah bidang kuasa penyedia perkhidmatan.