Ana içeriğe geç

Tahmine Dayanmadan Sunucu Yükü Nasıl İzlenir

· 5 dakikalık okuma
Customer Care Engineer

14 Temmuz 2026 tarihinde yayımlandı

Tahmine Dayanmadan Sunucu Yükü Nasıl İzlenir

Yoğun bir site zaman aşımına uğramaya başlamadan önce sunucu nadiren kibar bir uyarı gönderir. Daha sık olarak, biri yavaş bir WordPress panosunu fark eder, bir ödeme sayfası takılır veya e-posta teslimi gecikmeye başlar. Sunucu yükünü nasıl izleyeceğinizi bilmek, ziyaretçileriniz fark etmeden önce baskının arttığını görme şansı verir.

Sunucu yükü, şöyle bir bakıp unutacağınız tek bir sayı değildir. CPU talebi, kullanılabilir bellek, disk etkinliği, ağ trafiği ve dikkat için rekabet eden süreçlerden oluşan bir tablodur. Bu sinyalleri birlikte okursanız, normal bir trafik artışı ile yardıma ihtiyaç duyan bir sunucu arasındaki farkı anlayabilirsiniz.

Sunucu yükü gerçekte neyi ölçer?

Linux'ta load average, CPU üzerinde çalışmaya hazır olan veya kesilemeyen bir durumda bekleyen görevlerin sayısını ölçer; bunun nedeni çoğu zaman disk G/Ç'si bekliyor olmalarıdır. Genellikle son 1, 5 ve 15 dakikadaki ortalama yükü temsil eden üç değer görürsünüz.

`0.60, 0.80, 1.20` gibi bir gösterim otomatik olarak iyi ya da kötü değildir. Anlamlı karşılaştırma, yük ile sunucuda kullanılabilir CPU çekirdeği sayısı arasındadır. Tek CPU çekirdeğine sahip bir sunucuda, kalıcı olarak 1.00 yük değeri çekirdeğin tamamen meşgul olduğu anlamına gelir. Dört çekirdekli bir sunucuda ise 1.00 yük genellikle rahattır, çünkü hâlâ kullanılabilir kapasite vardır.

Bu kuralın bile bir istisnası vardır. Düşük CPU kullanımıyla birlikte yüksek bir load average, işlemci baskısından ziyade disk beklemelerine işaret edebilir. Bu yüzden yalnızca load average izlemek sizi yanlış yöne götürebilir. Bir sayı size işlerin beklediğini söyler. Çevresindeki metrikler ise nedenini söyler.

Sunucu yükü doğru yerlerde nasıl izlenir?

Mevcut etkinliği ve son eğilimleri kontrol etmenizi sağlayan bir izleme görünümüyle başlayın. Gerçek zamanlı veriler bir olay sırasında yardımcı olurken, geçmiş grafikler daha faydalı soruya yanıt verir: bu bir kez mi oldu, yoksa her gün saat 14:00'te mi oluyor?

Gerçek zamanlı sunucu izleme sunan bir kontrol paneli, gün boyu terminali açık tutmak istemeyen site sahipleri ve ekipler için bunu kolaylaştırır. FASTPANEL'de sunucu kaynakları, onları kullanan web siteleri ve hesaplarla birlikte görüntülenebilir; bu da tek bir proje payından fazlasını tüketmeye başladığında dedektiflik işini azaltır.

Linux'ta daha yakından incelemek için, alışıldık komutlar hâlâ mükemmel iş çıkarır. `uptime` load average değerlerini hızlıca gösterir. `top` veya `htop` şu anda CPU ve belleği kullanan süreçleri gösterir. `free -m` bellek ve swap kullanımını değerlendirmenize yardımcı olurken, `df -h` dolu bir dosya sisteminin soruna katkıda bulunup bulunmadığını gösterir. Disk etkinliği için, kuruluysa `iostat` ve `iotop` faydalıdır.

En iyi kurulum her iki yaklaşımı da kullanır: günlük görünürlük için net bir pano ve belirli bir süreci, sorguyu, yedekleme işini veya trafik olayını incelemeniz gerektiğinde komut satırı kontrolleri.

Bu sinyalleri birlikte izleyin

Bir sunucu izleme ekranı açtığınızda, birbiriyle bağlantılı şu sinyallere odaklanın:

  • CPU kullanımı ve load average süreçlerin işlemci zamanı için rekabet edip etmediğini gösterir.
  • Bellek kullanımı ve swap etkinliği sunucunun RAM bakımından yetersiz kalıp kalmadığını ve verileri daha yavaş disk depolamaya taşıyıp taşımadığını ortaya koyar.
  • Disk alanı, G/Ç beklemesi ve disk aktarım hızı dolu diskleri veya okuma ve yazma işlemlerine yetişemeyen depolamayı belirler.
  • Ağ trafiği ve bağlantı sayıları meşru talebin, botların veya bir trafik artışının web hizmetleri üzerinde baskı oluşturup oluşturmadığını gösterir.
  • En yoğun süreçler etkinliğin arkasında hangi hizmetin, kullanıcının, web sitesinin veya zamanlanmış işin olduğunu ortaya çıkarır.

Bir ürün lansmanı sırasında yüksek CPU yüzdesi beklenen bir durum olabilir. CPU kullanımı düşük kalırken yüksek G/Ç beklemesi ise farklı bir hikâyedir; çoğu zaman yedeklemeleri, veritabanı işlemlerini, günlük döndürmeyi veya aşırı yüklenmiş bir depolama birimini içerir. Amaç kırmızı bir çizgide paniğe kapılmak değildir. Amaç darboğazı bulmaktır.

Önce normal bir temel seviye oluşturun

Faydalı uyarılar, sunucunuz için normalin nasıl göründüğünü bilmeye bağlıdır. Küçük bir işletme web sitesi günün büyük bölümünde sakin olabilir ve zamanlanmış bir içe aktarma sırasında zirve yapabilir. Bir hosting sağlayıcısı onlarca hesapta istikrarlı etkinliğe sahip olabilir. Yoğun bir ajans sunucusu, istemci kampanyaları yayına girdiğinde öngörülebilir zirveler görebilir.

Her artışı bir olay olarak değerlendirmeden önce en az iki ila dört haftalık veriyi takip edin. Yük, CPU, bellek, disk G/Ç'si ve trafikteki kalıpları arayın. Bu kalıpları bilinen olaylarla eşleştirin: yedeklemeler, cron işleri, eklenti güncellemeleri, raporlama görevleri veya ziyaretçi trafiğinin zirve saatleri.

Bu temel seviye iki yaygın hatayı önler. İlki, uyarıları arka plan gürültüsüne dönüşecek kadar düşük ayarlamaktır. İkincisi ise tekrarlayan bir yavaşlamayı sıradanlaştığı için kabullenmektir. Yük her gece dört çekirdekli bir sunucuda 6'ya ulaşıyor ve siteler hızlı kalıyorsa, bu yönetilebilir olabilir. Aynı kalıp yavaş veritabanı sorguları ve artan yanıt süreleriyle çakışıyorsa, dikkat gerektirir.

Eyleme götüren uyarılar ayarlayın

Bir uyarı, yalnızca bir sunucunun var olduğunu duyurmamalı; birinin belirli bir durumu incelemesini söylemelidir. Eşikleri yalnızca değere göre değil, süreye göre de ayarlayın. Kısa süreli bir CPU sıçraması normaldir. CPU'nun 15 dakika boyunca %90'ın üzerinde olması daha bilgilendiricidir. Aynı ilke bellek, disk kullanımı ve load average için de geçerlidir.

CPU çekirdeklerine göre kalıcı yüksek yük, yüksek CPU kullanımı, düşük kullanılabilir bellek, etkin swap artışı, yüksek disk G/Ç beklemesi ve kapasiteye yaklaşan diskler için uyarı kuralları kullanın. Disk alanı, çoğu ekibin beklediğinden daha erken bir uyarıyı hak eder. Bir birim %100 dolana kadar beklemek, basit bir temizliği hizmet kesintisine dönüştürür.

Mümkün olduğunda uyarıya bağlam ekleyin: etkilenen sunucu, mevcut yük, bellek durumu, disk kullanımı ve koşulun başladığı zaman. Uyarılar bağlam olmadan gelirse, insanlar ilk on dakikayı uyarının ne anlama geldiğini anlamaya çalışarak geçirir. Bu izleme değildir. Bu, yönetsel kardiyodur.

Tahmin yürütmeden yüksek yükü inceleyin

Yük arttığında, kanıta giden en kısa yoldan başlayın. CPU kullanımının da yüksek olup olmadığını kontrol edin. Öyleyse, çalışan süreçleri CPU kullanımına göre sıralayın ve sorumlu hizmeti belirleyin. Web sunucusu çalışanları, PHP süreçleri, veritabanı sorguları, kötü amaçlı yazılım taramaları ve kötü zamanlanmış cron işleri yaygın kaynaklardır.

Yük yüksek ama CPU kullanımı değilse, G/Ç beklemesini ve disk etkinliğini kontrol edin. Çok sayıda dosya yazan bir yedekleme, bir dizini yeniden oluşturan veritabanı veya neredeyse dolu bir disk, CPU kapasitesi mevcut olsa bile süreçleri beklemede bırakabilir. Dosya sistemi alanını kontrol edin, son zamanlanmış görevleri gözden geçirin ve alışılmadık derecede yoğun okuma veya yazma etkinliği arayın.

Ardından belleği kontrol edin. Düşük kullanılabilir RAM ve kalıcı swap kullanımı, sunucu bellek sayfalarını sürekli olarak diske taşıdığı ve diskten geri aldığı için her hizmeti yavaş hissettirebilir. Bir hizmeti yeniden başlatmak kısa bir nefes aldırabilir, ancak daha fazla belleğe ihtiyaç duyan bir uygulamayı, kontrolden çıkmış bir süreci veya iş yükü için basitçe çok küçük olan bir sunucuyu düzeltmez.

Son olarak, trafiğe ve bağlantılara bakın. Ani bir artış, başarılı bir kampanya gibi iyi haber olabilir ya da oturum açma sayfalarına saldıran agresif botlar gibi daha az hoş bir durum olabilir. Web erişim günlükleri, bağlantı sayıları ve site başına kaynak görünümleri, gerçek ziyaretçi talebini istenmeyen gürültüden ayırmaya yardımcı olur.

Grafiği değil, nedeni düzeltin

Doğru yanıt darboğaza bağlıdır. CPU baskısı için maliyetli uygulama kodunu optimize edin, tekrarlanan işleri önbelleğe alın, PHP worker'larını ayarlayın veya tekrarlayan işleri yoğun saatlerin dışına taşıyın. Veritabanı baskısı için, daha fazla sunucu kaynağı eklemeden önce yavaş sorguları, eksik indeksleri ve bağlantı sınırlarını inceleyin.

Diskle ilgili baskı için gereksiz dosyaları temizleyin, yedeklemelerin ziyaretçi trafiğiyle rekabet etmediğini doğrulayın ve iş yükü gerektiriyorsa daha hızlı depolama kullanın. Bellek baskısı için savurgan hizmetleri azaltın, uygulama sınırlarını dikkatle ayarlayın veya RAM'i artırın. Ölçeği büyütmek doğru adım olabilir, ancak bunun hayal kırıklığından değil kanıttan sonra gelmesi gerekir.

Ayrıca paylaşımlı veya çok siteli sunucularda hesap yalıtımını da göz önünde bulundurun. Kötü optimize edilmiş tek bir web sitesinin, diğer tüm siteleri yavaş bir özre dönüştürmesine izin verilmemelidir. Hesap başına görünürlük, kaynağı belirlemeyi ve gerektiğinde adil sınırlar koymayı çok daha kolay hâle getirir.

Düzeltmeden sonra da izlemeyi sürdürün

Bir değişiklik yaptıktan sonra, sonraki yoğun dönemde aynı metrikleri izleyin. Daha düşük bir load average cesaret vericidir, ancak yanıt süreleri, hata oranları ve kullanıcı deneyimi de önemlidir. Sunucu daha sakin görünebilir, ancak bir veritabanı kuyruğu veya uygulama hatası devam ediyor olabilir.

İyi izleme, grafiklere bakıp kalmaktan çok güven oluşturmaktır: normalin nasıl göründüğünü bilirsiniz, faydalı uyarılar alırsınız ve bir şey yaratıcı davranmaya başladığında net bir sonraki adımınız olur. Sunucu yönetimi işte bu şekilde web sitelerini çalıştırmanın rutin bir parçası olur; akşamınızın kaybolma nedeni değil.