Cara Semak CPU Steal Time VPS dan Masalah Noisy Neighbour

Apa yang sebenarnya diukur oleh CPU steal time

CPU steal time ialah bahagian masa vCPU anda yang sedia untuk dijalankan, 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, yang merupakan cara untuk 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 (pengguna) atau sy (sistem). Masa yang dihabiskan oleh tugasan semasa disekat pada storan dilaporkan sebagai wa (I/O wait). vCPU (virtual CPU) yang boleh dijalankan, berada dalam baris gilir jalankan, tanpa I/O yang belum selesai, namun masih tidak melaksanakan tugas, dilaporkan sebagai st. Tiada apa-apa di dalam pelayan anda yang boleh membersihkan keadaan 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 pecahan 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 sentiasa memberitahu anda siapa yang mengambilnya.

Dari mana datangnya angka steal

Kernel anda tidak boleh mengukur steal dengan sendirinya, kerana ia tidak dapat melihat host. Hypervisor yang memberitahunya. Pada KVM, host menulis pembilang per-vCPU ke dalam halaman yang dikongsi dengan guest, dan guest menjumlahkannya apabila kernel dibina dengan CONFIG_PARAVIRT_TIME_ACCOUNTING, yang terdapat pada setiap kernel pengedaran. Xen melaporkan perkara yang sama melalui kawasan runstate-nya. Jumlah tersebut sampai ke ruang pengguna 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 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 host sedang terlebih beban. KVM dan Xen mengeksportnya. Guest pada VMware dan Hyper-V biasanya melaporkan sifar rata. Periksa 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 host melayan anda dengan baik. Pada platform yang tidak pernah mengisi medan tersebut, nilai sifar bukanlah bukti langsung, dan contention perlu dinilai dengan mengukur kerja sebenar sebagai gantinya.

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 sesetengah 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 kaunter kernel 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 ukuran yang mencukupi kerana steal time berlaku secara berperingkat: jalankan vmstat 1 60 dan perhatikan selama seminit penuh sebelum membuat kesimpulan.

top melaporkan nombor yang sama pada baris ringkasan %Cpu(s), dalam medan yang ditandakan sebagai 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 bertahan selama beberapa saat. Normal pada mana-mana nod kongsi. Proses binaan jiran bermula, atau hos menjalankan sandaran datanya.
• 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 yang menerbitkan jaminan steal pada pelan kongsi. Timbangkan angka tersebut dengan apa yang anda jalankan. Kerja kelompok (batch job) waktu malam boleh menyerap 15 peratus steal tanpa disedari sesiapa. Servis yang sensitif terhadap latensi akan menunjukkannya pada p99 jauh sebelum puratanya kelihatan membimbangkan, itulah sebabnya beban kerja sensitif latensi seperti bot dagangan perlu menggunakan teras berdedikasi.

Berapakah kos steal time anda?

Pengiraannya ringkas. Jika pecahan s 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 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 biasanya kosong mula bertambah.

Ini adalah nilai yang dikira, bukan ukuran. Model ini mengandaikan satu thread yang boleh dijalankan dan steal tersebar secara sekata sepanjang selang masa tersebut. Servis sebenar sering terasa lebih perlahan daripada lengkung ini, kerana slice yang dicuri berlaku di tengah-tengah permintaan dan kelewatan tersebut kemudiannya ditanggung semula oleh semua 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 ini steal, atau sesuatu yang lain?

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

• st tinggi manakala 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 manakala 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 burstable memerlukan nota tersendiri. Ia memberikan anda baki kredit yang terkumpul semasa anda melahu dan berkurangan semasa anda sibuk, dan apabila ia habis, penyedia akan mengehadkan anda pada kadar asas. Pada sesetengah platform, pendikitan (throttle) itu dilaporkan sebagai steal. Pada platform lain, ia tidak kelihatan dari dalam, dan anda hanya mendapat lebih sedikit kitaran sesaat. Baca perihalan pelan sebelum membuat kesimpulan bahawa jiran adalah puncanya.

Mengapa kontena melaporkan sifar steal time

Steal ialah sifat bagi mesin maya, bukan bagi kontena yang berjalan di dalamnya. Kontena Docker pada VPS anda berkongsi /proc hos, jadi nilai st yang dibaca di dalamnya ialah steal milik VPS tersebut, iaitu nilai yang anda perlukan. Virtualisasi berasaskan kontena yang dijual sebagai VPS berkelakuan berbeza. Dengan lxcfs diaktifkan, /proc/stat di dalam kontena disintesis daripada perakaunan cgroup, dan nilai steal adalah sifar secara reka bentuk. Stak pemantauan yang hanya mengumpul data dari dalam kontena boleh menunjukkan nilai sifar yang rata dan stabil, sedangkan mesin fizikal di bawahnya sebenarnya 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 sedang berjalan; ini adalah 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 punca masa hilang, kerana VM di dalam VPS anda menanggung steal milik anda ditambah dengan kelewatan penjadualan miliknya sendiri. Ingat perkara ini jika anda menjalankan virtualisasi bersarang pada VPS.

Apa yang perlu dilakukan mengenai steal yang berterusan

Tiada tetapan di dalam guest yang dapat membaiki steal, kerana penjadual yang membuat keputusan tersebut berjalan di luar guest. Terdapat empat langkah yang nyata.

Kumpul bukti terlebih 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. Tampalkan output vmstat dan waktu yang tepat. Penyedia perkhidmatan 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 kepada pihak lain merupakan salah satu perbezaan praktikal antara VPS terurus dan tidak terurus.

Minta migrasi. Memindahkan guest ke nod yang kurang beban adalah kerja rutin bagi penyedia perkhidmatan, dan ia biasanya hanya melibatkan reboot yang singkat. Ini adalah penyelesaian yang tidak menelan kos, dan ia menyelesaikan kes biasa di mana satu nod secara 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 bagi 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 anda menunggu semua itu, kurangkan kesan buruk steal. Jalankan thread pekerja yang lebih sedikit daripada jumlah vCPU yang anda miliki, kerana thread yang tidak mendapat teras hanya menambah penukaran konteks (context switches). Pindahkan kerja kelompok (batch work) ke waktu apabila nod tidak sibuk, yang kini diberitahu oleh 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 sekadar meneka.

FAQ

Apakah nilai CPU steal time yang normal pada VPS?

Pada pelan kongsi (shared plan), lonjakan singkat dan nilai yang konsisten 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 perlu dilaporkan melalui tiket sokongan. Pada pelan vCPU khusus (dedicated vCPU), 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: kerja kelompok (batch job) waktu malam boleh menyerap steal time 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 time 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 langsung, 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 jumlah vCPU yang anda miliki, supaya kurang kerja yang tertangguh dalam run queue menunggu teras yang tidak tersedia. Pindahkan kerja kelompok ke waktu apabila nod lebih lengang. Lakukan caching pada hasil supaya kurang permintaan yang memerlukan CPU. Perubahan yang benar-benar menghilangkan steal time, iaitu migrasi ke nod lain atau penggunaan teras khusus, terletak di bawah bidang kuasa penyedia perkhidmatan.