Sunucunuz ne kadar doluluk seviyesinde? Ölçüm adımları ve yorumlama.
"Sunucumuz yeterli mi?" sorusunun cevabı tahminle değil ölçümle verilir. Bu yazı, teknik olmayan bir yöneticinin de yorumlayabileceği bir ölçüm çerçevesi sunar.
Başlamadan önce
- Sunucu izleme aracına erişim (yoksa kurulmalı)
- En az bir aylık geçmiş veri
- Sonuçları kaydedeceğiniz bir tablo
1. Adım — Neyi ölçeceğinizi belirleyin
| Ölçüm | Ne gösterir | Dikkat eşiği |
|---|---|---|
| İşlemci kullanımı | Hesaplama yükü | Sürekli yüksekse |
| Bellek kullanımı | Çalışan işlemlerin alanı | Doluluk yükseldiğinde |
| Disk doluluğu | Kalan alan | Belirli bir oranın üstü |
| Disk işlem hızı | Depolama darboğazı | Bekleme süresi artınca |
| Ağ kullanımı | Trafik yoğunluğu | Kapasiteye yaklaşınca |
| Yük ortalaması | Genel meşguliyet | Çekirdek sayısını aşınca |
| Yanıt süresi | Kullanıcı deneyimi | Artış eğilimi varsa |
Not: Kesin eşik değerleri iş yüküne göre değişir; asıl bakılacak olan eğilimdir.
2. Adım — Doğru zaman aralığında ölçün
- ☐ En az bir ay veri toplayın
- ☐ Günlük yoğun saatleri belirleyin
- ☐ Haftalık örüntüyü inceleyin
- ☐ Ay sonu/dönem sonu yüklerini görün
- ☐ Kampanya dönemlerini ayrı değerlendirin
Kritik: Ortalama değerler yanıltır. Bir sunucu günün büyük kısmında boş, iki saatte tıkanık olabilir; ortalama "her şey yolunda" der.
3. Adım — Zirve yükü belirleyin
Kapasite planlaması zirveye göre yapılır:
- Günün en yoğun saatinde kullanım ne?
- Haftanın en yoğun günü ne?
- Ayın en yoğun dönemi ne?
- Yılın en yoğun günü ne?
4. Adım — Darboğazı bulun
Bir sunucuda genelde tek bir bileşen darboğaz oluşturur. Belirtiler:
| Belirti | Muhtemel darboğaz |
|---|---|
| İşlemci sürekli yüksek | İşlemci |
| Bellek dolu, takas kullanılıyor | Bellek |
| Disk bekleme süresi yüksek | Disk hızı |
| Ağ kapasitesi dolu | Bant genişliği |
| Hepsi düşük ama yavaş | Uygulama ya da veritabanı |
Son satır önemlidir: Kaynaklar boşken sistem yavaşsa, sorun donanımda değil yazılımdadır ve sunucu büyütmek çözmez.
5. Adım — Eğilimi çıkarın
- ☐ Son altı ayda kullanım nasıl değişti?
- ☐ Artış hızı ne?
- ☐ Bu hızla devam ederse ne zaman limite ulaşılır?
- ☐ Planlanan yeni yükler var mı?
Bu hesap, ne zaman büyütmeniz gerektiğini önceden gösterir — kriz anında değil, planlı biçimde.
6. Adım — Uyarı eşikleri tanımlayın
- ☐ Disk doluluğu için uyarı
- ☐ Bellek kullanımı için uyarı
- ☐ İşlemci sürekli yüksekse uyarı
- ☐ Yanıt süresi artışı için uyarı
- ☐ Servis durursa uyarı
- ☐ Uyarılar doğru kişilere gidiyor
Uyarı eşiklerini limitin epey altında tutun; müdahale için zaman kazandırır.
7. Adım — Raporlayın
Aylık bir özet hazırlayın:
- Ortalama ve zirve kullanım
- Limitlere yaklaşan bileşenler
- Eğilim ve tahmin
- Yaşanan olaylar
- Öneri (büyütme, optimizasyon, değişiklik yok)
Yorumlama rehberi
| Durum | Yorum | Yapılacak |
|---|---|---|
| Tüm kaynaklar düşük | Kapasite fazla | Küçültmeyi değerlendirin |
| Bir kaynak zirvede | Darboğaz | O bileşeni artırın ya da optimize edin |
| Zirve saatlerde tıkanma | Kapasite sınırda | Optimizasyon, sonra büyütme |
| Sürekli tıkanma | Yetersiz | Acil büyütme |
| Kaynak boş, sistem yavaş | Yazılım sorunu | Uygulama incelemesi |
| Ani sıçrama | Anormallik | Güvenlik kontrolü |
Son satır atlanmamalı: açıklanamayan bir kaynak artışı, bir güvenlik olayının ilk işareti olabilir.
Büyütmeden önce
Kaynak artırmadan önce şunları değerlendirin:
- Uygulama tarafında iyileştirme mümkün mü?
- Veritabanı sorguları optimize edilebilir mi?
- Önbellek kullanılıyor mu?
- Gereksiz servisler kapatılabilir mi?
- Kullanılmayan veriler temizlenebilir mi?
- Roller ayrı sunuculara dağıtılabilir mi?
Bu adımlar çoğu zaman büyütme ihtiyacını erteler ve kalıcı maliyet artışını önler.
Yorumlar (0)
Henüz yorum yok — ilk yorumu siz yazın.
Yorum yaz