Sunucu CPU %100: Sebepler, teşhis ve kalıcı çözümler

Sunucu CPU kullanımının %100 seviyesine çıkması, yalnızca performans düşüşü demek değildir; aynı zamanda oturumların yavaşlaması, zaman aşımı (timeout), hatta servis kesintisi riskini artırır. Bu rehberde CPU %100 durumunun en yaygın sebeplerini (Linux/Windows, web sunucusu, veritabanı, task’ler ve ağ etkileri dâhil) nasıl tespit edeceğinizi ve kalıcı çözümleri nasıl uygulayacağınızı öğreneceksiniz. Hedefimiz, NetKıyas’ta karar verirken de kullanabileceğiniz net bir kontrol çerçevesi vermek.

CPU %100 alarmı neyi gösterir?

CPU %100 genellikle sunucuda “çalışacak iş”in CPU’nun kaldırabileceğinden fazla olduğunu anlatır. Bu durum kaynakların tek bir süreçte yoğunlaşmasından (ör. veritabanı sorguları), yoksa genel yük artışından (ör. çok fazla eşzamanlı istek) kaynaklanabilir.

CPU %100 ile ilgili kritik fark: Bazı sistemler “anlık pik” üretir, fakat bu pik kısa sürüp düşüyorsa sorun olmayabilir. Asıl problem, CPU’nun uzun süre (ör. 5-15 dakika ve üzeri) yüksek kalması ve servisin yanıt sürelerini bozmaya başlamasıdır.

Hızlı ayrım: CPU mu, I/O mu?

CPU %100 görmeniz, sorunun CPU olduğu anlamına gelmez. Disk/IO beklemeleri de bazı süreçleri CPU döngüsüne sokabilir. Bu yüzden teşhiste sadece CPU’ya değil şu metriklere de bakın: - RAM kullanımı ve swapping (swap alanı kullanımı) - Disk I/O bekleme (wait) ve iostat benzeri metrikler - Veritabanı sorgu süreleri ve kilit (lock) - Web sunucusu kuyrukları ve istek oranları

En sık sebepler: CPU’yu %100’e çıkaran gerçek kaynaklar

Aşağıdaki liste, pratikte en çok görülen kök nedenleri önceliklendirir. Her madde için “teşhis nasıl yapılır?” kısmına doğrudan gireceksiniz.

1) Tek bir süreç CPU’yu ele geçiriyor (process spike)

Örnekler: - PHP-FPM worker’larının kilitlenmesi veya hatalı döngü - Çok pahalı bir cron job - Yanlış yapılandırılmış cache temizleme işlemi - Log parselayan araçların (örn. tarama/işleme) kontrolsüz çalışması

2) Veritabanı darboğazı (MySQL/MariaDB/PostgreSQL)

Örnekler: - İndekslenmemiş sorgular - Büyük tablolar üzerinde tam tarama (full scan) - Bağlantı havuzu/limit sorunu - Otomatik bakım (OPTIMIZE, VACUUM, ANALYZE) yanlış saatlerde çalışması

3) Web sunucusu aşırı istek veya yanlış ayar

Örnekler: - Trafik artışı: aniden yükselen bot trafiği - WAF/anti-bot devre dışı veya yetersiz - Keep-Alive / worker ayarları yanlış - Çok ağır dosyaların (ör. büyük görseller) her istekle yeniden işlenmesi

4) WordPress eklentisi/tema kaynaklı döngü veya tarama

Örnekler: - Cache eklentisi ile CDN/edge cache çakışması - Kötü yazılmış cron “traffic” üretir - Güncelleme sonrası geride kalan eski job’lar - WooCommerce/arama eklentisi sorguları

5) Disk/IO beklemeleri: CPU döngüye giriyor

Örnekler: - yavaş disk (özellikle paylaşımlı veya düşük IOPS katmanı) - çok küçük /tmp veya cache dizininde taşma - yüksek sayıda küçük dosya işlemi

6) Swap kullanımı ve bellek basıncı

RAM yetersizliğinde swap devreye girer. Swap hem performansı düşürür hem de CPU’nun “kısır döngü” gibi çalışmasına yol açabilir.

7) Güvenlik olayları: botlar, brute-force, tarama

CPU’yu doğrudan artıran şeyler: - log yazımı (özellikle disk dolumu riski) - şifre denemeleri ve banlama mekanizmalarının geç devreye girmesi - kötü niyetli isteklerin uygulama katmanına düşmesi

Teşhis: 15-30 dakikada kök nedeni bulma planı

Bu bölüm “önce ölç, sonra müdahale et” yaklaşımını takip eder. Mantık: CPU %100 gördüğünde hedefiniz, hangi metrik ve hangi süreç sorumluluğu aldığını netleştirmektir.

1) CPU’yu hangi süreç yükseltiyor? (Linux)

Önce top/ps ile süreçleri izleyin: - top veya htop - CPU’ya göre sıralama: en yüksek CPU’lu 3-5 süreç

Ardından detay: - ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -n 15

Burada en kritik çıktı şudur: %100’ü “tek bir PID” mi yapıyor, yoksa çok sayıda süreç mi yayıyor?

2) Linux’ta genel yük dağılımı ve I/O bekleme

Şu komutlar, CPU’nun “busy” mi yoksa “wait” mi olduğunu ayırmanıza yardım eder: - iostat -x 1 - vmstat 1

Eğer CPU bekleme (iowait) anlamlıysa kök neden büyük ihtimalle disk/IO’dur. Bu durumda yalnızca CPU limitine yüklenmek çözüm vermez.

3) Veritabanı tarafını kontrol et

MySQL/MariaDB için tipik kontrol başlıkları: - En uzun süreliler (long running queries) - Çok sık gelen yavaş sorgular - Bağlantı sayısı ve lock oranı

Pratikte en hızlı yol: DB panelinde ya da yönetim arayüzünde “slow query log” ve son 30 dakikalık sorgu listesine bakmaktır. İndeks ihtiyacı varsa CPU artışı bir “semptom” olur.

4) Web sunucusu (Apache/Nginx) ve uygulama katmanı

Apache için mod_status veya erişim loglarından: - 4xx/5xx oranı - istek başı süre (TTFB/response time) - belirli endpoint yoğunluğu

Nginx için benzer şekilde: - upstream time - worker busy oranları

Uygulama katmanında (PHP/Node) en çok CPU tüketen worker’lar/threads belirlenir.

5) Log analizi: CPU’yu artıran tetikleyiciyi bul

Şu iki log kritik: - uygulama logları (örn. PHP error log) - access log + hata logları

Özellikle “belli bir IP aralığı” veya “belli bir URL” yoğunluğu varsa bot etkisi düşünün. Güvenlik tarafı ayrıca değerlendirilmeli.

Çözümler: Tek seferlik müdahale değil, kalıcı plan

Aşağıdaki çözümler, kök neden bulduğunuzda hızlı şekilde uygulanan net adımlardır. “Hangi durumda hangisi?” sırası önemlidir.

1) Tek süreç yüksekse: hatalı job/worker’ı izole et

• CPU’yu yükselten PID’yi durdurup (servisi kısmen kesmeden) hangi bileşen olduğunu tespit edin.
• Büyük olasılıkla cron job, PHP-FPM worker, arka plan script’i veya queue worker’dır.

Kalıcı önlem: - Cron’ları tekrar planlayın (işi yoğun saat dışına alın) - Süre/limit koyun (ör. maksimum çalışma süresi) - Hatalı döngü yapan script’i düzeltin

2) DB kaynaklıysa: sorgu + indeks + bağlantı optimizasyonu

Net uygulanabilir adımlar: - Slow query log’tan ilk 10 sorguyu çıkarın - Her bir sorgu için eksik indeks var mı kontrol edin - Çok sık gelen sorgular için uygun indeks oluşturun - Bağlantı limitlerini ve pool ayarlarını gözden geçirin

Önemli nokta: DB CPU’su yüksekse ve sorgu maliyeti düşmezse sadece daha güçlü CPU almak geçici rahatlatır.

3) Web katmanı aşırı istek alıyorsa: kapasite + koruma + cache

Kalıcı çözüm paketi: - Cache katmanını netleştirin (sayfa cache + obje cache) - Statik içerikler için uygun cache header ayarlayın - Bot trafiği için rate limit ve gerekirse ban kuralları uygulayın - WAF/anti-DDoS katmanını etkinleştirin

4) WordPress eklentisi yüzünden oluyorsa: eklentiyi “tek tek” doğrulayın

Net teşhis metodu: - Son eklenen/son güncellenen eklentileri sırayla devre dışı bırakın - Cache eklentisi + optimizasyon eklentisi çakışmasını giderin - WP-Cron tetiklemelerini düzenleyin (trafik yerine belirli aralıklarla)

Kalıcı önlem: - Eklentileri “en az paket” yaklaşımıyla sadeleştirin - Dış API çağıran eklentilerde zaman aşımı ve retry sayısını sınırlayın

5) I/O kaynaklıysa: disk/IO katmanını düzeltin (CPU artırmak tek başına çözmez)

Somut kontrol: - iowait anlamlı mı? - disk gecikmesi artıyor mu? - yoğun anda disk throughput düşüyor mu?

Çözüm seçenekleri: - Daha yüksek performanslı storage (IOPS/throughput) seçin - Gereksiz log ve dosya birikimini temizleyin - tmp/cache dizinlerini doğru boyutla yapılandırın

6) Swap kullanımı varsa: RAM’i ve bellek ayarlarını düzeltin

• Swap kullanımını izleyin
• Gerekiyorsa RAM’i artırın
• Uygulamanın memory limitlerini (ör. PHP memory_limit) doğru ayarlayın

Swap’ın “sürekli çalışır” hale gelmesi kalıcı problemdir.

7) Güvenlik kaynaklıysa: istekleri uygulama öncesinde durdurun

• Brute-force denemeleri için doğru throttle/ban mekanizması kurun
• Şüpheli IP/ülke trafiğini WAF seviyesinde sınırlayın
• Log yazımını yönetin; disk dolmasını önleyin

NetKıyas yaklaşımı: CPU %100’de sağlayıcı/plan seçimi nasıl yapılır?

CPU %100 sorunu bazen uygulama hatasıdır, bazen de seçilen planın kapasitesi yetersizdir. Kararı desteklemek için NetKıyas’ta şu kontrol ölçütleriyle ilerleyin.

Karar tablosu: hangi metrik hangi seçimi işaret eder?

Plan seçerken bakılması gereken teknik başlıklar

• IOPS ve disk gecikmesi (CPU’yu dolaylı etkiler)
• CPU garantisi/oversell yaklaşımı (paylaşımlı kaynaklarda dalgalanma)
• VDS/VPS’te CPU throttling var mı (olası limitler)
• Network kapasitesi (yüksek gecikme uygulamayı yavaşlatır)
• Kontrol paneli ve metrik erişimi (CPU/IO metriklerini hızlı görme)
• Yedekleme (backup) ve yeniden kurulum kolaylığı (hızlı toparlanma)

Aşırı CPU’yu önleyen pratik önlemler listesi

Sorun çıktıktan sonra çözmek yerine, aşağıdaki önlemler CPU %100 tekrarını ciddi şekilde azaltır.

• Cron işlerini kademeli çalıştırın (aynı anda birden fazla iş tetiklenmesin)
• Log rotasyonunu etkinleştirin; disk dolması riskini ortadan kaldırın
• Uygulama tarafında timeout ve retry limitleri koyun
• Cache’te “invalidate” sıklığını kontrol edin (gereksiz temizleme CPU’yu artırır)
• Veritabanında periyodik indeks/istatistik bakımını planlayın
• Trafik botlarını uygulama katmanına düşürmemek için WAF/rate limit kullanın

Sonuç: CPU %100’te ilk aksiyon ölçmek, ikinci aksiyon düzeltmek

Sunucunuz CPU’yu %100 seviyesinde tutuyorsa tek bir “daha güçlü CPU” hamlesi çoğu zaman yeterli olmaz. Önce hangi süreç ve hangi katman (DB, web, uygulama, I/O, güvenlik) sorumludur onu 15-30 dakikada netleştirin; ardından kök nedene yönelik kalıcı düzeltmeyi uygulayın. Aksiyon planı hazır olduğunda (özellikle depolama/IOPS veya DB optimizasyonu gerekip gerekmediği netleştiğinde) NetKıyas üzerinden karşılaştırmalı şekilde bir VDS/VPS planını kapasite ve metriklerine göre seçin.