VDS/VPS Performans Düşüşü: Hızlanmak için Net Kontrol Listesi

Sanal sunucularda (VDS/VPS) performans düşüşü çoğu zaman tek bir hatadan değil, birkaç göstergenin birlikte “yanlış yöne” gitmesinden kaynaklanır. Kullanıcı deneyimi (sayfa yüklenme süresi), uygulama hataları ve hatta bağlantı zaman aşımı bu düşüşün ilk belirtileri olur. Bu rehberde, performans düşüşünü hızlıca teşhis edip nereden başladığınızı netleştirmenizi sağlayacak bir kontrol akışı bulacaksınız: CPU/RAM/disk, ağ (network), I/O bekleme, servis kaynak kullanımı, loglar ve kalıcı iyileştirmeler.

Aşağıdaki adımların amacı “tahmin etmek” değil; ölçüm yapıp nedeni daraltmaktır. Her bölümde, hangi metriğe bakacağınızı ve hangi sonuca hangi aksiyonun çıktığını göreceksiniz.

1) İlk 10 dakikada etkiyi ve kapsamı ölçün

Performans düşüşü başladıktan sonra önce “her şey mi yavaş?” sorusunu cevaplayın.

Etkiyi kontrol edin

• Web uygulamasıysa: Uygulama sayfalarında TTFB (ilk byte zamanı) mi artıyor, yoksa sadece toplam yükleme mi? Tarayıcı DevTools’ta network sekmesinden gecikmeyi görün.
• API/SSH tarafındaysa: İsteklerin response time değerlerini kıyaslayın.
• Dosya/streaming varsa: İndirme hızı mı düştü, yoksa bağlantı kurulması mı uzadı?

Sunucu bazında eşik belirleyin

Aşağıdaki metrikler, sorun nerede olduğunu hızlı gösterir: - CPU: Sürekli %80+ mi? CPU steal time (bulut ortamında) görüyor musunuz? - RAM: Serbest RAM düşük mü, swap kullanımı artıyor mu? - Disk: I/O bekleme yüksek mi? Diskin doluluğu performansı bozar. - Network: Paket kaybı, retransmit artışı var mı?

Bu tespiti yapmadan servis değişikliği yapmak genellikle zaman kaybettirir. Ölçüm, doğru düzeltmeyi kısaltır.

2) Kaynağı daraltın: CPU, RAM, disk I/O ve swap sıçramaları

VDS/VPS’te performans düşüşü için en sık 4 kök neden vardır: CPU darboğazı, RAM yetersizliği, disk I/O gecikmesi ve swap (sayfalama) kaynak tüketimi.

CPU darboğazı belirtileri

• CPU tek çekirdekte değil, tüm çekirdeklerde uzun süre yüksek seyrediyorsa uygulama yükü artmış olabilir.
• “Anlık yükselip düşüyor” yerine sürekli yüksekse optimizasyon gerekir.

Uygulama süreçlerini görmek için Linux’ta şu akışı kullanın: - top veya htop ile en üstteki prosesleri inceleyin. - Tercihen PID bazında ayrıntı için ps -eo pid,pcpu,pmem,cmd --sort=-pcpu | head -n 15

Aksiyon: Yüksek CPU kullanan süreç belirliyse önce kod/konfigürasyon tarafını düzeltin. Örnek: süreçte sonsuz döngü, yoğun log üretimi, bitmeyen sorgu veya yanlış cron.

RAM yetersizliği ve swap artışı

RAM düşerse Linux swap’a yüklenir; bu da gecikmeyi dramatik artırır. - RAM kullanımının sürekli %90 civarında olması - Swap kullanımının artması - Uygulamanın yanıt sürelerinin “yavaşça değil, sıçrayarak” artması RAM kaynaklı olur.

Aksiyon: - RAM gerçekten yetersizse plan yükseltin. - Swap kullanımını azaltmak için önce bellek tüketen süreci bulun. - Uygulama cache katmanlarını (ör. Nginx cache, uygulama cache) doğru yapılandırın.

Disk I/O beklemesi (I/O wait)

I/O wait yükseliyorsa CPU düşük olsa bile uygulama yavaşlar. Özellikle veritabanı veya sık disk yazan işler (log, indexleme) I/O’yu kilitler.

Kontrol: disk doluluğu ve I/O bekleme - Disk doluluğu %80+ ise performans düşer; log ve geçici dosyalar hızla büyür. - I/O wait yükseliyorsa disk hattı darboğazdadır.

Aksiyon: - Disk doluluğunu acil temizleyin (log rotasyonu, geçici dosyalar). - Veritabanı için uygun indexleme ve sorgu optimizasyonu yapın. - Çok yazan işlerde (ör. sık loglama) log seviyesini ve rotasyonu düzenleyin.

3) Ağ (network) sorununu ele: Paket kaybı, gecikme, bant genişliği

Ağ kaynaklı performans düşüşünde genellikle: - Uzak istekler (özellikle Avrupa/ABD) yanıt verirken gecikme artar. - Arayüzden arayüze çağrılarda timeout görülür. - İndirme hızları düşer ama CPU/RAM normal kalır.

Kıyas yapın: dıştan ve içten ölçüm

• Sunucu dışından ping/traceroute benzeri testlerle gecikmeyi kıyaslayın.
• Uygulama sunucu içindeyse: curl -w "time_total=%{time_total}\n" -o /dev/null -s http://localhost/... ile yerel gecikmeyi ölçün.
• Ağ trafiği artışı varsa (özellikle bot trafiği): web server access log’larına bakın.

Aksiyon: - Trafik artışı saldırı/bot kaynaklıysa WAF/CDN veya rate limit devreye alın. - Lokasyon uyuşmazlığı varsa (Türkiye kullanıcı -> yurt dışı lokasyon) CDN ile içeriği yaklaştırın. - Bant ölçümünüzde normalin üzerinde dalga varsa, servis kalitesi (QoS) ve sağlayıcı performansını değerlendirin.

4) Uygulama katmanı: Cron, worker, queue ve güncellemeler

Performans düşüşü güncelleme veya yapılandırma değişikliğinden hemen sonra başladıysa uygulama katmanını kontrol edin.

Güncelleme ve konfig değişikliği kontrolü

• Son deploy’den sonra mi başladı?
• PHP/Node/Python ayarları değişti mi (worker sayısı, memory limit, max connections)?
• Nginx/Apache tarafında proxy time-out veya cache ayarları güncellendi mi?

Cron ve background job’lar

En sık görülen senaryolar: - Yanlış planlanan cron (her dakika, her 10 saniye gibi) - Kuyruğun (queue) tüketilememesi ve iş birikmesi - Worker sayısının düşmesi veya işlerin kilitlenmesi

Aksiyon: - Önce çalışan scheduler’ları listeleyin. - crontab -l - systemctl list-timers --all - Kuyruk sistemi kullanıyorsanız (ör. Redis/RabbitMQ) backlog metriğine bakın.

Veritabanı kaynaklı performans

DB tarafı yavaşladığında uygulama “tamamlanmıyor” gibi görünür. - yavaş sorgular - lock (kilit) beklemeleri - yanlış index

Aksiyon: - Sorgu loglarını inceleyin. - Yavaş sorgu için index ekleyin. - Bağlantı sayısı artışı varsa connection pool ayarını kontrol edin.

5) Loglar ve güvenlik: Gerçek nedeni logdan çıkarın

Performans düşüşünü “sorun güvenlik mi?” diye ayırmadan önce loglar anlatır.

Nereye bakmalısınız?

• Web server logları: Nginx/Apache access/error
• Uygulama logları: framework logları
• Sistem logları: auth, kernel, journal
• Güvenlik: fail2ban (kullanıyorsanız) ve SSH login denemeleri

Örnek tespit ipuçları: - Çok sayıda 4xx/5xx isteği - Aynı IP’den aşırı istek (bot) - auth başarısız denemeleri ve otomatik engelleme - kernel loglarında disk/IO uyarıları

Port tarama ve servis yükü

Port tarama tek başına CPU’yu tüketmez; ama saldırı trafiği çok yoğun geliyorsa web server ve loglama katmanı etkilenir.

Aksiyon: - Rate limiting uygulayın. - Gereksiz açık portları kapatın. - fail2ban/policy ile brute-force denemelerini kısıtlayın. - Log seviyesini “debug” yerine “info/warn” seviyesine çekin.

6) Kalıcı iyileştirmeler: Ölçüm + kapasite planlama + doğru ayarlar

Sorunu çözdükten sonra hedef, tekrarlamayı azaltmaktır. Burada yapılacaklar “tek seferlik temizlik” değil, sistem davranışını kontrol etmektir.

İzleme (monitoring) kurun: 5 metriği grafiğe bağlayın

Aşağıdaki metrikler için grafikleri hazır hale getirin: - CPU kullanım yüzdesi ve load average - RAM kullanımı ve swap kullanımı - Disk doluluğu ve I/O wait - Network kullanım (in/out) ve hata/packet kaybı göstergeleri - Uygulama bazlı: request süresi (p95/p99) ve error rate

Aksiyon: Alarm eşiği belirleyin. - swap 0’dan sürekli yükseliyorsa alarm - disk %80+ doluluğa yaklaşınca alarm - error rate artınca alarm

Kaynak ölçekleme stratejisi

• RAM kaynaklıysa: worker sayısı ve cache ayarları ilk adım; yetmezse plan yükseltme.
• CPU kaynaklıysa: optimizasyon (query/cache/worker) ve gerekirse plan yükseltme.
• Disk I/O kaynaklıysa: I/O yoğun işlerin düzenlenmesi + disk performansı ve yerleşim.

Net karar kuralı: - Sorun belirli bir saat aralığında tekrarlıyorsa (ör. günlük peak), cron/worker ve dış talep modelini düzeltin. - Sorun tüm gün yayılıyorsa, kapasite yetersizliği ihtimali doğrudur ve planı gözden geçirin.

7) Ne zaman sağlayıcıya veya panel/altyapı kontrollerine dönmelisiniz?

Bazı performans düşüşleri uygulama kaynaklı değildir; bulut altyapısı veya sanallaştırma paylaşımı etkiler.

Bulut/altyapı kaynaklı işaretler

• CPU/RAM normal görünürken gecikme artıyor
• aynı lokasyonda birden fazla müşteride benzer şikayet var
• “uygulama kaynak” az olmasına rağmen network zaman aşımı artıyor

Aksiyon: - Sağlayıcı destek ekibine zaman damgası, metrikler ve log parçalarını gönderin. - Aynı zamanda kendi tarafınızda izleme verisini saklayın (kanıt seti).

Karar Tablosu: Belirtiye göre ilk aksiyon

Aşağıdaki tablo, hızlı yön bulmanıza yardım eder.

Sonuç: Aksiyon planını bugün başlatın

Performans düşüşünde en doğru yaklaşım, “hızlıca bir ayar değiştir” yerine ölçümle nedeni daraltmaktır. Bugün yapmanız gereken minimum aksiyonlar şunlar: (1) CPU/RAM/disk I/O/network metriklerini aynı anda kontrol edin, (2) yüksek tüketen süreç ve zamanlanmış iş (cron/worker) varsa tespit edin, (3) loglarda hata oranı ve trafik paterni görünüyorsa güvenlik/rate limit adımlarını uygulayın, (4) çözüm sonrası p95/p99 gecikme ve error rate için alarm kurun.

Eğer isterseniz, kullandığınız işletim sistemi (Linux/Windows), uygulama türü (ör. WordPress, Node.js, PHP) ve performans düşüşünün başladığı zaman aralığını yazın; buna göre kontrol listesini sizin senaryonuza göre daha da netleştirebilirim.