VDS/VPS Performans Düşüşünde Net Aksiyon Planı (30 dk Kontrol)

VDS ya da VPS sunucusunda performans düşüşü, çoğu zaman "sunucu çöktü" gibi tek bir nedenden değil; CPU yükü, disk gecikmesi (disk latency), ağ darboğazı, rate limit/throttling, yanlış yapılandırma veya disk doluluğu gibi birden fazla faktörden birlikte oluşur. Bu rehberde, 30 dakikada sorunun kaynağını daraltacak şekilde CPU, RAM, disk, ağ ve sistem loglarını sırayla kontrol edecek; her bulgu için uygulanabilir aksiyonları net maddeler halinde göreceksiniz. Hedef, belirsiz "hosting yavaş" yorumuna gitmeden, ölçüme dayalı karar vermek.

1) İlk 5 dakika: Etkiyi ölç, değişkenleri sabitle

Performans düşüşünde ilk adım, sorunun neyi etkilediğini netleştirmek ve aynı anda birden çok şeyi kurcalamadan ölçü almaktır.

Hangi metrikler “düşüş” sayılır?

Aşağıdakilerden en az biri belirgin şekilde bozuluyorsa aksiyon planına geçin: - Web/API isteklerinde artan gecikme (p95/p99 latency) - CPU kullanımında uzun süreli yükselme - Sunucu yanıtında zaman aşımı (ör. uygulama tarafında timeout) - Disk okuma/yazmada belirgin yavaşlama - Ağda paket kaybı veya aşırı retransmit (TCP retransmission)

Değişiklik yapmadan önce 3 şey topla

• Son 1 saatlik uygulama metrikleri: ör. Nginx/Apache response süreleri, hata oranı
• Sunucu metrikleri: CPU, RAM, disk I/O, load average
• Son 5 dakikalık log parçaları: sistem logu ve uygulama logu

İpucu: Aynı anda hem yeniden başlatma hem ayar değişikliği yapmayın. Hangi değişiklikten sonra düzeldi/bozuldu netleşmez.

2) 10 dakika: CPU/RAM yükünü ve “load”ın kaynağını bul

CPU/RAM sorunu, en sık görülen nedenlerden biridir; ama "CPU %100" tek başına yeterli açıklama değildir. Load average ile işlem türünü ayırmanız gerekir.

Hızlı kontrol komutları (Linux)

Aşağıdaki komutlar, sorunu sınıflamak için yeterli sinyali verir: - CPU ve süreç özeti: top veya htop - Yük (load average): uptime - En çok CPU kullanan süreçler: ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head - Bellek ve swap durumu: free -h - Swap kullanımı varsa: vmstat 1

Net yorum kılavuzu

• CPU yükseliyorsa: Genelde tek bir servis/işlem (ör. worker, indexer, cron) ya da istek patlaması vardır.
• RAM doluysa ve swap aktifse: Performans düşüşü disk I/O’yu da şişirir; “disk latency” ile birlikte değerlendirin.
• Load average yüksek ama CPU düşükse: I/O beklemesi (özellikle disk) veya kernel düzeyinde bekleme vardır.

Aksiyonlar

• Tek bir süreç aşırı CPU tüketiyorsa: O süreç için istek/kuyruk/loop durumunu inceleyin (queue worker, polling aralığı, cron frekansı).
• Swap artıyorsa: Uygulamanın bellek tüketimini azaltın (cache boyutu, concurrency ayarı) ve mümkünse swap yerine RAM planlayın.
• PHP-FPM, Node.js, Gunicorn gibi worker tabanlı sistemlerde: concurrency/worker sayısını mevcut donanıma göre sınırlandırın.

3) 10 dakika: Disk gecikmesi ve disk doluluğu (en kritik tetikleyiciler)

Disk performansı, VDS/VPS’lerde “yavaşlık” şikayetlerinin başlıca nedenidir. Özellikle SSD olsa bile IOPS sınırı veya hatalı filesystem/partition yönetimi gecikme yaratabilir.

Disk gecikmesini ölçmeye yönelik pratik kontrol

• Disk doluluğu: df -h
• Disk I/O yükü: iostat -x 1 10 (paket olmayabilir; yoksa alternatif izleyin)
• Bloklama/persistent I/O durumları: vmstat 1

Net risk listesi (hemen kontrol)

• /var, /home veya log dizinleri dolu: Uygulama log yazamadığı için yanıtlar yavaşlar veya hataya döner.
• Filesystem %80+ doluluk: Birçok servis yazma işlemlerini ve metadata güncellemelerini yavaşlatır.
• Uzun süren checkpoint/backup write: Aynı anda yedekleme (backup) yazma ve iş yükü varsa disk I/O şişer.

Aksiyonlar

• Disk doluluğu yüksekse: Öncelik log rotasyonudur.
• Logları inceleyin ve gereksiz büyük dosyaları temizleyin.
• logrotate ayarlarının çalıştığını doğrulayın.
• Yedekleme çakışması varsa: Yedekleme saatini iş yoğunluğu olmayan zamana alın.
• Veritabanı varsa: Slow query ve yoğun index/maintenance çalışmalarını saatlendirin.

4) 15 dakika: Ağ (network) darboğazı, paket kaybı ve throttling

Performans düşüşü “CPU değil ağ” da olabilir. Özellikle veri merkezi dışı ülke, yoğun saat trafiği veya sağlayıcının rate limiting / throttling mekanizması varsa gecikme artar.

Net ağ testleri

• Paket kaybı/latency: mtr -rwz <hedef-ip>
• Sunucu içi bağlantı testleri (uygulama hedefi): uygulamanın bağlandığı servis IP/port kontrolü
• İstemci tarafında da aynı anda ölçüm yapın (aynı test 2 konumdan bakış açısı sağlar).

throttling / rate limit şüphesi nasıl doğrulanır?

Aşağıdaki belirtiler genelde ağ/plan kaynaklıyı işaret eder: - Bant genişliği (throughput) belirli bir eşikten sonra düşüyor - TCP bağlantı kurma veya TLS handshake gecikmeleri artıyor - Aynı sunucuda farklı uygulamalar da birlikte yavaşlıyor

Aksiyonlar

• Trafik artışı ani başladıysa: Uygulama tarafında gereksiz istekleri kısın (cache, CDN, endpoint rate limit).
• Veri büyüklüğü yüklü işlemler varsa: Büyük indirme/yükleme işlerini saatleyin.
• Sağlayıcı tarafında ağ planı kısıtlarını inceleyin: Eğer performans metrikleri düzenli eşik üstünde ise, daha yüksek ağ limiti veya farklı tier düşünülür.

5) 10 dakika: Kernel, zaman, process crash ve sistem loglarında ipucu

Bazen performans düşüşü “uygulama” gibi görünür ama kök neden sistem seviyesindedir: OOM killer, kernel reclaim, CPU throttling, servis restart döngüsü, DNS/clock sorunları.

Loglarda aramanız gereken net ifadeler

• OOM killer: Out of memory
• Service restart döngüsü: systemd ile “restarting” kayıtları
• Disk/IO hata sinyalleri: I/O error, ext4/xfs mesajları
• Kernel throttling belirtileri: donanıma/virt katmana göre değişir

Örnek log akışı (genel): - journalctl -S "1 hour ago" - Uygulama logları: Nginx/Apache, uygulama runtime (ör. supervisor/gunicorn) logları

Aksiyonlar

• OOM killer görüyorsanız: Bellek ayarlarını düşürün (worker sayısı, heap, cache) ve swap/limit yaklaşımını gözden geçirin.
• Restart döngüsü varsa: Uygulama yapılandırma hatası veya kaynak limit aşımı var demektir; hata kodlarını önce çözün.
• Zaman (time skew) sorunu varsa: TLS/sertifika doğrulama ve tokenlar gecikebilir; NTP/chrony ayarlarını doğrulayın.

6) “Tek hamlede düzeltme” yerine kanıta dayalı yol haritası

Performans düşüşünü çözerken en sık yapılan hata, sebebi netleştirmeden sunucuyu yeniden başlatmaktır. Yeniden başlatma geçici rahatlatır; kök neden devam ederse 1-2 saat içinde yeniden düşer.

Bulgu → olası neden → net aksiyon tablosu

Kontrol paneli üzerinden yapılabilecekler

Sunucu sağlayıcının kontrol paneli veya yönetim arayüzü üzerinden şunları doğrulayın: - Anlık CPU/RAM/disk grafikleri (30dk-1 saat penceresi) - Yedekleme/maintenance işlemi çalışma saatleri - Port/servis bazlı durum (bazı panellerde restart/health check) - Virt katman sınırlamaları: “burst” veya ağ/disk limitleri gibi notlar

Sonuç: 30 dakikada kaynak bulun, sonra çözümü kalıcı yapın

Performans düşüşünde doğru yaklaşım, önce ölçümle sorunu sınıflamak (CPU/RAM mi, disk mi, ağ mı, sistem logu mu?) ve sonra tek bir kök nedeni hedeflemektir. Bugün uygulayacağınız en net aksiyon sırası şudur: disk doluluğu (df) ve load/CPU ile başlayın, ardından I/O ve ağ metriklerini kontrol edin; loglarda OOM/restart döngüsü gibi kök işaretleri yakalayın. Sorun tekrarlıyorsa, çözümü yalnızca geçici yeniden başlatma değil, kapasite planı (RAM/IO limit), yedekleme zamanlaması ve uygulama ayarları üzerinden kalıcı hale getirin.