Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
Linux kernel dokümantasyonu `/proc/stat` içindeki steal alanını guest'in istemsiz bekleme süresi olarak tanımlar; sar man sayfası `%steal` için hypervisor başka virtual processor'ı çalıştırırken vCPU'nun beklediği zamanı açıklar.
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Linux VPS/VDS'de %steal değerini top, mpstat, sar ve /proc/stat ile ölçün; CPU contention, overselling ve gerçek uygulama yavaşlığını ayırın.
Linux kernel dokümantasyonu `/proc/stat` içindeki steal alanını guest'in istemsiz bekleme süresi olarak tanımlar; sar man sayfası `%steal` için hypervisor başka virtual processor'ı çalıştırırken vCPU'nun beklediği zamanı açıklar.
Steal time fiziksel bare-metal sunucuda aynı anlamda ortaya çıkmaz; sanallaştırma scheduler'ı bağlamına özgü bir sinyaldir.
Guest işletim sistemi çalışmak istese bile hypervisor fiziksel CPU zamanını başka VM'e verebilir. Bu süre guest açısından `%steal` olarak görülebilir. Uygulama kendi CPU kullanımını düşük gösterirken request latency artabilir.
Ancak her yavaşlık steal değildir. Disk iowait, memory pressure/swap, network loss, DB lock, PHP worker kuyruğu ve DNS gibi nedenler de benzer hissedilir. Bu yüzden steal tek metrik değil teşhis sinyalidir.
`top` CPU satırındaki `st`, hızlı kontrol sağlar. `mpstat -P ALL 1` çekirdek bazında `%steal` gösterir. `sar -u 1 60` zaman serisi görmenizi sağlar. sysstat kurulu değilse `/proc/stat` ham verisi izlenebilir.
topmpstat -P ALL 1 20sar -u 1 60grep '^cpu ' /proc/statBir saniyelik spike karar vermek için yeterli değildir. Aynı workload altında farklı saatlerde 5-15 dakikalık örnekler alın. Steal değerinin trafik yoğun saatlerde düzenli yükselmesi host contention şüphesini güçlendirir.
Hostinger kendi dokümanında düşük tek haneli steal değerlerinin etkisini kademeli yorumluyor; ancak evrensel '10% altı her zaman normal' standardı yoktur. Latency-sensitive workload için küçük oranlar bile hissedilebilir.
cgroup CPU quota veya provider CPU limitinde guest kendi hakkını tükettiği için throttle olabilir; steal ise hypervisor'ın guest'i istemsiz bekletmesiyle ilgilidir. İki durum aynı yavaşlığı yaratabilir ama çözümü farklıdır.
Container tabanlı VPS'de CPU throttling metrikleri cgroup üzerinden daha belirgin olabilir. Full VM'de steal ve guest scheduler metrikleri ön plana çıkar.
Aynı VM'de sysbench CPU testi, uygulama response time ve steal değerini aynı anda kaydedin. İş yükü aynı kalırken sysbench süresi ve uygulama latency steal ile birlikte bozuluyorsa host contention ihtimali güçlenir.
sysbench cpu --threads=1 --time=30 runsysbench cpu --threads=$(nproc) --time=30 runSaat dilimiyle birlikte tarih/saat, `mpstat` veya `sar` çıktısı, VM CPU modeli/vCPU sayısı, aynı anda çalışan workload ve mümkünse uygulama response grafiği gönderin. 'Sunucu yavaş' yerine ölçülebilir örnek paylaşmak node taşıma veya host incelemesini hızlandırır.
| Metrik | Yükseliyorsa ne düşünülür? |
|---|---|
| %steal | Hypervisor scheduling/contention |
| %iowait | Disk/storage bekleme |
| Load yüksek, CPU düşük | I/O veya blocked task |
| Swap artıyor | Memory pressure |
Tek bir benchmark, port etiketi veya CPU marka adıyla satın alma kararı vermeyin. Aynı testleri farklı saatlerde tekrarlayın; destructive disk testlerini production verisi üzerinde çalıştırmayın ve sağlayıcının kaynak/fair-use politikasını yazılı doğrulayın.
İdeal olarak düşük ve tutarlı olması beklenir; sanallaştırma ortamında kısa küçük değerler olabilir. Workload latency'siyle birlikte değerlendirin.
Guest optimizasyonu yükü azaltabilir ama fiziksel host contention kök nedense provider tarafında node/resource politikası gerekir.
Projenizin yazılımını, eşzamanlı kullanıcı sayısını, disk/veritabanı yükünü ve lokasyon hedefini iletin; yalnız RAM/Core sayısına değil gerçek darboğaza göre sunucu sınıfını belirleyin.