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

CPU steal time gerçekte neyi ölçer

CPU steal time, sanal CPU'nuzun çalışmaya hazır olduğu ve bekleyecek hiçbir şeyi olmadığı halde, 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ığı zaman us (user) veya sy (system) olarak raporlanır. Bir görevin depolama biriminde engellenerek harcadığı zaman wa (I/O wait) olarak raporlanır. Çalıştırılabilir durumda olan, çalıştırma 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 makinede (host) 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, bu yüzden ana makine çekirdekleri sizinle paylaşır. 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 bunu 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 veriyi hipervizör sağlar. 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 —ki tüm dağıtım çekirdekleri bu şekilde derlenir— konuk işletim sistemi bu değerleri toplar. Xen ise 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. Sıralama şöyledir: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal, etiketten sonraki sekizinci değerdir. Aşağıdaki tüm araçlar, vmstat, top, mpstat ve herhangi bir Prometheus 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, ilgili alan sonsuza kadar sıfır kalır ve bu alana dayanan 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 çalıştırıldığında ise makinenin kendisi hakkında değil, lxc, docker veya podman gibi çalışma zamanı (runtime) hakkında bilgi verir. kvm üzerinde görülen bir sıfır, ana makinenin size iyi davrandığının gerçek bir kanıtıdır. Bu 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 yüzden 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 olmak üzere toplam beş örnek 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 sağda değil, sağdan ikinci sıradadır. 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ı sistemin 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 örnek ö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 veya sadece birinin mi etkilendiğini gösteren %steal sütunu ile her CPU için bir satır yazdırır. Destek talebi için gereken geçmiş verisi adına, değerleri ekrandan okumak yerine örnekleri kaydedin:

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

Bu komutu şüphelendiğiniz saatler boyunca cron üzerinden çalıştırın; böylece dosya, servis sağlayıcınıza "dün gece yavaştı" demek ile onlara tam on dakikalık süreci kanıtlarıyla göstermek arasındaki farkı yaratacaktır.

Steal değerleri ne anlama gelir?

• Sabit bir 0.0. Sağlıklı bir durumdur veya platform steal değerini raporlamıyordur. Kutlamadan önce systemd-detect-virt ile doğrulayın.
• Saniyeler süren birkaç yüzdelik ani yükselişler. Paylaşımlı tüm düğümlerde 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 bir durumdur. Fiyat, 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 aynı saatleri birkaç gün boyunca karşılaştırın.
• Saatler boyunca 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 sunucu değişikliği yapmayı 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 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 p99 değerlerinde bunu yansıtır; bu yüzden ticaret 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. Eğer CPU sürenizin s oranında bir kısmı alınıyorsa, sabit miktarda CPU gerektiren bir iş, saat üzerinde 1 / (1 - s) kat daha uzun sürer. 60 saniyelik CPU gerektiren 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 bu süre 65.2 saniyedir. 40 yüzde değerinde aynı iş 100.0 saniyeye ihtiyaç duyar ve normalde boşalan bir kuyruk, bunun yerine büyümeye başlar.

Bunlar ölçüm değil, hesaplanmış değerlerdir. Model, tek bir çalıştırılabilir iş parçacığı ve aralık boyunca eşit dağılmış bir steal süresi 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. Bir formül yerine kendi verinizi elde etmek için, sakin bir saatte ve yoğun bir saatte VPS performansını test edin ve her iki zaman aralığı için de st değerini kaydedin.

Çalma (steal) mı, yoksa başka bir şey mi?

Çalma (steal) belirtisini diğerleriyle karıştırmak kolaydır. Sayaçları aynı vmstat satırı üzerinde birlikte inceleyin.

• st yüksekken r ve us düşük kalıyorsa: ana makine size çekirdek süresi vermiyordur. Bu durum çalmadır (steal).
• r vCPU sayınızın oldukça üzerindeyse, us yüksek ve st sıfıra yakınsa: kendi CPU kapasitenizin üzerinde iş yükü çalıştırıyorsunuzdur. r değerini nproc çıktısıyla 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.
• Yük ortalaması (load average) yüksekken st ve us değerlerinin her ikisi de düşükse: yük değeri kesilemeyen görevleri de saydığı için 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 (anlık yükselmeye izin veren) planlar ayrı bir notu hak eder. Bu planlar, boşta kaldığınızda biriken ve yoğun olduğunuzda azalan bir kredi bakiyesi sunar; kredi tükendiğinde ise sağlayıcı sizi temel hız sınırında tutar. Bazı platformlarda bu kısıtlama çalma (steal) olarak raporlanır. Bazılarında ise içeriden bakıldığında görünmez ve sadece saniye başına daha az çevrim 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 üzerinde çalışan bir Docker container'ı, ana makinenin /proc kaynağını 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ı gereği sıfırdır. Yalnızca içeriden veri toplayan bir izleme yığını, alttaki fiziksel makine kaynak yetersizliği çekse 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 (throttling). cgroup v2 üzerinde:

cat /sys/fs/cgroup/cpu.stat

nr_throttled, grubun CPU kotasına ulaştığı zorlama periyotlarını sayar ve throttled_usec, 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 limitten kaynaklanır. Özellikle servislerinizi bir VPS üzerinde Docker ile çalıştırıyorsanız ve compose dosyasında CPU limitleri tanımladıysanız, 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 çalıştırıyorsanız bunu göz önünde bulundurun.

Sürekli steal (çalınan zaman) durumunda ne yapılmalı

Konuk işletim sistemi içindeki hiçbir ayar steal sorununu çözmez; çünkü bu kararı veren zamanlayıcı, konuk sistemin dışında çalışır. Çekirdeği yükseltmek de bunu değiştirmez: Linux kernel 7.2 ile eklenen önbellek duyarlı zamanlama, görevlerinizi size fiilen tahsis edilen çekirdekler üzerinde yeniden düzenler ancak bir komşunun halihazırda aldığı döngüleri geri kazanamaz. Dört hamle gerçektir.

Önce kanıt toplayın. Zaman damgalarını UTC olarak kaydedin, her bir olayın süresini, ne sıklıkla tekrarlandığını ve mpstat çıktısının tek bir vCPU'yu mu yoksa tamamını mı etkilediğini not edin. Bir haftalık günlük örnekleri, tek 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 (node) aşırı yükleniyor mu ve örneğim başka bir yere taşınabilir mi? vmstat çıktısını ve tam zamanları yapıştırın. Sağlayıcılar tekrarlanabilir bir zaman aralığına göre hareket eder; 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ılar için rutin bir işlemdir 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 rezerve eder; böylece sayaç sıfırda kalır. Aylık maliyeti daha yüksektir ancak varyansı tolere edemeyen 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.

Tüm bu süreçleri beklerken, steal durumunun verdiği zararı azaltın. vCPU sayınızdan daha az sayıda işçi iş parçacığı (worker thread) çalıştırın; çünkü çekirdek alamayan iş parçacıkları sadece bağlam anahtarlamayı (context switch) artırır. Toplu işlerinizi, kendi günlüklerinizden tespit ettiğiniz düğümün sakin olduğu saatlere kaydırın. Ardından aynı komutla aynı saatler üzerinde 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 time değeri 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 oluşturulmasını gerektirir. Dedicated vCPU planında beklenen değer 0.0'tür, dolayısıyla 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 üst bir plan yüksek steal time sorununu çözer mi?

Tek başına hayır. Aynı paylaşımlı düğüm üzerinde daha fazla vCPU, aynı fiziksel çekirdekler için rekabet eden daha fazla sanal CPU anlamına gelir ve yüzde değeri tam olarak aynı kalabilir. Steal değerini ortadan kaldıran şey, dedicated CPU tahsisidir 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'im bariz bir şekilde yavaş olmasına rağmen neden 0 steal time 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. Aksi takdirde darboğaz başka bir yerdedir: depolama bekleme süreleri için wa'i kontrol edin, kendi aşırı yüklenmeniz için r ile nproc değerlerini karşılaştırın ve container içindeki kota kısıtlamalarını görmek için /sys/fs/cgroup/cpu.stat'i inceleyin.

Sunucumun içinden steal time değerini düşürebilir miyim?

Konuk sistemin içinden ana makinenin zamanlama ayarlarını değiştiremezsiniz. Yalnızca bunun yarattığı olumsuz 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şlerinizi 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 değerini gerçekten ortadan kaldıran değişiklikler, yani başka bir düğüme geçiş veya dedicated çekirdekler, sağlayıcının yetki alanındadır.