CPU steal time nedir ve nasıl yorumlanır?

CPU steal time değerinin gerçekte neyi ölçtüğü

CPU steal time, sanal CPU'nuzun çalışmaya hazır olduğu ve bekleyeceği hiçbir şeyin bulunmadığı ancak hipervizörün fiziksel çekirdeği başka bir konuğa tahsis ettiği sürenin payıdır. İş kuyruğa alınmıştır. Çekirdek başka bir yerdedir. Linux bu döngüleri ayrı olarak sayar ve st olarak raporlar; "sunucum meşgul" ile "sunucum sırasını bekliyor" ayrımını bu şekilde yaparsınız.

Bu fark, sayacın var olma nedenidir. Kendi süreçlerinizin CPU üzerinde harcadığı süre us (kullanıcı) veya sy (sistem) olarak raporlanır. Bir görevin depolama biriminde engellenerek geçirdiği süre wa (I/O wait) olarak raporlanır. Çalıştırılabilir durumda olan, çalışma kuyruğunda bekleyen, bekleyen I/O işlemi olmayan ancak yine de yürütülmeyen bir vCPU (sanal CPU), st olarak raporlanır. Sunucunuzun içindeki hiçbir şey bu durumu düzeltemez, çünkü zamanlama kararı sizin bir katman altınızda, ana makine üzerinde verilir.

Bu durum, doğrudan bir VPS'in tek bir fiziksel makineyi birçok konuk arasında nasıl paylaştığı ile ilgilidir. Yaygın neden bir komşudur: aynı düğümdeki başka bir konuk yoğun çalışıyordur ve ana makine çekirdekleri sizinle paylaştırıyordur. Gözden kaçan ikinci bir neden daha vardır. Birçok sağlayıcı, paylaşımlı bir vCPU'yu fiziksel bir çekirdeğin bir kısmı ile sınırlar ve çeşitli hipervizörlerde bu zorunlu sınır, konuk içinde steal olarak hesaba katılır. Dolayısıyla yüksek bir st değeri, çekirdeğin size verilmediğini gösterir. Ancak bu değer, onu kimin aldığını her zaman söylemez.

Steal değerinin kaynağı

Çekirdeğiniz, ana makineyi (host) göremediği için steal değerini kendi başına ölçemez. Bu değer hipervizör tarafından bildirilir. KVM üzerinde ana makine, her vCPU için bir sayacı konuk (guest) ile paylaşılan bir sayfaya yazar; çekirdek CONFIG_PARAVIRT_TIME_ACCOUNTING ile derlendiğinde konuk bu değeri toplar. Tüm dağıtım çekirdekleri bu şekilde yapılandırılmıştır. Xen, aynı bilgiyi runstate alanı üzerinden raporlar. Toplam değer kullanıcı alanına (userspace) tam olarak tek bir noktadan ulaşır:

head -1 /proc/stat

Bu cpu satırı, önyüklemeden bu yana geçen USER_HZ cinsinden on adet sayaç taşır; bunlar sırasıyla: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice şeklindedir. Steal, etiketten sonraki sekizinci değerdir. Aşağıdaki tüm araçlar, vmstat, top, mpstat ve tüm Prometheus dışa aktarıcıları (exporter), aynı alanı okur ve iki örneklemden bir yüzde değeri hesaplar.

Bu durumun diğerlerinden daha önemli bir sonucu vardır. Hipervizör sayacı dışa aktarmazsa, alan sonsuza kadar sıfır kalır ve bu alanı temel alan tüm araçlar, ana makine aşırı yüklü olsa bile 0.0 değerini raporlar. KVM ve Xen bu değeri dışa aktarır. VMware ve Hyper-V üzerindeki konuklar genellikle sabit sıfır raporlar. Sıfır değerine güvenmeden önce platformu kontrol edin:

systemd-detect-virt

Bu komut, kvm, xen, vmware veya microsoft gibi platform adını, bare metal üzerinde ise none değerini yazdırır. Bir container içinde ise alttaki makineyi değil, lxc, docker veya podman gibi çalışma zamanını (runtime) raporlar. kvm üzerinde görülen bir sıfır, ana makinenin size iyi davrandığının gerçek bir kanıtıdır. Alanı hiçbir zaman doldurmayan bir platformda ise sıfır hiçbir şey ifade etmez; bu durumda çekişme (contention), gerçek iş yüklerinin zamanlaması üzerinden değerlendirilmelidir.

Bir VPS üzerinde CPU steal time değeri nasıl kontrol edilir?

vmstat, procps paketinden gelir. Hemen hemen tüm Ubuntu ve Debian VPS imajlarında bulunur; ancak bazı minimal container imajlarında eksik olabilir, bu nedenle bağımlılık olarak kullanmadan önce yükleyin.

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

vmstat --version, vmstat from procps-ng 4.0.4 gibi bir satır yazdırır. Eğer bu çıktı alınıyorsa araç yüklüdür ve gerçek çekirdek sayaçlarını okuyorsunuz demektir. vmstat 1 5, saniyede bir örnek alarak beş kez çalışır.

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

Sağ taraftaki cpu bloğunda st sütununu bulun. Güncel procps-ng sürümleri, KVM guest süresi için bundan sonra bir gu sütunu yazdırır; bu nedenle st, en son sütun yerine sağdan ikinci sütundur. Sütunu başlık ismine göre okuyun, çünkü bu konum sürümler arasında değişiklik göstermiştir.

Okumaların tutarlı olması için iki alışkanlık edinin. İlk veri satırı sistem açılışından bu yana olan ortalamayı gösterir, bu yüzden onu görmezden gelin ve sonraki satırları okuyun. Ayrıca tek bir örnekleme ölçüm sayılmaz, çünkü steal time ani artışlarla gerçekleşir: vmstat 1 60 komutunu çalıştırın ve bir sonuca varmadan önce tam bir dakika boyunca izleyin.

top, %Cpu(s) özet satırında, st ile işaretlenmiş alanda aynı sayıyı raporlar:

%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

Çekirdek bazında detay için sysstat ekleyin:

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

mpstat, her vCPU'nun etkilenip etkilenmediğini gösteren bir %steal sütunu ile her CPU için bir satır yazdırır. Bir destek talebi için gereken geçmiş veriler adına, değerleri ekrandan okumak yerine örnekleri kaydedin:

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

Bunu şüphelendiğiniz saatler boyunca cron üzerinden çalıştırın; böylece dosya, sağlayıcıya "dün gece yavaştı" demek ile onlara tam on dakikalık süreyi göstermek arasındaki farkı yaratacaktır.

Steal değerleri ne anlama gelir?

• Sabit bir 0.0. Sistem sağlıklıdır veya platform steal değerini hiç raporlamıyordur. Kutlamadan önce systemd-detect-virt ile doğrulayın.
• Saniyeler süren birkaç yüzdelik ani yükselişler. Paylaşımlı bir düğümde normaldir. Bir komşunun derleme işlemi başlamış veya ana makine yedeklerini alıyor olabilir.
• Paylaşımlı bir planda sürekli yüzde 1 ila 5 arası. Beklenen durumdur. Ödenen ücret, paylaşımlı CPU kapasitesini yansıtır.
• Sürekli yüzde 5 ila 10 arası. Ölçülebilir bir yavaşlama. Kanıt toplamaya başlayın ve birkaç gün boyunca aynı saatleri karşılaştırın.
• Saatlerce yüzde 10'un üzerinde. Düğüm, iş yükünüz için aşırı yüklenmiştir. Bu seviye, bir destek talebi açmayı veya başka bir sunucuya geçmeyi haklı kılar.

Bu aralıkları bir şartname değil, okuma kılavuzu olarak değerlendirin; çünkü hiçbir sağlayıcı paylaşımlı planlarda steal garantisi vermez. Bu değerleri çalıştırdığınız iş yüküne göre tartın. Gece çalışan bir toplu iş (batch job), yüzde 15'lik steal değerini tolere edebilir ve kimse fark etmez. Gecikmeye duyarlı bir servis ise, ortalama değerler endişe verici görünmeden çok önce bunu p99 değerlerinde gösterir; bu yüzden işlem botları gibi gecikmeye duyarlı iş yükleri özel (dedicated) çekirdekler üzerinde çalıştırılmalıdır.

Steal time size ne kadara mal olur?

Hesaplama oldukça kısadır. CPU sürenizin s oranında bir kısmı çalınıyorsa, sabit miktarda CPU gerektiren bir işin tamamlanması saat süresi bazında 1 / (1 - s) kat daha uzun sürer. 60 saniyelik CPU süresine ihtiyaç duyan bir iş için:

[
  {
    "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"
  }
]

Sıradan bir paylaşımlı plan okuması olan 3 yüzde değerinde, bu iş 60.0 yerine 61.9 saniye sürer. Kimse bunun için bir destek talebi açmaz. 8 yüzde değerinde ise süre 65.2 saniyedir. 40 yüzde değerinde aynı iş 100.0 saniyeye ihtiyaç duyar ve normalde boşalan bir kuyruk, bu noktada birikmeye başlar.

Bunlar ölçüm değil, hesaplanmış değerlerdir. Model, tek bir çalıştırılabilir iş parçacığı olduğunu ve çalınan sürenin aralık boyunca eşit dağıldığını varsayar. Gerçek servisler genellikle bu eğriden daha kötü bir performans sergiler; çünkü çalınan bir dilim bir isteğin ortasına denk gelir ve gecikme, o isteği bekleyen her şey tarafından tekrar ödenir. Formül yerine kendi değerinizi elde etmek için, sunucuyu sakin bir saatte ve ardından yoğun bir saatte VPS performans testi ile test edin ve her iki zaman aralığı için st değerini kaydedin.

Bu "steal" mi, yoksa başka bir şey mi?

Steal, diğer belirtilerle kolayca karıştırılabilir. Sayaçları aynı vmstat satırı üzerinde birlikte okuyun.

• st yüksekken r ve us düşük kalıyorsa: ana makine size çekirdek süresi vermiyordur. Bu durum steal'dir.
• r vCPU sayınızın oldukça üzerindeyse, us yüksek ve st sıfıra yakınsa: kendi CPU kapasitenizin üzerinde iş çalıştırıyorsunuz demektir. r değerini nproc çıktısı ile karşılaştırın. Bu, bir komşudan kaynaklanan değil, kendi aşırı yüklemenizdir.
• wa yüksekken st sıfıra yakınsa: görevler depolama biriminde engelleniyordur; bu farklı bir sorundur ve farklı bir çözüm gerektirir.
• Load average yüksekken st ve us her ikisi de düşükse: yük değeri kesilemeyen görevleri de saydığından, bu durum genellikle CPU'dan ziyade takılı kalmış bir aygıta veya yanıt vermeyen bir ağ bağlantısına işaret eder.

Burstable (esnek) planlar ayrı bir notu hak eder. Bu planlar, boşta kaldığınızda biriken ve meşgul olduğunuzda azalan bir kredi bakiyesi sunar; kredi tükendiğinde sağlayıcı sizi temel bir hızda sınırlar. Bazı platformlarda bu kısıtlama steal olarak raporlanır. Bazılarında ise içeriden bakıldığında görünmez ve sadece saniye başına daha az işlem döngüsü alırsınız. Bir komşunun hatalı olduğuna karar vermeden önce plan açıklamasını okuyun.

Bir container neden steal time rapor etmez

Steal, container içinde çalışan bir sürecin değil, sanal makinenin bir özelliğidir. Kendi VPS'niz üzerindeki bir Docker container'ı, ana makinenin /proc değerini paylaşır; dolayısıyla içeriden okunan bir st değeri, VPS'nizin steal değeridir ve görmeniz gereken de budur. VPS olarak satılan container tabanlı sanallaştırma ise farklı davranır. lxcfs devredeyken, container içindeki /proc/stat değeri cgroup muhasebesinden sentezlenir ve steal değeri yapısal olarak sıfırdır. Yalnızca içeriden veri toplayan bir izleme yığını, alttaki fiziksel makine kaynak sıkıntısı çekerken bile düz ve sabit bir sıfır değeri gösterebilir.

Bir container içinde aynı anlama gelen sayaç, CPU kota kısıtlamasıdır (CPU quota throttling). cgroup v2 üzerinde:

cat /sys/fs/cgroup/cpu.stat

nr_throttled, grubun CPU kotasına takıldığı uygulama dönemlerini sayar, throttled_usec ise sürecin dondurulmuş halde geçirdiği toplam süreyi tutar. Artan bir nr_throttled değeri, sürecinizin çalışmaya hazır olduğu ancak çalıştırılmadığı anlamına gelir; bu, steal ile aynı deneyimdir ancak sizin tarafınızdan belirlenen bir sınırdan kaynaklanır. Özellikle servislerinizi bir VPS üzerinde Docker ile çalıştırıyorsanız ve compose dosyanızda CPU limitleri tanımlıysa, ana makineyi suçlamadan önce kendi limitlerinizi kontrol edin. Katmanlı sanallaştırma, zamanın kaybolabileceği bir nokta daha ekler; çünkü VPS'niz içindeki bir sanal makine, hem sizin steal değerinizi hem de kendi zamanlama gecikmesini öder. Eğer bir VPS üzerinde iç içe sanallaştırma (nested virtualisation) çalıştırıyorsanız bunu göz önünde bulundurun.

Sürekli steal süresi ile ne yapılmalı

Konuk sistem içerisindeki hiçbir ayar steal sorununu çözmez, çünkü kararı veren zamanlayıcı konuk sistemin dışında çalışır. Dört hamle gerçektir.

Önce kanıt toplayın. Zaman damgalarını UTC olarak, her bir olayın süresini, ne sıklıkla tekrarlandığını ve mpstat çıktısının tek bir vCPU'yu mu yoksa hepsini mi etkilediğini kaydedin. Bir haftalık günlük örnekleri, bir ekran görüntüsünden daha değerlidir.

Bu verilerle bir destek talebi açın. İki doğrudan soru sorun: bu zaman aralıklarında düğüm aşırı yükleniyor mu ve örneğim taşınabilir mi? vmstat çıktısını ve tam zamanları yapıştırın. Sağlayıcılar tekrarlanabilir bir zaman aralığında işlem yapar; sadece sunucunun yavaş olduğunu belirten bir talep, sizden bu bilgileri isteyen bir yanıtla sonuçlanır. Bu işin ne kadarını devredebileceğiniz, yönetilen ve yönetilmeyen bir VPS arasındaki pratik farklardan biridir.

Taşıma talep edin. Bir konuğu daha az yüklü bir düğüme taşımak, sağlayıcı için rutin bir iştir ve genellikle kısa bir yeniden başlatma gerektirir. Bu, hiçbir maliyeti olmayan ve bir düğümün aynı anda birkaç ağır komşuyu barındırması gibi yaygın durumları çözen yöntemdir.

Çekişmeyi satın alarak giderin. Dedicated vCPU planı, fiziksel çekirdekleri örneğiniz için ayırır; böylece sayaç sıfırda kalır. Aylık maliyeti daha yüksektir ve değişkenliği kaldıramayan iş yükleri için dürüst çözümdür. Eğer bu da yeterli değilse veya bellek bant genişliğini de tamamen kendinize ayırmak istiyorsanız, bir sonraki adım VPS yerine dedicated sunucu kullanmaktır.

Bunların herhangi biri için beklerken, steal sorununun etkisini azaltın. vCPU sayınızdan daha az sayıda iş parçacığı (worker thread) çalıştırın, çünkü çekirdek alamayan iş parçacıkları sadece bağlam anahtarlamasına (context switch) neden olur. Toplu işleri, kendi günlüklerinizden öğrendiğiniz düğümün sakin olduğu saatlere kaydırın. Ardından aynı komutla aynı saatlerde tekrar ölçüm yapın; böylece tahmin yürütmek yerine değişikliğin işe yarayıp yaramadığını söyleyebilirsiniz.

FAQ

Bir VPS üzerinde normal CPU steal süresi nedir?

Paylaşımlı bir planda, kısa süreli sıçramalar ve yüzde 5'in altındaki sürekli değerler normaldir; çünkü paylaşımlı CPU, fiziksel çekirdeklerin konuk sistemler arasında bölüştürüldüğü anlamına gelir. Saatler süren çift haneli değerler normal değildir ve bir destek talebi açılmasını gerektirir. Dedicated vCPU planında beklenen değer 0.0'tür, bu nedenle bunun dışındaki her durum bildirilmesi gereken bir hatadır. Sayıyı kendi iş yükünüze göre değerlendirin: gece çalışan bir toplu iş (batch job), gecikmeye duyarlı bir API'nin tolere edemeyeceği steal değerlerini absorbe edebilir.

Daha büyük bir plan yüksek steal süresini çözer mi?

Tek başına hayır. Aynı paylaşımlı düğüm üzerinde daha fazla vCPU, aynı fiziksel çekirdekler için yarışan daha fazla sanal CPU demektir ve yüzde değeri tam olarak aynı kalabilir. Steal süresini ortadan kaldıran şey, dedicated CPU tahsisi veya daha az yüklü bir düğüme geçiştir. Yoğun bir makineden alınan daha büyük bir pay, hala yoğun bir makineden alınan bir paydır.

VPS neden yavaş olmasına rağmen 0 steal süresi gösteriyor?

Bunun iki yaygın nedeni vardır. Hipervizör, sayacı hiç dışa aktarmıyor olabilir; bu durum VMware ve Hyper-V platformlarında yaygındır, bu nedenle ana makine ne yaparsa yapsın ilgili alan sıfırda kalır. Hangi platformda olduğunuzu görmek için systemd-detect-virt komutunu çalıştırın. Diğer taraftan darboğaz başka bir yerdedir: depolama beklemeleri için wa komutunu kontrol edin, kendi aşırı yükünüzü görmek için r ve nproc değerlerini karşılaştırın ve container içindeki kota kısıtlamaları için /sys/fs/cgroup/cpu.stat değerini okuyun.

Sunucumun içinden steal süresini azaltabilir miyim?

Konuk sistemin içinden ana makinenin zamanlama ayarlarını değiştiremezsiniz. Yalnızca bunun yarattığı etkiyi azaltabilirsiniz. vCPU sayınızdan daha az sayıda işçi iş parçacığı (worker thread) çalıştırın; böylece gelmeyecek bir çekirdeği bekleyen çalışma kuyruğunda daha az iş birikir. Toplu işleri, düğümün daha sakin olduğu saatlere erteleyin. Sonuçları önbelleğe alın, böylece daha az istek CPU gücüne ihtiyaç duyar. Steal süresini gerçekten ortadan kaldıran değişiklikler, yani başka bir düğüme geçiş veya dedicated çekirdekler, sağlayıcının sorumluluğundadır.