VPS’te Noisy Neighbor ve CPU Steal Sorunlarını Tespit Etmek ve Azaltmak

VPS kullanırken CPU grafikleri tavan yapmadığı hâlde uygulamanızın arada bir sebepsiz yavaşladığını, cron işlerinizin uzadığını veya veritabanı sorgularınızın aynı yükte daha geç döndüğünü mutlaka yaşamışsınızdır. Özellikle kapasite planlama toplantılarında “Sunucuyu büyütelim mi, yoksa sorun başka yerde mi?” sorusuna net cevap verememek, teknik ekibin en sık zorlandığı noktalardan biridir. Bu belirsizliğin arkasında çoğu zaman noisy neighbor (gürültücü komşu) ve CPU steal sorunları yatar.

VPS dünyasında işlemci, RAM, disk ve ağ kaynakları fiziksel bir sunucu üzerinde sanallaştırılarak birden fazla kiracıya paylaştırılır. Eğer aynı fiziksel host üzerinde sizin VPS’inizle birlikte çalışan başka bir VPS anlık olarak çok yoğun CPU kullanırsa, hipervizör önceliği o tarafa kaydırabilir. Siz kendi sanal makinenizde CPU tüketmiyor olsanız bile, CPU steal time adı verilen bu durum yüzünden işlemcinin bir kısmını paylaşamadığınız için uygulamanız yavaşlar. Bu yazıda VPS’te noisy neighbor ve CPU steal sorunlarını hem nasıl tespit edeceğinizi hem de uygulama, sistem ve altyapı seviyesinde nasıl azaltabileceğinizi adım adım anlatacağız.

VPS’te Noisy Neighbor ve CPU Steal Nedir?

Noisy neighbor, aynı fiziksel sunucu üzerinde çalışan başka bir VPS’in, sizinle paylaşılan kaynakları (özellikle CPU, disk IO ve ağ) orantısız biçimde tüketmesi sonucu performansınızı olumsuz etkilemesi anlamına gelir. Buradaki “gürültü”, doğrudan sizin VPS’inizde görünen bir proses değil, altyapı tarafında paylaşılan fiziksel kaynağın baskılanmasıdır.

CPU steal ise özellikle KVM gibi sanallaştırma ortamlarında karşımıza çıkan, sanal makinenin çalıştırmak istediği CPU talebinin, hipervizör tarafından geç veya kısmen karşılanması durumunda ölçülen zaman dilimidir. Basitçe:

• VPS içindeki çekirdek, CPU’da 100 ms çalışmak istiyor,
• Hipervizör yoğunluktan dolayı bu isteği hemen karşılayamıyor,
• Aradaki “bekleme” süresi steal time olarak kaydediliyor.

Bu iki kavram birbirine sıkı sıkıya bağlıdır: Genellikle yüksek CPU steal değerleri, aynı hosttaki noisy neighbor etkisine işaret eder. Ancak her steal artışı illa ki kötü bir altyapı anlamına gelmez; önce sistematik biçimde ölçmek ve diğer metriklerle birlikte yorumlamak gerekir.

CPU Steal ve Noisy Neighbor Nasıl Tespit Edilir?

Linux Araçlarıyla CPU Steal Ölçümü

VPS içinde doğrudan fiziksel hostu göremezsiniz ama Linux çekirdeğinin sunduğu bazı metriklerle steal time’ı izleyebilirsiniz. En pratik araçlardan bazıları şunlardır:

• top: Varsayılan görünümde CPU satırında st alanı steal time’ı gösterir.
• htop: Her çekirdek için ayrı steal yüzdesini görmek için Setup > Columns kısmından Steal sütununu ekleyebilirsiniz.
• mpstat (sysstat paketi): mpstat -P ALL 1 çıktısında her CPU için %steal kolonu yer alır.
• vmstat: vmstat 1 çıktısındaki st kolonu steal zamanını saniye bazında gösterir.

Sahada gördüğümüz tipik senaryolar şöyle:

• Normal durumda %steal değeri genelde 0–1% civarında seyreder.
• Kısa süreli 5–10% sıçramalar anlık yoğunluklarda yaşanabilir, çoğu zaman tolere edilebilir.
• Sürekli veya sık sık 20%+ seviyelerinde steal görmek, noisy neighbor veya host tarafında ciddi kapasite baskısı yaşandığına işaret eder.

Önemli nokta, steal değerine tek bir anlık bakmak yerine zaman serisi olarak izlemektir. Bu konuda adım adım komut örnekleriyle ilerlemek isterseniz, VPS kaynak kullanımını htop, iotop, Netdata ve Prometheus ile izlemeye yönelik rehberimize göz atabilirsiniz.

Uygulama Seviyesinde Noisy Neighbor Belirtileri

CPU steal değerlerini toplamak önemli, ancak çoğu ekip sorunu önce uygulama davranışı üzerinden fark eder. Noisy neighbor ve yüksek steal time genellikle şu belirtilerle kendini gösterir:

• Belirli saatlerde yavaşlayan web sitesi: Trafik seviyesi aynı olduğu hâlde örneğin her gün 11:00–13:00 arası TTFB ve sayfa yüklenme süreleri artıyorsa.
• Cron job’ların uzaması: Normalde 1–2 dakika süren rapor oluşturma işleri arada 10 dakikaya kadar çıkıyorsa.
• Kuyruk işlerinin birikmesi: Queue worker’larınızın CPU kullanımı düşük görünmesine rağmen, iş kuyruğunda bekleyen görev sayısı hızla artıyorsa.
• Veritabanı sorgu sürelerinde düzensiz artış: Aynı sorgular aynı veritabanı planı ile bazen 20 ms, bazen 500 ms sürüyorsa.

Bu semptomlar sadece noisy neighbor kaynaklı olmayabilir; disk IO veya veritabanı optimizasyon problemleri de benzer etki yaratır. Özellikle “günün belli saatlerinde” yaşanan dalgalanmaları analiz etmek için, belirli saatlerde yavaşlayan siteler için CPU, IO ve MySQL darboğazı teşhisi rehberimize mutlaka göz atmanızı öneririz.

Uzun Vadeli İzleme ve Trend Analizi

Noisy neighbor sorununu bir defalık ölçümlerle yakalamak her zaman mümkün olmayabilir. En sağlıklı yaklaşım, CPU steal dahil tüm temel metrikleri 24/7 izleyip grafiklemektir. Bunun için:

• Node Exporter + Prometheus ile CPU, memory, disk ve network metriklerini toplayabilir,
• Grafana ile %steal, load average, response time gibi değerlerin zaman içindeki seyrini görebilir,
• Uptime Kuma veya benzeri araçlarla uçtan uca HTTP yanıt süresini takip edebilirsiniz.

Steal grafiği ile HTTP response time grafiğini üst üste koyduğunuzda, belirli zamanlarda paralel yükselişler görüyorsanız, noisy neighbor şüphesi güçlenir. Bu tür bir izleme altyapısını sıfırdan kurmak istiyorsanız, Prometheus, Grafana ve Uptime Kuma ile VPS izleme ve alarm kurulumunu anlattığımız yazıya adım adım bakabilirsiniz.

Noisy Neighbor ile Karıştırılan Diğer Performans Sorunları

Sahada sıkça gördüğümüz bir hata, her performans dalgalanmasını “kesin noisy neighbor” diyerek açıklamaya çalışmaktır. Oysa çoğu zaman problem bambaşka katmanlardadır. Özellikle şu üç başlıkla CPU steal’i karıştırmamak önemli:

Disk IO Darboğazları

Veritabanı veya dosya odaklı uygulamalarda, disk IO gecikmesi (latency) arttığında CPU kullanımı düşük kalsa da uygulama hissedilir şekilde yavaşlar. Bu durumda iostat, iotop ve veritabanı slow query log’ları size daha net sinyal verir. IO problemi yaşıyorsanız:

• Steal time genelde düşük kalır,
• Disk bekleme süresi (await) ve queue depth yükselir,
• CPU “boşta” görünür ama istekler yavaş döner.

Böyle durumlarda öncelikle disk tarafını teşhis etmek, gerekirse NVMe diskli planlara veya uygun depolama mimarisine geçmek daha doğru bir adımdır.

RAM Yetersizliği ve Swap Kullanımı

Uygulamanız RAM’i doldurup swap kullanmaya başladığında, CPU steal olmasa bile sistem genel olarak ağırlaşır. Özellikle PHP-FPM, Node.js veya Java tabanlı uygulamalarda bellek kullanımını iyi yönetmek kritik. Bu minvalde, swap ve OOM killer davranışlarını anlamak için VPS’te RAM, swap ve OOM killer yönetimi rehberimize bakabilirsiniz.

RAM kaynaklı yavaşlamalarda tipik belirtiler:

• free -m ve vmstat çıktısında yoğun swap kullanımı,
• dmesg içinde Out of memory: Kill process log’ları,
• Steal % genelde düşük, fakat load average yüksek seyredebilir.

Uygulama ve Veritabanı Optimizasyon Eksiklikleri

İyi optimize edilmemiş sorgular, gereksiz büyük objeleri RAM’e alan kodlar veya yanlış yapılandırılmış PHP-FPM havuzları, CPU steal olmasa da yüksek load ve yavaş yanıt sürelerine yol açabilir. Özellikle WordPress, WooCommerce ve benzeri PHP uygulamalarında:

• OPcache ve object cache (Redis/Memcached) kullanımı,
• Doğru PHP-FPM pm ve pm.max_children değerleri,
• Veritabanı indeksleme ve sorgu optimizasyonu

gibi başlıklar doğrudan performansı etkiler. Bu konuları sistematik biçimde ele almak için, WordPress için sunucu tarafı optimizasyon rehberimize göz atabilirsiniz.

Noisy Neighbor Etkisini Azaltmak İçin Uygulama Tarafı Stratejiler

Noisy neighbor tamamen altyapı kaynaklı bir konu gibi görünse de, uygulama mimarisini doğru kurarak bu etkinin hissedilirliğini ciddi ölçüde azaltabilirsiniz. Özellikle CPU steal anlarında “zarifçe yavaşlayan” ve kuyruklarını patlatmayan sistemler tasarlamak mümkün.

Önbellekleme ile CPU Yükünü Hafifletmek

CPU steal anlarında en büyük avantajınız, işlemciye binen yükü zaten düşük tutuyor olmanızdır. Bunun için:

• Statik içerikler ve HTML sayfalar için reverse proxy veya tam sayfa cache (Nginx micro-caching, Varnish, LiteSpeed Cache vb.) kullanın.
• Veritabanı ile sık konuşan kodlar için Redis/Memcached tabanlı object cache kurun.
• Yoğun raporlama veya filtreli listeleme sayfalarında, sonuçları belirli aralıklarla cache edip, her istekte yeniden hesaplamayın.

Böylece altyapı tarafında kısa süreli steal artışları yaşansa bile, kullanıcılar büyük oranda cache’den servis edildiği için hissedilen yavaşlama minimumda kalır.

Arka Plan İşleri ve Kuyruk Mimarisini Doğru Kurmak

CPU steal sorunları, zamanlamaya bağlı işler ve queue mimarilerinde daha acı verici hissedilir. Örneğin:

• Yoğun bir e-posta kampanyasını her gece 02:00’de tek bir VPS üzerinden göndermek,
• CPU ağır rapor hesaplarını senkron çalıştırmak,
• Video veya görsel işleme gibi CPU yoğun işleri web isteği sırasında yapmak.

Bu noktada yapılması gereken, bu iş yüklerini arka plan kuyruklarına taşımak ve mümkünse ayrı worker süreçleriyle yönetmektir. Laravel Queue, Supervisor, systemd veya PM2 gibi araçlarla pratik bir işçi mimarisi kurmak için, arka plan işleri ve kuyruk yönetimi rehberimizden yararlanabilirsiniz.

Steal değerleri yükseldiğinde kuyruk işçileri biraz yavaşlayabilir ama:

• Kritik kullanıcı istekleri bloklanmaz,
• Zamanla kuyruk tekrar boşalır,
• Performans dalgalanması daha yönetilebilir hâle gelir.

Kaynak Limitleri, Process İzolasyonu ve Docker/cgroups Kullanımı

Aynı VPS üzerinde birden fazla uygulama çalıştırıyorsanız, noisy neighbor etkisi sadece fiziksel hosttan değil, kendi iç servislerinizden de gelebilir. Örneğin yanlış yapılandırılmış bir arka plan worker’ı kendi VPS’iniz içinde diğer uygulamalarınız için noisy neighbor rolü üstlenebilir.

Bunu engellemek için:

• Docker veya systemd slice’ları üzerinden CPU ve RAM limitleri tanımlayın.
• Her proje için ayrı PHP-FPM havuzu, ayrı user ve gerekirse ayrı container kullanın.
• CPU yoğun batch işleri için nice ve ionice ile öncelik düşürün.

Böylece hem fiziksel host seviyesindeki noisy neighbor etkisini daha az hisseder, hem de kendi VPS’inizde projeler arası kaynak çekişmesini sınırlamış olursunuz.

Altyapı ve Planlama Tarafında Çözümler

Uygulama tarafında yapabileceklerinizi yaptıktan sonra hâlâ yüksek ve kalıcı CPU steal yaşıyorsanız, artık iş altyapı ve kapasite planlama tarafına kayar. Burada yapılabilecekleri üç başlıkta özetleyebiliriz.

vCPU Türü ve Plan Seçimini Gözden Geçirmek

VPS dünyasında her vCPU aynı değildir. Genel olarak:

• Paylaşımlı vCPU: Aynı fiziksel çekirdek birden fazla VPS’e paylaştırılır. Doğru oranlarla yapıldığında maliyet/performans dengesi iyidir ancak noisy neighbor riski daha yüksektir.
• Dedicated vCPU / pinned core: Fiziksel çekirdeğin belirli bir kısmı veya tamamı sadece sizin VPS’inize ayrılır. Noisy neighbor riski ciddi şekilde azalır, maliyet yükselir.

DCHost tarafında, CPU yoğun iş yükleri için müşterilerle yaptığımız değerlendirmelerde genellikle şu yolu izliyoruz:

• Önce 1–2 haftalık detaylı metrik toplayıp gerçek CPU kullanım desenini çıkarıyoruz.
• Kalıcı yüksek steal görülüyorsa, önce aynı veri merkezinde farklı fiziksel hosta taşıma gibi altyapısal iyileştirmeleri deniyoruz.
• İş yükü gerçekten CPU ağırlıklıysa (örneğin video işleme, raporlama, ML inferencing), dedicated vCPU veya gerekirse dedicated sunucu tarafına geçmeyi masaya yatırıyoruz.

Yatay Ölçekleme ve İş Yükü Ayrıştırma

Tek bir büyük VPS üzerinde her şeyi çalıştırmak yerine, iş yükünü mantıklı parçalara bölmek hem noisy neighbor etkisini hem de genel riskleri azaltır. Örneğin:

• Web sunucusu + PHP-FPM
• Veritabanı sunucusu
• Queue/worker sunucusu

şeklinde üç VPS’lik bir mimari, tek büyük VPS’e göre daha öngörülebilir davranır. Bir node üzerinde geçici noisy neighbor etkisi yaşansa bile, diğer bileşenler ayakta kalır ve toplam deneyim daha stabil olur.

DCHost üzerinde bu tür ölçeklendirmelerde, veritabanı ve queue gibi bileşenleri ayrı VPS’lere almak ve gerektiğinde bunları dedicated sunucu veya colocation tarafına taşımak, sık kullandığımız bir yol haritasıdır.

Altyapı Sağlayıcınızla Şeffaf İletişim

Noisy neighbor ve CPU steal tamamen sizin kontrolünüzde olmayan, hipervizör ve fiziksel host katmanında ortaya çıkan problemler olduğu için, bir noktadan sonra hosting sağlayıcınızla birlikte hareket etmek zorundasınız. Sağlıklı bir süreç için:

• Topladığınız %steal grafikleri, load average, response time ve log’ları destek talebine ekleyin.
• “Şu saatler arası şu pattern’i görüyorum” diyerek somut örnekler verin.
• Gerektiğinde VPS’inizi farklı bir fiziksel hosta taşıma, planınızı dedicated vCPU’ya yükseltme gibi opsiyonları beraber değerlendirin.

DCHost ekibi olarak, müşterilerimizden bu tarz detaylı metrik geldiğinde fiziksel host tarafında da kontroller yapıyor, gerektiğinde gürültü yapan VPS’leri kısıtlama veya farklı hostlara taşıma gibi aksiyonlarla noisy neighbor etkisini minimumda tutuyoruz.

DCHost Altyapısında Noisy Neighbor Riskini Nasıl Minimize Ediyoruz?

Noisy neighbor tamamen yok edilebilen bir olgu değil; ancak doğru mimari ve politika setiyle pratikte fark edilmeyecek seviyelere indirilebilir. DCHost tarafında bu konuda uyguladığımız başlıca yaklaşımlar şunlar:

• Dengeli overcommit oranları: Fiziksel host başına vCPU ve RAM overcommit oranlarını agresif tutmuyor, yoğun iş yüklerini daha baştan uygun host gruplarına yerleştiriyoruz.
• Proaktif izleme: Fiziksel host seviyesinde de CPU, IO ve network metriklerini izleyerek “host bazlı” anomalileri yakalıyor, daha müşteri şikâyet etmeden aksiyon alıyoruz.
• Kaynak ihlali yapan VPS’ler için politikalar: Sürekli limit üstü CPU veya IO tüketen VPS’leri otomatik kurallarla tespit ediyor, önce bilgilendiriyor, gerekirse throttle veya taşıma uyguluyoruz.
• Dedicated vCPU ve dedicated sunucu opsiyonları: Gürültüye hassas, gerçek zamanlı veya finansal sistemler için doğrudan izole kaynak sunan mimariler öneriyoruz.
• Colocation seçeneği: Bazı müşteriler kendi donanımlarını getirerek tamamen kendilerine ait fiziksel sunucularda çalışmayı tercih ediyor; biz de veri merkezi, ağ ve operasyonel katmanı sağlıyoruz.

Bütün bunların üzerine, müşterilerimizin VPS’lerinde detaylı metrik toplamalarını ve düzenli sağlık kontrolleri yapmalarını teşvik ediyoruz. Monitoring tarafını sağlam kurduğunuzda, noisy neighbor ve CPU steal gibi konuları sezgiyle değil, veriyle konuşma imkânınız oluyor.

Özet: Noisy Neighbor ile Yaşamak Zorunda Değilsiniz

Noisy neighbor ve CPU steal, sanallaştırılmış altyapıların doğasında var ama bu, performans dalgalanmalarını “kader” olarak kabulleneceğiniz anlamına gelmiyor. Doğru metrikleri izleyerek, uygulama mimarinizi güçlendirerek ve altyapı sağlayıcınızla veri odaklı iletişim kurarak bu etkiyi pratikte görünmez seviyeye indirebilirsiniz.

Öncelikle VPS’inizde %steal değerlerini, load average’i ve uygulama yanıt sürelerini düzenli olarak takip edin. Disk IO, RAM ve uygulama taraflı sorunları eleyip gerçekten noisy neighbor şüphesi kaldığında, somut grafiklerle birlikte bizimle iletişime geçin. DCHost olarak; gerek aynı veri merkezi içinde farklı hostlara taşıma, gerekse dedicated vCPU, dedicated sunucu veya colocation gibi daha izole çözümlere geçişte size adım adım yol haritası çıkarabiliriz.

Altyapınızı gözden geçirmek, monitoring kurmak veya mevcut VPS’inizde noisy neighbor olasılığını birlikte değerlendirmek isterseniz, DCHost ekibine her zaman ulaşabilirsiniz. Metriklere dayalı net bir tablo çıkardıktan sonra, performansınızı istikrarlı hâle getirmek için en uygun mimariyi birlikte tasarlayalım.