Sunucu yavaşlaması ve yüksek trafik hataları: nedenleri, teşhis komutları ve çözüm yolları

Sunucu yavaşladığında ilk tepki genellikle "daha güçlü sunucu alalım" olur. Oysa yavaşlığın kaynağı işlemci, bellek, disk, ağ ya da ani bir trafik artışı olabilir ve her birinin çözümü farklıdır. Yanlış teşhisle alınan ek kaynak çoğu zaman sorunu çözmez, yalnızca faturayı büyütür.

Bu rehberde önce yavaşlamanın ana kaynaklarını tanıyacak, ardından Linux'ta top, vmstat ve iostat, Windows Server'da ise typeperf ile hangi kaynağın tıkandığını ölçeceksiniz. Son bölümlerde yüksek trafik sorununu ele alıyoruz: meşru ziyaretçi artışını DDoS saldırısından ayırma, dikey ve yatay ölçekleme, yük dengeleme ve önbellek.

Sunucu yavaşlamasının ana kaynakları

Yavaşlık hissi kullanıcı tarafında tek bir belirti gibi görünür: sayfa geç açılır, uygulama donar, muhasebe programı kayıt eklerken bekler. Arka planda ise genellikle şu kaynaklardan biri ya da birkaçı sınırına dayanmıştır:

• İşlemci (CPU): Çalışmak isteyen süreç sayısı çekirdek sayısını sürekli aşıyorsa işler sıraya girer. Verimsiz bir sorgu, sonsuz döngüye giren bir betik ya da sıkıştırma ve şifreleme gibi yoğun işler buna yol açar.
• Bellek (RAM): Bellek yetmediğinde işletim sistemi verileri diske takas eder (swap). Disk, bellekten kat kat yavaş olduğu için sistem bir anda ağırlaşır.
• Disk G/Ç: Veritabanı, günlük yazımı, yedekleme ya da antivirüs taraması diski meşgul ettiğinde süreçler okuma ve yazma işleminin bitmesini bekler. CPU boşta görünse bile sistem yavaştır.
• Ağ: Bant genişliğinin dolması, paket kaybı ya da sunucu ile kullanıcı arasındaki yüksek gecikme yanıt süresini uzatır.
• Yazılım ve yapılandırma: Güncellenmemiş yazılımlardaki hatalar, düşük bırakılmış bağlantı sınırları, indekssiz veritabanı tabloları ya da tek iş parçacığıyla çalışan bir uygulama, donanım yeterli olsa bile darboğaz yaratır.
• Yüksek trafik: Kampanya, haber ya da sezon etkisiyle gelen gerçek ziyaretçiler veya kötü niyetli bir saldırı, yukarıdaki kaynakların hepsini aynı anda zorlayabilir.

Hangisinin sorumlu olduğunu tahminle değil ölçümle bulmak gerekir. Aşağıdaki komutlar bu ölçümü birkaç dakikada yapmanızı sağlar.

Linux'ta teşhis: top, vmstat ve iostat

Ölçümü sorun yaşanırken yapın. Sistem sakinken alınan değerler size yalnızca normal durumu gösterir; bu da karşılaştırma için faydalıdır, o yüzden ikisini de not edin.

top ile ilk bakış

top

Özet satırındaki load average üç değer gösterir: son 1, 5 ve 15 dakikanın yük ortalaması. Bu değerleri çekirdek sayınızla karşılaştırın (nproc komutu çekirdek sayısını verir). Dört çekirdekli bir sunucuda yük sürekli 4'ün çok üzerindeyse işler sıraya giriyordur. Üç değerin sıralaması da bilgi verir: 1 dakikalık değer 15 dakikalıktan çok yüksekse sorun yeni başlamıştır.

CPU satırında iki alan özellikle önemlidir:

• wa: İşlemcinin G/Ç işleminin bitmesini beklerken geçirdiği süre. Yüksekse sorun büyük olasılıkla CPU değil, disktir.
• st (steal): Hipervizörün bu sanal makineden alıp başka işlere verdiği süre. Sanal sunucuda st değeri sürekli yüksekse, sanal makineniz ihtiyaç duyduğu işlemci zamanını alamıyordur. Bu alan çekirdek sürümüne göre görünmeyebilir.

top açıkken P tuşu süreçleri CPU kullanımına, M tuşu bellek kullanımına göre sıralar. En üstteki süreç çoğu zaman suçlunun adını verir.

vmstat ile bellek ve kuyruk

vmstat 1 10

Bu komut her saniye bir satır olmak üzere on ölçüm alır. İlk satır açılıştan bu yana ortalamadır, değerlendirmeyi sonraki satırlarla yapın.

• r: Çalışan ya da CPU sırası bekleyen süreç sayısı. Çekirdek sayısını sürekli aşıyorsa CPU yetersizdir.
• b: G/Ç bitmesini bekleyerek bloke olmuş süreç sayısı. Sıfırdan farklı ve kalıcıysa disk darboğazı vardır.
• si ve so: Saniyede diskten belleğe geri alınan ve diske takas edilen bellek miktarı. Bu iki değer düzenli olarak sıfırın üzerindeyse bellek yetmiyor demektir. Bu durumda önce belleği tüketen süreci bulun, sonra RAM artırımını düşünün.

Bellek durumunu daha okunur görmek için:

free -h

iostat ile disk gecikmesi

iostat çoğu dağıtımda sysstat paketiyle gelir.

# Debian ve Ubuntu
sudo apt install sysstat
# RHEL, AlmaLinux, Rocky
sudo dnf install sysstat

iostat -x 1 5

-x seçeneği genişletilmiş istatistikleri açar: r_await, w_await, aqu-sz ve %util gibi. Burada asıl bakılacak değer await türleridir: bir G/Ç isteğinin kuyrukta bekleme ve işlenme süresi dahil ortalama karşılanma süresi, milisaniye cinsinden. Normal zamandaki değerinizle karşılaştırın; sorun anında katlanarak artıyorsa disk yetişemiyordur.

%util değerine tek başına güvenmeyin. RAID dizileri ve modern SSD'ler istekleri paralel işlediği için %100 görünen bir aygıt hâlâ kapasitesinin altında çalışıyor olabilir. Kararı await ve kuyruk boyu (aqu-sz) ile birlikte verin.

Ağ ve bağlantı durumu

ss -s
ss -tn state syn-recv | wc -l

İlk komut bağlantı özetini, ikincisi yarım açık (SYN_RECV) bağlantı sayısını verir. Bu sayı normalde düşüktür; aniden binlere çıkıyorsa aşağıdaki DDoS bölümüne bakın.

Windows Server'da teşhis: typeperf

Windows'ta Görev Yöneticisi ve Kaynak İzleyicisi hızlı bir bakış verir, ancak kayıt tutmak ve karşılaştırmak için komut satırındaki typeperf daha kullanışlıdır. Bu araç performans sayaçlarını komut penceresine ya da bir günlük dosyasına yazar. Varsayılan örnekleme aralığı bir saniyedir, varsayılan dosya biçimi CSV'dir ve Ctrl+C ile durdurulur.

typeperf "\Processor(_Total)\% Processor Time" "\System\Processor Queue Length" "\Memory\Available MBytes" "\Memory\Pages/sec" "\PhysicalDisk(_Total)\Avg. Disk sec/Transfer" -si 5 -sc 120 -o C:\perf\yavaslama.csv

Bu komut her 5 saniyede bir, toplam 120 ölçüm alır (yaklaşık 10 dakika) ve sonucu CSV dosyasına yazar. C:\perf klasörünün önceden var olduğundan emin olun. Linux karşılıklarıyla eşleştirirsek:

CSV dosyasını Excel'de açıp grafik çizmek, yavaşlamanın hangi saatte ve hangi kaynakla birlikte başladığını görmenin en kolay yoludur.

Yüksek trafik mi, DDoS saldırısı mı?

Kaynak ölçümleri sunucunun her yönden zorlandığını gösteriyorsa sıradaki soru, gelen trafiğin gerçek olup olmadığıdır. Çözüm buna göre tamamen değişir: gerçek ziyaretçi için kapasite artırılır, saldırı için filtreleme yapılır.

Meşru trafik artışının işaretleri

• Artış bir kampanya, e-posta gönderimi, reklam ya da medya haberiyle aynı zamana denk gelir.
• İstekler farklı sayfalara dağılır; ziyaretçiler ürün sayfası, sepet, ödeme gibi doğal bir yol izler.
• IP adresleri ve tarayıcı bilgileri çeşitlidir, coğrafi dağılım hedef kitlenizle uyumludur.
• Analitik aracınızda oturum ve dönüşüm sayıları da artmıştır.

Saldırı işaretleri

Microsoft, DDoS saldırılarını üç grupta inceler:

• Hacimsel saldırılar: UDP flood ya da amplification gibi yöntemlerle ağ bağlantısını yoğun trafikle boğar. Belirtisi, sunucu boşken bile bant genişliğinin dolmasıdır.
• Protokol saldırıları: Katman 3 ve 4'teki protokol zayıflıklarını kullanır; en bilineni SYN flood'dur. ss çıktısında SYN_RECV sayısının olağandışı artması tipik işarettir.
• Uygulama katmanı (katman 7) saldırıları: Normal görünen HTTP istekleriyle uygulamayı yorar. Slowloris, Slow Post, Slow Read ve HTTP(S) flood bu gruptandır. Bu saldırılara karşı ağ düzeyindeki DDoS korumasının yanında bir web uygulama güvenlik duvarı (WAF) gerekir.

Erişim günlüğünde en çok istek atan IP'leri ve en çok istenen adresleri görmek için (Nginx varsayılan günlük biçimi için):

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Az sayıda IP'nin binlerce istek atması, tek bir adrese (arama, giriş sayfası, xmlrpc gibi) yoğunlaşma ya da aynı tarayıcı bilgisinin tekrar etmesi saldırıya işaret eder. Windows tarafında SYN_RECEIVED birikmesiyle görülen bir örneği Windows sunucularda DNS kaynaklı SYN flood sorunu yazısında ayrıca ele aldık.

Kendinizi kilitlemeyin: Saldırgan IP'leri güvenlik duvarında engellemeden önce kendi yönetim IP'nize ve SSH ya da RDP portunuza izin veren kuralın yerinde olduğunu doğrulayın. Toplu engelleme kurallarını önce küçük bir listeyle deneyin; sağlayıcınızın konsol erişimini yedek yol olarak hazır tutun.

Yüksek trafikte çözüm: ölçekleme, yük dengeleme ve önbellek

Trafik gerçekse amaç, aynı donanımla daha çok isteği karşılamak ya da kapasiteyi büyütmektir. Önce ucuz ve hızlı adımlardan başlayın.

Önbellek: en ucuz kapasite

Her isteğin veritabanına kadar gitmesi, yüksek trafikte en sık görülen darboğazdır. Katman katman düşünün:

• Tarayıcı ve CDN önbelleği: Görsel, CSS ve JavaScript dosyaları için uygun önbellek başlıkları sunucuya gelen isteklerin önemli bir kısmını ortadan kaldırır.
• Sayfa önbelleği: Oturum açmamış ziyaretçilere aynı içeriği gösteren sayfalar (kategori, blog, ana sayfa) hazır HTML olarak sunulabilir. Varnish ya da Nginx'in kendi önbellek özelliği bu iş için kullanılır.
• Uygulama ve nesne önbelleği: Redis ya da Memcached, sık yapılan veritabanı sorgularının sonucunu bellekte tutar.
• Veritabanı tarafı: Yavaş sorgu günlüğünü açıp en çok süre harcayan sorguları indekslemek, donanım eklemekten çoğu zaman daha etkilidir.

Sepet, ödeme ve kullanıcı paneli gibi kişiye özel sayfaları sayfa önbelleğinin dışında tutmayı unutmayın.

Dikey ölçekleme

Dikey ölçekleme mevcut sunucuya daha fazla vCPU, RAM ya da daha hızlı disk eklemektir. Uygulamada değişiklik gerektirmez, bu yüzden ilk tercih olur. Teşhis bölümündeki ölçümler hangi kaynağın artırılacağını söyler: vmstat'ta si/so yüksekse RAM, r sütunu çekirdek sayısını aşıyorsa vCPU, await yüksekse disk. Bulut sunucuda kaynak artırımı panelden yapılabildiği için kampanya dönemleri gibi geçici yüklere uyum sağlamak kolaydır. Sürekli yüksek ve öngörülebilir yükte ise kaynakları kimseyle paylaşmayan bir fiziksel sunucu değerlendirilebilir.

Dikey ölçeklemenin bir tavanı vardır ve tek sunucu tek arıza noktası olarak kalır.

Yatay ölçekleme ve yük dengeleme

Yatay ölçeklemede aynı uygulamayı birden fazla sunucuda çalıştırır, önlerine bir yük dengeleyici koyarsınız. Yük dengeleyici gelen istekleri sunucular arasında dağıtır; yaygın yaklaşımlar istekleri sırayla dağıtmak, en az aktif bağlantısı olan sunucuyu seçmek ya da aynı istemciyi hep aynı sunucuya göndermektir. Hangisinin uygun olduğu uygulamanızın oturum bilgisini nerede tuttuğuna bağlıdır.

Yatay ölçeklemeye geçmeden önce şu koşulları kontrol edin:

1. Oturum bilgisi sunucunun yerel diskinde değil, ortak bir yerde (Redis, veritabanı) tutuluyor mu?
2. Kullanıcıların yüklediği dosyalar tüm sunucuların erişebildiği ortak bir depoda mı?
3. Veritabanı ayrı bir sunucuda mı ve artan bağlantı sayısını kaldırabiliyor mu?
4. Yük dengeleyici, yanıt vermeyen sunucuyu sağlık kontrolüyle devre dışı bırakıyor mu?

Bu dört soruya "evet" diyemiyorsanız önce uygulamayı hazırlamanız gerekir; aksi halde kullanıcılar oturumlarından düşer ya da dosyalarını göremez.

Kalıcı çözüm: izleme ve kapasite planı

Yavaşlık şikâyeti geldiğinde ölçüm yapmak geç kalmış bir tepkidir. Kalıcı çözüm için:

• Sürekli izleme kurun. CPU, bellek, disk gecikmesi ve ağ trafiğini grafik olarak saklayan bir sunucu izleme aracı, sorunun ne zaman başladığını ve hangi kaynakla ilişkili olduğunu geriye dönük gösterir.
• Eşik uyarıları tanımlayın. Yük ortalaması, boş bellek ve disk doluluğu için uyarılar, kullanıcı fark etmeden müdahale etmenizi sağlar.
• Yazılımı güncel tutun. İşletim sistemi, web sunucusu, veritabanı ve uygulama güncellemeleri performans hatalarını da giderir. Güncellemeyi önce test ortamında deneyin ve öncesinde yedek alın.
• Zamanlanmış işleri dağıtın. Yedekleme, raporlama ve antivirüs taraması gibi ağır işleri yoğun saatlerin dışına alın.
• Kampanyalardan önce test edin. Beklenen trafiğin bir kısmını yük testi araçlarıyla üreterek darboğazı gerçek ziyaretçilerden önce görün.

Sık yapılan hatalar

• Ölçmeden kaynak artırmak: Disk darboğazı olan bir sunucuya vCPU eklemek hiçbir şeyi değiştirmez.
• Yalnızca CPU yüzdesine bakmak: CPU %20'de görünürken wa ya da st yüksek olabilir; asıl sorun disk ya da sanallaştırma katmanındadır.
• %util değerini tek başına yorumlamak: SSD ve RAID'de bu değer yanıltıcıdır, await ile birlikte okuyun.
• Takası (swap) kapatarak sorunu gizlemek: Bellek yetersizliği takası kapatınca kaybolmaz; süreçler bellek yetmediği için sonlandırılmaya başlar.
• Saldırıyı ölçekleyerek karşılamak: Katman 7 saldırısında sunucu eklemek saldırganın işini kolaylaştırır; doğru yanıt filtreleme ve WAF'tır.
• Toplu IP engellerken yönetim erişimini unutmak: Kendi IP'nizi engellediğinizde sunucuya yalnızca konsoldan ulaşabilirsiniz.

Sık sorulan sorular

Sunucu yavaşlaması ile yüksek trafik hatası aynı şey mi?

Hayır. Yüksek trafik, yavaşlamanın nedenlerinden yalnızca biridir. Ziyaretçi sayısı sabitken de disk, bellek ya da yazılım kaynaklı yavaşlık görülebilir. Önce kaynak ölçümü yapın, ardından erişim günlüğüne bakarak trafikte artış olup olmadığını kontrol edin.

top çıktısında st değeri yüksekse ne yapmalıyım?

st, hipervizörün sanal makinenizden aldığı işlemci süresini gösterir. Değer sürekli yüksekse sorun sizin uygulamanızda değil, sanal makinenin aldığı işlemci payındadır. Ölçümleri saat bilgisiyle kaydedip sağlayıcınıza iletin; kalıcıysa daha büyük bir plan ya da paylaşımsız bir fiziksel sunucu değerlendirilebilir.

Yük ortalaması kaç olursa sorun vardır?

Tek bir eşik yoktur; değeri çekirdek sayısıyla karşılaştırmak gerekir. Yük ortalaması uzun süre çekirdek sayısının belirgin biçimde üzerindeyse işler sıraya giriyordur. Ancak yükün bir kısmı G/Ç bekleyen süreçlerden de gelebilir, bu yüzden vmstat'taki b sütununa ve wa değerine de bakın.

DDoS saldırısını sunucu üzerinde tek başıma durdurabilir miyim?

Kısmen. Uygulama katmanındaki küçük çaplı saldırılar hız sınırlama, IP engelleme ve WAF kurallarıyla sunucu üzerinde azaltılabilir. Hacimsel saldırılar ise bağlantının kendisini doldurduğu için sunucuya ulaşmadan, ağ düzeyinde filtrelenmelidir; bunun için sağlayıcınızın DDoS koruma seçeneklerini sorun.

Önbellek mi, daha güçlü sunucu mu önce gelmeli?

Çoğu web uygulamasında önce önbellek ve veritabanı sorgu iyileştirmesi gelmelidir; maliyeti düşüktür ve etkisi hemen görülür. Bu adımlardan sonra ölçümler hâlâ bir kaynağın sınırda olduğunu gösteriyorsa dikey, gerekirse yatay ölçeklemeye geçin.