Sunucu CPU %100: Sebepler ve net çözüm planı

Sunucunuzda CPU yüzde 100 görmek çoğu zaman “donanım zayıf” anlamına gelmez; çoğu durumda belirli bir süreç, yanlış yapılandırma, hatalı trafik veya bir servis döngüye girmiş demektir. Bu rehberde CPU yükünü yükselten tipik senaryoları ayıracağız; somut metrikler, log kaynakları ve adım adım uygulanabilir çözümlerle sorunu teşhis edip kalıcı hale getireceksiniz. Ayrıca VDS/VPS/dedicated kurulumlarda işe yarayan pratik kontrol listesini de paylaşacağız.

CPU yüzde 100 ne anlama gelir?

CPU yüzde 100, işletim sisteminin tüm zaman dilimlerinde CPU çekirdeklerinin işlem gücünü doyurduğunu gösterir. Bu durum şu etkileri doğurur: - Web yanıt süreleri artar (TTFB uzar), hata oranları yükselir. - Kuyruklar birikir: PHP-FPM, worker süreçleri, veritabanı sorguları veya kuyruk (queue) tüketimi yavaşlar. - Zamanlayıcılar gecikir: cron job’ları, indexleme, raporlama, log işleme aksayabilir.

Önemli nokta: “CPU yüzde 100” tek başına yeterli teşhis vermez. Gerçek sebep, hangi süreçlerin yükseldiği (process), hangi tür yük olduğu (I/O mu CPU mu), zamanla nasıl değiştiği (anlık mı sürekli mi) ve trafik/iş yüküyle nasıl eşleştiğidir.

Hızlı ayrım: CPU mu bekleme mi?

CPU kullanımı yüksekken bile bazı yükler aslında I/O beklemesiyle ilişkilidir. Bu nedenle CPU + disk + ağ metriklerini birlikte değerlendirin.

Kullanacağınız temel görünürlük kaynakları: - OS düzeyi: top/htop, ps, pidstat, iostat, vmstat - Uygulama: web server access log (Nginx/Apache), uygulama logları (PHP-FPM, Node, Java) - Sistem: dmesg, kernel OOM logları, sistem journal (journalctl) - Sağlayıcı: VDS/dedicated metrik ekranı (CPU steal, bandwidth, disk IOPS)

Net teşhis: 10 dakikada CPU yüzde 100’ü bul

Aşağıdaki plan “önce durumu ölç, sonra suçluyu bul” mantığıyla ilerler. Hedef, üretimde saatler kaybetmeden süreci yakalamaktır.

1) Zaman aralığını sabitleyin

CPU artışı ne zaman başladı? - Uygulama deploy edildi mi (kod değişimi, config değişimi)? - Yeni cron job eklendi mi? - Site trafiğinde ani artış oldu mu (kampanya, bot saldırısı)? - Veritabanı backup/restore, indexleme veya migration çalıştı mı?

Loglarda arama için başlangıç/bitiriş penceresi belirleyin (ör. 27.08 14:05–14:25).

2) Hangi süreçler yiyiyor?

Sunucuda en üst tüketiciyi görmeden çözüm aramak zaman kaybettirir.

Linux’ta örnek komutlar: - top -o %CPU - htop (varsa) - ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head - Süre bazlı inceleme: pidstat -u -p ALL 1

Aradığınız bilgiler: - En yüksek CPU kullanan PID’ler (process) - Bu PID’lerin ebeveyni (PPID) ve servis adı - CPU artışıyla beraber RAM ve swap artışı var mı?

3) CPU ile birlikte I/O ve yük var mı kontrol edin

CPU tek başına mı yüksek, yoksa sistem “bekliyor” mu? - iostat -xz 1 - await, util, svctm yüksekse disk I/O darboğazı olabilir. - vmstat 1 - r (ready queue) yüksekse CPU scheduling baskısı vardır. - si/so (swap in/out) artıyorsa bellek problemi döngüye sebep olmuş olabilir.

Bu ayrım, “cache temizle” gibi yanlış hamlelerin önüne geçer.

4) Web trafiği CPU’yu mu zorluyor?

Nginx/Apache access log ve hataları eşleştirin.

Kontrol edin: - Tek bir endpoint sürekli mi çağrılıyor? (ör. /wp-admin/admin-ajax.php, /cart, /search) - 4xx/5xx oranı yükseldi mi? - Aynı IP veya IP aralığı aşırı istek mi gönderiyor? (bot) - WAF/Rate limit devre dışı mı?

5) Cron ve arka plan işleri döngüye girmiş olabilir

CPU yüzde 100 bazı durumlarda tekil “yanlış cron” davranışından gelir. - crontab -l ve /etc/cron.* - /var/spool/cron/crontabs (distroya göre) - Sistem timer’ları: systemctl list-timers --all

Kontrol: Cron job her dakika mı çalışıyor? İş bitmeden yeni çalışmaya mı başlıyor? Bu senaryoda load dalga dalga yükselir.

En yaygın sebepler (ve net çözüm yaklaşımı)

Aşağıdaki maddeler sahadaki en sık kök nedenlerdir. Her birinde çözüm, sebebe uygun teşhis adımıyla başlar.

1) Yanlış uygulama kodu veya sınırsız döngü

Belirti: Sürekli çalışan tek bir proses/worker CPU’yu yer (aynı PID saatlerce üstte).

Net çözüm: - Deployed değişikliklerden sonra başladıysa rollback (geri alma) planı uygulayın. - Uygulama tarafında request başına maliyeti düşürün: sorgu optimizasyonu, döngü sınırı, pagination. - Thread/worker sayısı ayarını kontrol edin (ör. PHP-FPM pm.max_children).

2) Veritabanı sorguları CPU ve beklemeyi beraber yükseltir

Belirti: MySQL/PostgreSQL süreçlerinde yükseliş; aynı anda yavaş yanıt.

Net çözüm: - En pahalı sorguları bulun: slow query log (slow_query_log). - Index eksikliği veya yanlış join planı kontrol edin. - Backup/restore veya migration sırasında CPU artıyorsa zamanlamayı değiştirin.

3) PHP-FPM/Node/Java worker sayısı yanlış

Belirti: CPU artışı, trafikle birlikte dalgalanır; worker’lar sürekli yeni iş alır.

Net çözüm: - PHP-FPM için pm modunu ve pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers değerlerini mevcut RAM’e göre ayarlayın. - Çok sayıda worker gereksizse CPU tüketimi artar; azsa kuyruk birikir.

4) Cache eksikliği veya cache yanlış yapılandırma

Belirti: Aynı sayfalar tekrar tekrar “hazırlanıyor” gibi davranır; CPU yükselişi endpoint bazlı.

Net çözüm: - Uygulama cache (Redis/Memcached) ve web cache (Nginx microcache) devreye alın. - Cache bypass edilen header/set (ör. doğru varyasyon yapılmaması) kontrol edin.

5) Bot trafiği, saldırı veya tarayıcı olmayan yoğun istek

Belirti: Access log’da belirli User-Agent/IP tekrarları; endpoint çeşitliliği fazladır.

Net çözüm: - Rate limit ve WAF kurallarını devreye alın. - Şüpheli IP’leri engelleyin (kalıcı çözüm değil, geçici tahliye gibi düşünün). - API endpoint’lerinde pagination ve doğrulama (auth) zorunluluğunu artırın.

6) Swap kullanımı artışı (bellek baskısı)

Belirti: RAM doluyor, swap devreye giriyor; CPU yüzde 100’e yaklaşırken sistem “donuyor” gibi.

Net çözüm: - Yetersiz RAM’i düzeltin: application memory footprint’i azaltın veya planladığınız RAM’i artırın. - Disk swap ise disk I/O yükü de artabilir; swap’i kalıcı olarak aşırılaştırmayın. - Uygulama düzeyinde büyüyen cache/heap kontrol edin.

7) Disk/Filesystem I/O darboğazı CPU’yu etkiler

Belirti: iostat’ta util ve await yüksek; CPU “boş dönmüyor”, ama süreçler bekliyor.

Net çözüm: - Disk IOPS limit/performans sorununu teşhis edin. - Log rotasyonu düzgün mü? Aşırı büyük log dosyaları kontrol edin. - RAID/volume ve filesystem ayarlarını gözden geçirin.

Çözüm senaryoları: Hızlı ve kalıcı adımlar

Aşağıdaki planı uyguladığınızda sorunu sadece bastırmak yerine kökten çözme şansı artar.

Acil durum (5-15 dakika): hizmeti toparla

1) En çok CPU kullanan prosesi tespit edin (PID/servis). 2) Trafik bir anda arttıysa geçici olarak rate limit uygulayın. 3) Cron/worker tetikleniyorsa ilgili job’u geçici durdurun. 4) Uygulama hata loglarını kontrol edin (exception stack trace).

Not: Üretimde “rastgele process kill” kalıcı çözüm değildir; önce sebebi bulup uygun adımı seçin.

Kök neden (1-3 saat): kalıcı iyileştirme

• Kod değişikliği sonrası başladıysa rollback + değişiklik diff analizi.
• Veritabanı yavaşlığında: slow query raporu + index/SQL optimizasyonu.
• Worker ayarı hatalıysa: PHP-FPM/Node concurrency değerlerini RAM/CPU’ya göre yeniden dengeleyin.
• Bot etkisi varsa: WAF + rate limit + cache + endpoint koruma.

Kapasite planı: CPU limitini doğru hedefleyin

Sadece “CPU’yu düşürmek” değil, gelecekte tekrar yaşanmaması için kapasiteyi ayarlamak gerekir. - Pik saatlerde CPU’nun sürekli %80-90 üstüne çıktığını görüyorsanız ölçekleme veya uygulama optimizasyonu gerekir. - Ani sıçramalar tek seferlikse (backup/indexleme) işlerin zamanlaması düzeltilebilir.

VDS/VPS/dedicated farkı: CPU steal ve paylaşım etkisi

VPS/VDS üzerinde CPU yüzde 100 görüldüğünde, iki ayrı problem karışabilir: - Gerçek işlem yoğunluğu: belirli processler çalışır. - Sanallaştırma etkisi (CPU steal): hypervisor başka tenant’a CPU zamanı ayırıyordur.

Net aksiyon: - Sağlayıcı metriklerinde CPU steal varsa ve süreçler “beklemede” görünüyorsa, kök neden uygulama değil altyapı kaynak paylaşımı olabilir. - Bu durumda “ayar yap” yaklaşımı yerine daha iyi planlama: daha yüksek sınıf CPU, burst limitleri, ya da dedicated seçeneği.

Pratik kontrol listesi (kopyala-kullan)

Aşağıdaki maddeleri aynı sırayla kontrol edin.

• [ ] CPU artış zamanı: deploy/cron/backup mı başladı?
• [ ] top/ps ile en yüksek CPU PID’leri hangileri?
• [ ] Bu PID hangi servis altında (web server, php-fpm, db, cron, worker)?
• [ ] vmstat ile ready queue (r) yüksek mi?
• [ ] iostat ile await/util yüksek mi? (I/O darboğazı?)
• [ ] RAM dolu mu, swap artıyor mu?
• [ ] Nginx/Apache access log’da tek endpoint veya tek IP aşırı mı?
• [ ] WAF/rate limit aktif mi?
• [ ] Slow query log var mı? En pahalı sorgular hangileri?
• [ ] Cron/systemd timer tetiklenmesi var mı? (her dakika çalışıp üst üste binme?)

Sonuç: CPU yüzde 100’ü tek hamlede değil, ölçerek çözün

Sunucuda CPU yüzde 100 sorunu için en hızlı yol, “süreci bulmak + metriklerle ayrım yapmak + sebebe uygun kalıcı ayarı yapmak”tır. Bugün yapmanız gereken aksiyon: önce zaman penceresini sabitleyin, ardından top/ps ile CPU yiyen PID’yi netleştirip (process), web/db/cron etkileşimini loglarla eşleştirin. Süreç netleştiğinde, worker/cache/index veya trafik kontrolünü hedefli uygulayın; gerekirse kapasiteyi planlayın (özellikle VDS/VPS tarafında CPU steal ve kaynak paylaşımı sinyalleri varsa). Bu yaklaşım, aynı hatanın tekrarını önler.