VDS/VPS Performans Düşüşünde Net Sorun Giderme Rehberi

Sanal sunucu performansı düştüğünde ilk tepki genelde “hızlıca başka paket alalım” olur. Oysa çoğu durumda sorun; yanlış kaynak kullanımı, disk doluluğu, ağ gecikmesi, kernel/conntrack ayarları, hatalı cache yapısı veya başka bir servis/kurulumun yük bindirmesidir. Bu rehberde, VDS/VPS üzerinde ölçüm → kök neden tespiti → somut düzeltme akışıyla ilerleyeceksiniz. Sonuç olarak, neyin bozulduğunu netleştirip doğru adımı atmanız kolaylaşır.

1) Önce “ne düştü?” sorusunu ölçümle cevapla

Performans düşüşü çoğunlukla tek bir belirti değildir. CPU tavanı, RAM yetersizliği, disk I/O gecikmesi, ağ paket kaybı veya uygulama tarafı (ör. PHP-FPM/Node.js) yavaşlaması farklı belirtiler üretir.

Hız kaybını üç katmanda ayırın

Aşağıdaki ayrım, sorunu %80 daha hızlı bulmanızı sağlar:

• İstemci deneyimi: Web sitesi geç mi yükleniyor? API yanıtları mı yavaş?
• Sunucu kaynakları: CPU, RAM, swap, disk I/O yükseldi mi?
• Ağ: Paket kaybı, yüksek gecikme (latency), DNS/route sorunları var mı?

5 dakikalık ölçüm paketi (sunucu üzerinde)

• CPU/RAM/disk durumunu kontrol edin:
• top veya htop
• free -m
• df -h
• iostat -xz 1 10
• Ağ gecikmesini test edin:
• ping (hedef IP/alan adı)
• mtr (varsa)
• Servis seviyesinde loglar:
• Web: Nginx/Apache erişim + hata logları
• Uygulama: PHP-FPM, Node.js, queue/worker logları

Bu noktada hedefiniz şu tek cümle: “Sorun kaynakta mı (CPU/RAM/disk/ağ) yoksa uygulamada mı?”

2) En sık kök neden: CPU/RAM/Swap tavanı

VDS/VPS performans düşüşlerinde en sık görülen senaryolardan biri, başlangıçta sorun yaratmayan bir iş yükünün zamanla büyümesidir (ör. cron job’ların sıklaşması, logların şişmesi, index/queue birikmesi).

CPU yükselmesi nasıl anlaşılır?

• top içinde CPU kullanımının sürekli %80-100 bandına yapışması
• 1-2 işlem çekirdeği değil de sistem genelinde sürekli yüksek yük
• Uygulama tarafında belirli bir thread/worker’ın sürekli CPU tüketmesi

Somut kontrol: - top içinden en çok CPU tüketen işlemin PID’sini alın - PID’ye göre ne çalıştığını bulun: - ps -p <PID> -o pid,cmd,%cpu,%mem - Gerekirse servis/binary ismine göre konum ve yapılandırma dosyasını kontrol edin

RAM düşüşü ve swap kullanımı

RAM yetmediğinde Linux swap’a yüklenir. Swap kullanımı artınca disk I/O gecikmesi belirginleşir ve web/API yanıt süreleri uzar.

Kontrol: - free -m çıktısında swap kullanımı sürekli artıyor mu? - vmstat 1 ile swap in/out var mı?

Somut düzeltmeler: - Swap aşırıysa uygulama worker sayısını (ör. PHP-FPM pm.max_children, Node.js concurrency/cluster) düşürün - Log ve temp dosyalarının şişmesini temizleyin - Gereksiz cache/kuyruk yığılmalarını boşaltın

3) Disk doluluğu ve disk I/O gecikmesi (en ölümcül kombinasyon)

VPS/VDS’te “hızlıyım” hissi genelde CPU ile başlar, ama performans düşüşleri çok sık disk kaynaklı çıkar. Özellikle disk %85+ doluysa, log yazma ve indexleme işlemleri ciddi yavaşlar.

Ön kontrol checklist

• df -h ile mount noktalarında boş alan var mı?
• iostat -xz 1 10 ile await veya svctm değerleri yükseliyor mu?
• dmesg | tail -n 200 içinde disk ile ilgili hata var mı? (I/O error, timeout vb.)

Somut düzeltme adımları

• Log rotasyonu yapın (logrotate):
• Nginx/Apache access/error log boyutlarını kontrol edin
• Cache/temp temizliği:
• Uygulamanın oluşturduğu cache (ör. Laravel cache, npm/yarn cache, temp dizinleri)
• Veritabanı:
• MySQL/PostgreSQL için yığılmış transaction/log birikimi var mı?

Not: Disk I/O sorunu tespit ettiğinizde “sadece CPU artırma” yanlış çözüm olur. Önce disk doluluğu ve I/O beklemesini düşürün.

4) Ağ tarafı bozulduğunda: gecikme, paket kaybı, bağlantı birikimi

Performans düşüşü bazen “sunucu yavaşladı” sanılır; aslında ağ gecikmesi (latency) veya paket kaybıdır. Ayrıca bazı servislerde bağlantı birikimi (ör. çok sayıda kısa ömürlü bağlantı) sistemin ağ stack’ini zorlayabilir.

4.1 Paket kaybı ve latency testi

• Uzak uç noktalara ping atın (aynı bölgedeki DNS/IP):
• ping -c 50 <hedef>
• Daha kapsamlı için mtr -rw <hedef> kullanın

Eğer belirgin packet loss/oynak latency görüyorsanız şu olasılıkları değerlendirin: - Yanlış bölge/route - Sağlayıcı ağında geçici yoğunluk - Uygulama bağlantı kurma/yenileme (keep-alive kapalı, aşırı connection churn)

4.2 Conntrack ve bağlantı sayısı (Linux ağ tabakası)

Yük altında çok sayıda bağlantı, conntrack tablosunu doldurabilir ve yeni bağlantılar gecikebilir.

Somut kontrol fikirleri: - ss -s ile toplam bağlantı durumlarını izleyin - Firewall/NAT kurallarında aşırı yük var mı kontrol edin

Düzeltme yaklaşımı: - Uygulama tarafında connection pooling/keep-alive ayarlarını doğru yapın - Gerekirse conntrack kapasite ayarlarını sağlayıcı önerisine göre revize edin

5) Uygulama katmanında performans düşüşü: cache, worker ve zamanlayıcılar

Kaynaklar normal görünüyor ama site/API yavaşsa suçlu çoğunlukla uygulama tarafıdır. En yaygın tetikleyiciler cron/worker birikmesi, cache’in devre dışı kalması ve veritabanı sorgularının zamanla ağırlaşmasıdır.

5.1 Cache gerçekten çalışıyor mu?

• Web katmanında HTTP cache (Cache-Control) var mı?
• CDN/Reverse proxy (Nginx) tarafında cache ayarları aktif mi?
• WordPress/benzeri sistemlerde obje/cache “hit” oranı düştü mü?

Somut kontrol: - Nginx access log’da cache status işaretleri (ör. HIT/MISS) var mı? - Uygulama tarafında “her istek DB’ye gidiyor” davranışı oluştu mu?

5.2 Cron ve background job’lar “pik” yapıyor mu?

Özellikle performans düşüşü günün belirli saatlerinde oluyorsa, cron tetiklemeleri ana adaydır.

Kontrol: - /etc/cron.* ve uygulama cron’larını gözden geçirin - Loglarda aynı anda başlayan ağır işler var mı bakın

Düzeltme: - Ağır job’ları daha seyrek çalıştırın - Queue/worker sistemi kullanıyorsanız worker sayısını hedef yükle hizalayın

5.3 Veritabanı: sorgu yavaşlaması ve kilitlenmeler

İstatistik mantığı: - CPU/RAM normal ama yanıt süreleri uzuyor → DB sorguları veya kilitler güçlü adaydır.

Somut adımlar: - yavaş sorgu loglarını açın/inceleyin (varsa) - en pahalı sorguları optimize edin (index ekleme, sorgu sadeleştirme) - transaction/lock sürelerini azaltın

6) “Sürekli düşüyor” ise önleyici kontroller: izleme, limitler ve yedekleme disiplini

Tek seferlik düzeltme yeterli olmayabilir. Net hedef, bir daha aynı senaryonun sürpriz olmaması.

6.1 İzleme (monitoring) kurun: 4 metrik şart

Aşağıdaki metrikler, performans düşüşünü kök nedene bağlamanın en hızlı yoludur: - CPU kullanımı (ve load average) - RAM ve swap - Disk doluluğu + I/O beklemesi - Ağ gecikmesi/paket kaybı

6.2 Kaynak limitlerini doğru kullanın

Bazı sistemlerde konteyner/servis limitleri yanlış yapılandırıldığı için aniden performans bozulur. Çözüm yaklaşımı: - Uygulama süreçlerini (worker/concurrency) sunucu kapasitesine göre sınırlayın - Otomatik ölçekleme varsa doğru eşiklerle ayarlayın

6.3 Yedek (backup) ile performansı aynı anda koruyun

Yedekleme kritik olmakla birlikte, yanlış planlanmış backup yük bindirir. Bu yüzden: - Backup işlerini yoğun saat dışında yapın - DB snapshot veya dosya bazlı backup yöntemini ölçerek seçin - Yedek depolama alanının dolmaması için otomatik temizleme kuralı koyun

Hızlı karar tablosu: Belirtiye göre aksiyon

Aşağıdaki tablo, 10 dakikada “hangi alana bakacağım?” kararını netleştirir.

Sonuç: Planlı tanılama ile “tahmin” yerine “kanıt” kullanın

VDS/VPS performans düşüşünü çözmek için tek doğru yol, önce ölçümle sorunu kategorize etmek (CPU/RAM/disk/ağ/uygulama), sonra kök nedeni hedefleyerek düzeltmektir. En kısa aksiyon önerimiz: Bugün başlayarak CPU/RAM/swap/disk I/O ve ağ gecikmesini bir kez sistematik kontrol edin; ardından bulguya göre worker, cache, cron ve veritabanı tarafını revize edin. Performans tekrar ediyorsa izleme kurup (4 metrik) belirli saat/pattern ile iş yükünü eşleştirin; böylece bir sonraki düşüşte müdahale süreniz dakikaya iner.