CPU Steal Time Nedir, Nasıl Ölçülür

Sunucun yavaş, ama top çıktısında CPU kullanımı %20, bellek rahat, disk boşta ve ağda sorun yok. Uygulaman aynı işi bazen 200 ms'de, bazen 900 ms'de yapıyor ve bunun için hiçbir açıklaman yok. Sanal bir sunucudaysan bu tablonun en olası açıklaması CPU steal time'dır: hipervizörün senin vCPU'na zaman vermediği, yani başka bir misafirin senin sıranı aldığı süredir.

Steal time, sanal sunucu dünyasında ölçebileceğin en dürüst metriklerden biridir çünkü doğrudan misafirin kendi çekirdeği tarafından raporlanır ve sağlayıcının pazarlama iddialarından bağımsızdır. Bu rehberde steal time'ın teknik olarak ne olduğunu, hangi komutlarla ölçüleceğini, hangi eşiğin gerçekten sorun sayıldığını, düşük CPU kullanımıyla yüksek gecikmenin nasıl bir arada olabileceğini ve sağlayıcıyla konuşurken elinde hangi kanıtın bulunması gerektiğini anlatacağım.

Steal Time Teknik Olarak Nedir#

Sanallaştırılmış bir sistemde misafir işletim sisteminin çekirdeği, zamanı kategorilere ayırarak sayar: kullanıcı alanı (us), çekirdek alanı (sy), boşta (id), I/O beklemesi (wa) ve steal (st). Steal, "çalıştırılabilir durumdaydım, iş yapmaya hazırdım, ama hipervizör bana fiziksel çekirdek vermedi" anlamına gelir. Bu ölçüm mümkün olur çünkü modern hipervizörler misafire paravirtualize bir saat sunar; misafir, gerçek zamanın ne kadar aktığını ve kendisine bu sürenin ne kadarının verildiğini karşılaştırarak farkı hesaplar.

Kritik ayrım şudur: steal time, senin işlemcinin meşgul olduğu süre değildir; senin işlemcinin var olmadığı süredir. %10 steal time gördüğünde, sunucunun her saniyesinin 100 milisaniyesi boyunca CPU sana ait değildi demektir. Bu süre boyunca uygulaman donmuş gibidir — ne CPU harcar ne de ilerler. Bu yüzden düşük CPU kullanımıyla yüksek gecikme aynı anda görülebilir ve klasik teşhis refleksleri (CPU'ya bak, belleğe bak) yanıltıcı olur.

Steal time'ın kaynağı her zaman komşular değildir. Üç ayrı sebep olabilir:

Üçünü ayırt etmenin yolu zaman içindeki desene bakmaktır; birazdan bunun için pratik bir yöntem vereceğim.

Steal Time'ı Ölçme Komutları#

En hızlı yol vmstat'tır ve neredeyse her dağıtımda kurulu gelir. Son sütun olan st doğrudan steal yüzdesidir:

# Her saniye bir örnek, toplam 20 örnek
vmstat 1 20

# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  2  0      0 384512  92104 1204336   0    0     0    12  892 1640 18  3 72  0  7
#  3  0      0 384380  92104 1204336   0    0     0     0  915 1702 21  4 63  0 12

Buradaki 7 ve 12 değerleri, o saniyede CPU zamanının yüzde kaçının senden alındığını gösterir. top çıktısında da aynı bilgi vardır; üst satırdaki CPU özetinde st kısaltmasıyla görünür:

top -bn1 | head -3
# %Cpu(s): 18.2 us,  3.1 sy,  0.0 ni, 66.4 id,  0.3 wa,  0.0 hi,  0.2 si, 11.8 st

Uzun vadeli eğilim için sysstat paketinin sar aracı en iyi seçenektir çünkü verileri diske yazar ve geçmişe dönük sorgulamana izin verir:

# sysstat kurulumu (Debian/Ubuntu)
apt install sysstat && systemctl enable --now sysstat

# Bugünün saat bazında CPU dağılımı, %steal sütunuyla
sar -u
# 10:00:01 CPU  %user  %nice  %system  %iowait  %steal  %idle
# 10:10:01 all  16.44   0.00     2.91     0.22    9.87   70.56

# Dün için (log dosyası numarası ayın günüdür)
sar -u -f /var/log/sysstat/sa24

Konteyner içinden bakıyorsan /proc/stat dosyasındaki sekizinci alan ham steal sayacını (jiffy cinsinden) tutar; iki ölçüm arasındaki farkı alarak kendi hesabını yapabilirsin:

# Ham steal sayacı: cpu satırının 8. değeri
awk '/^cpu /{print "steal jiffies:", $9}' /proc/stat

Hangi Eşik Gerçekten Sorun#

Steal time'ın "kabul edilebilir" değeri, satın aldığın ürünün türüne göre değişir. Sıfır steal beklemek yalnızca fiziksel makinelerde ve tam pinlenmiş VDS ürünlerinde makuldür. Aşağıdaki eşikler, sahada işe yarayan pratik bir kılavuzdur:

Bu tabloyu kullanırken ortalamaya değil dağılıma bak. Günlük ortalaman %3 olabilir ama iş saatlerinde %18'e çıkıp geceleri sıfıra düşüyorsa, müşterilerin en yoğun olduğu saatte sorun yaşıyorsun demektir ve ortalama seni yanıltır. Basit bir örnek dağılım çıkarmak için:

# 10 dakika boyunca saniyede bir ölç, steal değerlerini say
vmstat 1 600 | awk 'NR>2 {print $NF}' | sort -n | uniq -c | tail -20

Bu çıktı sana en yüksek steal değerlerinin ne sıklıkta görüldüğünü verir. Birkaç ani sıçrama normaldir; ölçümlerin %20'sinden fazlası çift haneliyse elinde somut bir problem var demektir.

Steal Time ile I/O Beklemesini Karıştırmamak#

Sık yapılan bir teşhis hatası, steal time ile wa (iowait) sütununu karıştırmaktır. İkisi de "CPU çalışmıyor ama iş bitmiyor" tablosu yaratır, sebepleri ise tamamen farklıdır. wa, CPU'nun elinde iş olduğu ama diskten veri beklediği süredir — sorun depolamadadır. st ise CPU'nun elinde iş olduğu ama fiziksel çekirdeğin başkasına verildiği süredir — sorun hipervizördedir.

Ayırt etmek için ikisini aynı anda izle ve disk gecikmesini ayrıca ölç:

# CPU dağılımı ve disk gecikmesini birlikte gör
iostat -x 1 5

# Device  r/s   w/s   rkB/s   wkB/s  r_await  w_await  %util
# vda    12.4  38.9   198.2  1204.6     0.62     1.14    9.8

r_await ve w_await değerleri milisaniye cinsinden ortalama istek gecikmesidir. SSD tabanlı bir sistemde bunların tek haneli olması beklenir; %util düşükken await yüksekse depolama katmanında paylaşım sorunu var demektir. Her ikisi de sağlıklıysa ve st yüksekse, teşhis CPU tarafındadır.

Bu iki metriği ayrı ayrı düşünmek önemlidir çünkü çözümleri farklıdır: iowait sorunu daha hızlı disk ya da daha iyi sorgu indeksleriyle çözülür; steal sorunu ise ancak farklı bir kaynak modeline geçerek çözülür. vCPU'nun fiziksel çekirdeğe nasıl eşlendiğini ve hangi tahsis oranlarının hangi steal değerlerini ürettiğini vCPU ile fiziksel çekirdek ilişkisi yazısında sayısal olarak ele aldım.

Steal Time'ı Azaltmak İçin Ne Yapabilirsin#

Steal time'ın kaynağı senin makinenin dışında olduğu için, misafir tarafında yapabileceklerin sınırlıdır — ama tamamen çaresiz değilsin. Sırayla denenmesi gereken adımlar şunlardır:

1. Deseni belgele. En az 48 saatlik sar verisi topla. Sağlayıcıya "sunucu yavaş" demek sonuç vermez; "şu tarihlerde saat 10:00-18:00 arasında ortalama %14 steal ölçtüm" demek sonuç verir.
2. Kendi yükünü profilleyip azalt. Steal, senin vCPU talebin arttıkça daha görünür hale gelir. Gereksiz cron işlerini yoğun saatlerden çıkarmak, önbellek katmanı eklemek ve sorguları düzeltmek talebi düşürür, dolayısıyla bekleme de azalır.
3. vCPU sayısını gözden geçir. Fazla vCPU, hipervizörün hepsini aynı anda zamanlamasını zorlaştırdığı için steal'i artırabilir. Kullanılmayan çekirdekleri düşürmek bazen sayacı iyileştirir.
4. Ana makine değişikliği iste. Çoğu sağlayıcı, kanıt sunduğunda misafiri daha az yüklü bir ana makineye taşır. Bu genellikle kısa bir yeniden başlatma gerektirir.
5. Ürün modelini değiştir. Kalıcı çözüm budur: garantili kaynak veren bir ürüne geçmek.

Beşinci maddede seçeneklerin net: çekirdeklerin sabitlendiği bir VDS, tüm makinenin sana ait olduğu dedicated sunucu ya da kaynak sınırlarının açıkça tanımlandığı bir bulut sunucu. Hangi ürünün hangi durumda mantıklı olduğunu bulut sunucu mu VDS mi yazısında karşılaştırdım.

İzleme ve Alarm Kurmak#

Steal time'ı bir kez ölçmek teşhis içindir; sürekli izlemek ise sorunun tekrar etmesini yakalar. Herhangi bir izleme aracın yoksa basit bir betikle başlayabilirsin. Aşağıdaki örnek, beş dakikalık ortalama steal değeri eşiği aşarsa bir log satırı yazar:

#!/bin/bash
# /usr/local/bin/steal-watch.sh
ESIK=8
ORT=$(vmstat 1 300 | awk 'NR>2 {t+=$NF; n++} END {printf "%.1f", t/n}')
if (( $(echo "$ORT > $ESIK" | bc -l) )); then
  logger -t steal-watch "Yuksek steal time: %$ORT (esik %$ESIK)"
fi

Bunu bir cron kaydıyla saatlik çalıştırıp journalctl -t steal-watch ile geçmişi okuyabilirsin:

# /etc/cron.d/steal-watch
0 * * * * root /usr/local/bin/steal-watch.sh

Daha kapsamlı bir izleme kuruyorsan, steal metriğini yanıt süresi grafiğinle aynı panelde göstermeyi öneririm. İkisinin birlikte yükseldiğini görmek, aylarca sürebilecek bir tartışmayı tek bakışta bitirir. Servislerinin ayakta olup olmadığını dışarıdan da izlemek istersen uptime SLA hesaplayıcı aracıyla hedeflediğin erişilebilirlik oranının pratikte kaç dakikalık kesintiye denk geldiğini görebilirsin.

Sıkça Sorulan Sorular#

Steal time yüzde kaçın üstünde sorun sayılır#

Genel kabul, %5'in üstünün dikkat, %10'un üstünün ise müdahale eşiği olduğudur. Ancak bu değerler ürün türüne bağlıdır: garantili kaynaklı bir VDS'te %3 bile açıklanması gereken bir durumken, ucuz paylaşımlı bir VPS'te %5 normal karşılanabilir. Asıl önemli olan sayının kendisi değil, uygulamanın yanıt süresiyle birlikte hareket edip etmediğidir.

Fiziksel sunucuda steal time görülür mü#

Hayır. Steal time kavramı sanallaştırmaya özgüdür ve hipervizör olmayan bir sistemde her zaman sıfırdır. Fiziksel bir sunucuda vmstat çıktısındaki st sütunu sürekli 0 gösterir. Bu sütunda sıfırdan farklı bir değer görüyorsan, makinen bir hipervizör üzerinde çalışıyor demektir — bazen "bare metal" sanılan makinelerin aslında sanal olduğu böyle anlaşılır.

Steal time'ı kendi tarafımda tamamen sıfırlayabilir miyim#

Misafir tarafından tek başına sıfırlaman mümkün değildir, çünkü kararı veren hipervizördür. Yapabileceğin şey talebini azaltmak (yoğun saatlerdeki iş yükünü dağıtmak, gereksiz süreçleri kapatmak) ve sağlayıcıdan daha az yüklü bir ana makineye taşınma talep etmektir. Kalıcı olarak sıfıra yakın değer istiyorsan, çekirdeklerin fiziksel olarak ayrıldığı bir ürüne geçmek gerekir.

top çıktısında st sütununu göremiyorum, neden#

Bazı top sürümleri dar terminallerde CPU satırını kısaltır ya da sütunu gizler. Terminal genişliğini artırmayı, top içinde t tuşuna basarak CPU görünümünü değiştirmeyi deneyebilirsin. Daha güvenilir yol vmstat 1 kullanmaktır; oradaki son sütun her zaman steal değeridir. /proc/stat dosyasındaki cpu satırının sekizinci alanı da ham sayacı verir.

Yüksek steal time verilerimi tehlikeye atar mı#

Doğrudan veri kaybına yol açmaz; steal time bir performans sorunudur, bütünlük sorunu değil. Ancak dolaylı riskler vardır: zaman aşımına uğrayan istekler yarım kalan işlemler yaratabilir, kuyruklar birikebilir ve sağlık kontrolleri başarısız olduğunda yük dengeleyici sunucuyu devre dışı bırakabilir. Uzun süren yüksek steal, kritik servislerde mutlaka çözülmesi gereken bir durumdur.

Steal time ölçmek için ek yazılım kurmam gerekir mi#

Hayır, temel ölçüm için hiçbir ek yazılım gerekmez. vmstat ve top neredeyse tüm Linux dağıtımlarında kurulu gelir ve ikisi de steal değerini gösterir. Geçmişe dönük analiz yapmak istiyorsan yalnızca sysstat paketini kurman yeterlidir; bu paket sistemi periyodik olarak örnekler ve sar komutuyla günler öncesine bakmanı sağlar.

Kapanış#

CPU steal time, sanal sunucularda "neden yavaş" sorusunun en doğrudan cevabıdır ve ölçmesi bir dakikadan az sürer. Aklında kalması gereken pratik alışkanlıklar şunlar: yavaşlık şikâyetinde ilk bakılacak yer vmstat çıktısındaki st sütunu olsun, ortalama yerine yoğun saatlerin dağılımına bak, steal ile iowait'i asla karıştırma ve sağlayıcıyla konuşmadan önce en az iki günlük veri topla.

Ölçtüğün değerler kalıcı olarak yüksek çıkıyorsa çözüm ayar değil, model değişikliğidir. Çekirdeklerin sana ayrıldığı VDS paketlerimiz ya da tüm donanımın senin olduğu dedicated sunucu seçeneklerimiz bu sorunu kaynağında ortadan kaldırır; büyüme planın belirsizse bulut sunucu tarafı esneklik sağlar. Ölçüm, taşıma ve izleme kurulumunu kendin yapmak istemiyorsan sunucu yönetimi hizmetimiz bu süreci senin yerine yürütür.