Sunucu CPU %100: Sebepleri ve 2026 İçin Net Çözümler

CPU kullanımı %100 olduğunda web siteleri yavaşlar, API istekleri zaman aşımına uğrar ve bazen tamamen hizmet durur. Bu yazıda “neden oldu?” sorusunu somut ölçümlerle netleştiriyor; Linux, VDS/VPS ve dedicated senaryolarında en sık görülen sebepleri sıralayıp her biri için uygulanabilir çözümler veriyoruz. Okuduktan sonra kendi sunucunda hangi komutla neyi kontrol edeceğini bilecek, sorunu kalıcı olarak düşürecek aksiyon planını çıkaracaksın.

CPU %100’ün en sık 7 nedeni: Ne zaman süreç, ne zaman altyapı

CPU %100 “hesaplama” (CPU-bound) sorunu da olabilir, “bekleme” (I/O wait) kaynaklı dolaylı bir belirti de olabilir. Önce hedefi doğru koymak için şu ayrımı yap: - CPU-bound: Bir süreç/işlem sürekli çalışır, kullanıcı istekleri ilerler ama geç yanıt verir. - I/O-bound (bekleme): CPU görünür olarak artar, ancak asıl darboğaz disk/IO veya ağ beklemesidir. - Burst/DoS/DDoS: Trafik ani yükselir, web servis süreçleri ve log yazımı büyür. - Yanlış yapılandırma: Rate limit yoktur, keep-alive bozuk, cache devre dışıdır. - Kaynak tükenmesi: Çok büyük cron job, sınırsız worker sayısı, memory yokluğu nedeniyle swap’a düşme.

Aşağıdaki tablo, “semptom → olası kök neden → hızlı doğrulama” eşlemesini netleştirir.

Semptom	Olası kök neden	Net doğrulama adımı
`top/htop`’ta tek bir PID çok CPU tüketiyor	Hatalı uygulama döngüsü, uçuşan log, sonsuz retry	`ps -eo pid,comm,%cpu,%mem --sort=-%cpu \| head`
CPU yüksek ama `iowait` de yükseliyor	Disk/SSD doygun, yoğun IO, yavaş storage	`iostat -xz 1 5` ve `vmstat 1 5`
Web yüküyle birlikte CPU artıyor	Bot/trafiğe karşı koruma yok	Nginx/Apache access log ve WAF/rate limit kontrolü
Günün belli saatlerinde artıyor	Cron/queue job patlaması	`crontab -l`, systemd timers, queue worker ayarı
Günler sonra yavaşlıyor ve CPU dalgalanıyor	Cache yokluğu, DB zorluyor	DB metrikleri: yavaş query ve buffer/cache
Backup, update veya tarama sırasında oluyor	Ağır maintenance işi çakışması	`journalctl`, scheduled task listesi
Container/VPS’te tek kiracı etkileniyor	Yanlış cgroup limiti/overcommit	`docker stats`, cgroup ve provider limitleri

##1. İlk teşhis: CPU’yu kim yiyor, bekliyor mu?

Hızlı teşhis için önce tek seferde “yük nerede?” sorusunun cevabını al.

Hızlı komut seti (Linux)

1) Genel durum: - top -o %CPU - htop (kuruluysa)

2) En çok CPU tüketen süreçler (ilk 10): - ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 11

3) CPU zaman dağılımı (özellikle iowait): - mpstat 1 5 - Yoksa: vmstat 1 5

4) IO bekleme ve disk performansı: - iostat -xz 1 5

5) O anda sistemde çalışan ağ yoğun işleri: - ss -s - ss -tp | head

Net yorumlama kuralı: - top’ta bir PID/komut sürekli %100’e yakın gidiyorsa, bu çoğunlukla “uygulama hatası” veya “ağır job”tur. - vmstat/mpstat’ta iowait belirgin yükseliyorsa, CPU’nun yükselmesi disk/IO darboğazına bağlı dolaylıdır. - Web servislerinde (ör. nginx, apache, php-fpm, node) CPU artışı “tahsilatı” (traffic) ile aynı anda yükseliyorsa, trafik kaynaklıdır.

Kritik kontrol: swap var mı?

Memory baskılanınca sistem swap’a düşer; bu da CPU’yu artırabilir. - free -h - swapon --show

Net aksiyon: Swap kullanımı başlamışsa (özellikle uzun süre), CPU çözümüne girmeden önce memory ve worker planını düzeltmek gerekir.

##2. CPU %100 vakasında süreç/uygulama kaynaklı çözümler

Bu bölümde en sık görülen uygulama nedenlerini “ölç–kes–kalıcı düzelt” mantığıyla ele alıyoruz.

Sonsuz döngü, hatalı retry ve agresif worker

Belirti: - Tek bir servis veya uygulama PID’i sürekli CPU tüketir. - Loglarda “retry”, “timeout”, “reconnect” tekrarları görülür.

Net teşhis: - Uygulama loglarını son 30-60 dakikada filtrele. - Örnek: journalctl -u servisadi --since "30 min ago"

Net çözüm: - Worker sayısını düşür: (ör. queue worker concurrency). - Retry stratejisini sınırla: max deneme ve exponential backoff. - Time-out değerlerini mantıklı hale getir: çok düşük time-out aşırı retry üretir.

PHP-FPM / Node / Java servislerinde yanlış ayar

Belirti: - Nginx/Apache CPU düşer ama php-fpm veya uygulama süreçleri yükselir.

Net kontrol listesi: - PHP-FPM: pm.max_children, pm.max_requests, request_terminate_timeout değerlerini incele. - Node: cluster worker sayısı CPU çekirdeğiyle uyumlu mu? - Java: thread havuzu ve GC logları anormal mi?

Net kural: Uygulama CPU’yu doygun hale getiriyorsa, “daha fazla worker eklemek” genellikle sorunu büyütür. Önce iş yükünü optimize et (query/cache), sonra concurrency artır.

Cron job ve background task patlaması

Belirti: - Her gün aynı saatte CPU yükselir.

Net teşhis: - crontab -l - /etc/cron.* dizinlerini kontrol et - systemd timer varsa: systemctl list-timers

Net çözüm: - Cron işlerini daha düşük öncelik ve sınırlı parallel ile çalıştır. - Aynı anda birden fazla task çakışıyorsa scheduler’ı dağıt. - Büyük işlemleri (tarama, rapor üretimi) parçalara böl.

##3. IO beklemesi (I/O wait) kaynaklı CPU artışı ve depolama çözümleri

Bazen CPU %100 görürsün ama asıl problem disk/IO’dur. Bu durumda “CPU’yu düşürme” değil, IO’yu düzeltme gerekir.

iowait yüksekse: disk doygunluğu ve yavaş storage

Net kontrol: - Disk doluluk: df -h - Dizin bazlı kullanım: du -sh /var/log/* | sort -h | tail - Log şişmesi: CPU yerine disk/IO’yu şişirebilir.

Net çözüm adımları: - Doluluk %80+ ise log rotasyonu ve cleanup uygula. - Zorunluysa log düzeyini düşür. - Provider storage limitlerini incele: bazı VPS’lerde IOPS veya throughput sınırı vardır.

Log yazımı ve sık dosya erişimi

Belirti: - nginx/apache ve uygulama CPU yüksek. - Aynı zamanda log dosyaları hızlı büyüyor.

Net çözüm: - Log formatını optimize et (gereksiz alanları azalt). - Logrotate ile sık rotasyon + kompresyon. - Aşırı access denemelerinde WAF/rate limit devreye sok.

##4. Trafik kaynaklı CPU %100: Bot, DDoS, yanlış cache ve rate limit

CPU artışı kullanıcı trafiğiyle senkron gidiyorsa, kök neden çoğunlukla istek patlaması veya bot saldırısıdır.

Nginx/Apache loglarından kaynak IP ve uç davranışı bul

Net teşhis: - Nginx access log: tail -n 200 /var/log/nginx/access.log - Apache: tail -n 200 /var/log/apache2/access.log - En çok istek yapanları hızlı bul: - awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Çözüm: cache, limit, bot engelleme

Uygulanabilir aksiyonlar: - HTTP cache: Nginx tarafında sayfalar için uygun cache-control ve static varlık cache. - Rate limit: Özellikle login, wp-admin, API endpoint. - Bot yönetimi: Fail2ban veya WAF kuralları. - DDoS için edge koruma: sağlayıcı CDN/WAF kullanıyorsan doğru modda mı?

Net kural: Rate limit eklemeden önce logtan “kimin” yük yaptığını gör. Çünkü rastgele herkese çok katı limit koymak gerçek kullanıcıları da etkiler.

##5. Kalıcı önleme: İzleme, eşikler ve doğru kaynak planı

CPU %100’e “reaksiyon” vermek yerine ölçüme dayalı önleme kurmak gerekir.

Ücretsiz/kolay izleme: CPU, load, disk, ağ

Net uygulanabilir yaklaşım: - CPU: %90 üzeri 5-10 dakikada kalıyorsa alarm - Load average: CPU çekirdeğiyle orantılı eşik - Disk: doluluk %80 üzeri alarm - IO: iowait artışı eşik

Monitoring için araç karşılaştırması (pratik seçim)

İhtiyaç	Önerilen yaklaşım	Neyi ölçer
Basit sistem sağlığı	`node_exporter` + Grafana/Prometheus	CPU, RAM, disk, network
Log odaklı analiz	Loki/ELK benzeri veya sağlayıcı log	Hata, retry, anomali
Hızlı tek bakış	`sar`, `vmstat`, `atop`	Anlık ve kısa süreli inceleme

Eşik ve otomasyon örnekleri

CPU %90 > 10 dk: “top PID” snapshot al + süreç restart dene (uygulama izin veriyorsa)
Disk doluluk %85: log rotasyon/cleanup otomasyonu
iowait yükselmesi: IO darboğazı var mı diye alarm

Net aksiyon: Alarmı sadece “CPU %100” olarak kurma. CPU’nun yanında iowait, disk doluluk ve top PID bilgisini de birlikte topla. Aksi halde aynı alarm her seferinde farklı kök nedenlere işaret eder.

##6. VDS/VPS tarafında sağlayıcı ve sanallaştırma kaynaklı etkiler

CPU %100 bazen kiracının paylaştığı fiziksel kaynaklara ya da yanlış sanallaştırma beklentisine bağlıdır.

KVM/VPS mimarisi ve provider limitleri

Net kontrol: - Provider “CPU burst”, “guaranteed core” veya IOPS/throughput limitleri sunuyor mu? - Aynı pakette kısa süreli burst’ler tükenince CPU performansı düşüyor mu?

Container kullanıyorsan: cgroup etkisi

Belirti: - Host CPU normal ama container CPU “tutuyor” gibi.

Net çözüm: - Container limiti ve request/limit değerlerini kontrol et. - Uygulama worker sayısını limitlere göre ayarla.

Sonuç: CPU %100’te ilk 30 dakikalık net aksiyon planı

CPU %100 sorununda en doğru sıra şudur: Önce top/ps ile yükü hangi PID’nin yaptığını bul, ardından vmstat/mpstat ile iowait var mı netleştir. Trafikle senkron gidiyorsa Nginx/Apache loglarından kaynak davranışı çıkar; IO işaretleri baskınsa disk doluluğu ve depolama/IO limitlerini düzelt. En son adım olarak monitoringde CPU’nun yanına iowait, disk doluluk ve top PID snapshot’larını ekle; böylece bir sonraki CPU artışında körlemesine müdahale etmezsin. Şimdi sunucunda ilk kontrolleri yap: komut setini çalıştır, çıkan en yüksek PID’yi ve iowait durumunu not al; ardından bu yazıdaki ilgili bölüme göre kalıcı çözümü uygula.