Sunucu CPU %100: Sebepler ve Net Çözümler Rehberi (2026)

Sunucu CPU’sunun yüzde 100 çalışması; web sitelerinde yanıt gecikmesi, uygulamalarda zaman aşımı ve bazen de “servis yok” etkisi yaratır. Sorun tek bir nedene indirgenemez: yanlış kaynak planlamasından kötü ayarlı uygulamaya, donanım/IO darboğazından anlık saldırılara kadar uzanır. Bu rehberde, CPU yükselişinin kaynağını sistematik biçimde bulmayı ve kalıcı önlemler almayı öğreneceksiniz. Özellikle VDS/VPS/dedicated sunucularda doğru teşhis + net aksiyon planı kuracağız.

CPU %100 alarmı: Önce “gerçekten” ne oluyor?

CPU yüzde 100 her zaman “donanım arızası” demek değildir. Önce bunun türünü ayırın: sürekli mi, aralıklı mı; belirli bir proses mi; yoksa servis genelinde mi var.

1) Süreklilik ve dalga analizi

• CPU birkaç dakika yükselip düşüyorsa çoğu zaman periyodik görevler (cron, log rotasyon, yedekleme, indeksleme) veya geçici yük dalgası vardır.
• CPU sürekli %90-%100 ise genelde yanlış ölçekleme, limit aşımı, runaway (kaçak) süreç ya da patlayan bir iş kuyruğu söz konusudur.

2) Tek çekirdek mi tüm çekirdekler mi?

Linux’ta çekirdek bazında kontrol kritik bir ayrımdır. - Tek çekirdek yüksekse: tek bir iş/servis yoğun CPU kullanıyor olabilir. - Tüm çekirdekler yüksekse: genellikle çoklu worker’lar, paralel işleme veya saldırı trafiği etkisi vardır.

Not: Aşağıdaki komutlar Linux içindir. Windows tabanlı sunucularda benzer metrikler Event Viewer / Performans İzleyici ile izlenir.

Net teşhis: 15 dakikada kaynağı bulma akışı

Aşağıdaki sırayla ilerleyin. Hedefiniz “CPU’yu kim yiyor?” sorusunu kesin yanıtla kapatmak.

1) Anlık top/htop ile suçluyu yakalayın

Örnek komutlar: - top (en basit) - htop (daha okunur)

Aradığınız metrik: %CPU ile ilk sıradaki proses(ler). Bu noktada 3 bilgi not alın: 1) Proses adı (ör. php-fpm, nginx, mysqld, node, python, java) 2) PID 3) Kullanım deseni (tek proses mi yoksa çok sayıda worker mı?)

2) CPU zamanını hangi süreçler alıyor? (pid bazlı)

pidstat yoksa kurulum gerektirebilir; ancak çoğu ortamda ps ve top yeterlidir. Daha kesin yaklaşım: - PID’den komut satırını görme: ps -p <PID> -o pid,comm,args,%cpu,%mem

Bu adım size şunu söyler: “PHP-FPM işçileri mi yüksek?” yoksa “cron ile çalışan bir PHP betiği mi?”

3) Uygulama logları ile eşleştirin

CPU yükselişiyle aynı zamana denk gelen log satırlarını bulun. - Web sunucusu: Nginx/Apache access + error log - Uygulama: PHP-FPM logları, Node uygulama logları, queue worker logları - Veritabanı: MySQL/MariaDB/PostgreSQL yavaş sorgu logları

Net eşleştirme kuralı: CPU artışı başladığı anda loglarda hangi endpoint / hangi job kuyruğu / hangi SQL çalışıyor?

4) DB tarafında “sorgu fırtınası” var mı?

CPU’yu sıklıkla veritabanı besler. mysqld veya postgres gibi süreçler yüksekse şu kontrolleri yapın: - Yavaş sorgu (slow query) logu aktif mi? - Kilitlenme (lock) veya uzun transaction var mı? - Çok sayıda sorgu aynı tabloyu full scan ediyor mu?

Bu adım, “CPU %100” ile “DB yanlış sorgu” arasındaki bağı netleştirir.

En sık sebepler ve net çözümler

Aşağıdaki başlıklar CPU %100 vakalarının büyük kısmını açıklar. Her biri için “teşhis işareti” ve “net çözüm” verdim.

1) Uygulama tarafı: runaway iş döngüsü veya yanlış worker ayarı

Teşhis işaretleri

• php-fpm, node, python, java gibi uygulama süreçleri ilk sırada.
• Aynı endpoint sürekli çağrılıyor.
• Queue worker sayısı yüksek ama job türleri pahalı (CPU/IO yoğun).

Net çözüm

• Uygulama seviyesinde CPU tüketen döngüyü kapatın: ör. sonsuz retry, bitmeyen döngü, yanlış cron frekansı.
• Worker sayısını sınırlandırın:
• PHP-FPM’de pm.max_children ile aşırı paralelizmi azaltın.
• Node’da cluster/worker konfigürasyonunu CPU çekirdeğiyle eşleyin.
• Worker’ların timeout ve retry politikasını netleştirin.

Kural: “Daha fazla worker ekleyerek” sorun çözülmüyorsa, kök neden genelde hatalı iş/planlamadır; sadece ölçek büyütülür ve CPU daha da kilitlenir.

2) Veritabanı: N+1 sorgu, indeks yokluğu veya sorgu patlaması

Teşhis işaretleri

• mysqld / postgres CPU üst sıralarda.
• Loglarda tek endpoint’e bağlı yüzlerce benzer sorgu.
• Yavaş sorguların (slow queries) sayısı hızla artmış.

Net çözüm

• EXPLAIN/EXPLAIN ANALYZE ile indeks ihtiyacını doğrulayın.
• N+1 sorguları tespit edip tek sorgu/aggregate yaklaşımına geçin.
• Uygulama önbelleği ekleyin (özellikle object cache): aynı veriyi tekrar tekrar DB’den çekmeyin.
• Veritabanı bağlantı havuzu (connection pooling) kullanın; bağlantı fırtınası CPU’yu yükseltir.

3) Web sunucusu ve statik kaynaklar: hatalı cache ve yoğun tekrar

Teşhis işaretleri

• nginx/apache yüksek ama DB/app düşük görünüyor.
• Access log’larda aynı içerik tekrar tekrar isteniyor.
• Cache başlıkları eksik veya yanlış.

Net çözüm

• CDN veya ters proxy cache (varsa) kullanın.
• Static dosalar için doğru cache-control ayarlarını yapın.
• Uygulama kaynaklı olmayan isteklerde rate limit uygulayın.

4) Güvenlik: bot trafiği, brute force, zararlı istekler

Teşhis işaretleri

• Aynı IP aralığından saniyede çok sayıda istek.
• PHP/Node uygulamasının belirli endpoint’lerde CPU tüketmesi.
• 401/403/404 patlaması veya belirgin tarama (scan) deseni.

Net çözüm

• WAF / rate limiting / fail2ban benzeri mekanizmaları devreye alın.
• Şüpheli IP’leri engelleyin; otomatik bloklama için log tabanlı kurallar kullanın.
• Web uygulaması tarafında brute force koruması (login deneme limiti, captcha/step-up) uygulayın.

5) Depolama/IO darboğazı: CPU yüksek gibi görünür ama aslında bekleme vardır

CPU %100, her zaman “CPU gerçekten dolu” demek değildir. Bazı durumlarda uygulama yoğun retry yapar; bu da CPU’yu yükseltir.

Teşhis işaretleri

• Disk IO bekleme artışı (iowait) gözlenir.
• DB veya uygulama aynı anda çok sayıda okuma/yazma yapar.

Net çözüm

• Yavaş disk/IO gecikmesini azaltın: mümkünse NVMe SSD’ye geçin.
• IO yoğun işlerde batch işlemi yapın.
• Yedekleme sırasında performans bozuluyorsa, backup zamanlamasını yeniden planlayın.

6) Otomasyon/cron: yanlış periyotla çalışan işler

Teşhis işaretleri

• CPU artışı her gün/ her saat aynı dakikada başlıyor.
• Belirli bir script/komut çıktısı ile loglarda eş zamanlılık var.

Net çözüm

• Cron job frekansını düşürün, işi chunk’lara bölün.
• Eğer yedek (backup) veya indeksleme aynı zamanlara denk geliyorsa çakışmayı kaldırın.
• Scriptlerde timeout ve concurrency limit uygulayın.

“Net” performans planı: VDS/VPS kaynaklarını doğru eşleştirme

CPU %100 olduğunda ilk refleks “daha büyük paket” yapmak olur. Bu yöntem bazen anlık kurtarır; ama kök nedeni düzeltmezsen yeni sunucuda aynı hata hızlanır.

Aşağıdaki karar tablosu teşhis aşamasında hız kazandırır.

Tek seferlik rahatlatma vs kalıcı çözüm

CPU’yu hemen düşürmek ile kalıcı çözüm farklı iştir.

Hızlı rahatlatma (10-20 dk içinde)

• En yüksek CPU prosesini geçici olarak durdurun/yarım bırakın (ör. hatalı job kuyruğunu askıya alın).
• Traffic anormalse: ilgili endpoint’te geçici rate limit veya geçici IP engeli uygulayın.
• CPU artışı cron ile çakışıyorsa, çakışan işlerden birini erteleyin.

Kalıcı çözüm (gün içinde)

• Kaynağı bulup uygulama/DB yapılandırmasını düzeltin.
• Worker/pool limitlerini gerçek yükle uyumlu hale getirin.
• Cache katmanlarını (özellikle object cache ve HTTP cache) doğru konumlandırın.
• İzleme kurun: CPU, Load Average, DB slow log, uygulama endpoint gecikmesi.

Monitoring olmadan tekrar yakalama zor: Net öneriler

CPU %100 vakaları genelde “bir daha olmayacak” diye bitmez. Tekrarlamayı erken yakalamak için şu metrikleri izleyin:

• Sunucu CPU kullanımı (ortalama + tepe)
• Load Average (Linux)
• DB için slow query sayısı ve en yavaş sorgular
• Uygulama için queue uzunluğu / worker retry sayısı
• Nginx/Apache access’te hata oranı (401/403/429 patlıyor mu?)

İzleme eşiği örneği (pratik): - CPU %85’i 5 dakikadan uzun sürüyorsa alarm oluşturun. - CPU %95+ oluyorsa otomatik “incident bilgisi” toplayın: en yüksek proses, en yavaş endpoint, DB slow snapshot.

Sonuç: CPU %100’ü rastgele çözmeyin, kaynağı kapatın

Sunucu CPU’su yüzde 100 olduğunda en doğru yaklaşım “önce kaynağı bul, sonra yapılandırmayı düzelt, en son ölçekle” sırasıdır. Bu rehberdeki teşhis akışını kullanarak 15 dakikada hangi prosesin CPU’yu tükettiğini belirleyin; ardından log + DB/endpoint eşleştirmesiyle kalıcı çözümü uygulayın. Eğer aynı sorun 24 saat içinde tekrar ediyorsa, kök neden genellikle uygulama/DB ayarındadır; o ayarı düzeltmeden yalnızca paket büyütmek tekrarın önünü kesmez. Hemen bugün: CPU artış saatini not edin, logları o zamana göre eşleştirin ve ilk suçluyu (en yüksek CPU prosesini) net olarak kaydedin.