%100 CPU Kullanımı Sorunu Nasıl Çözülür? Linux Optimizasyonu

Giriş: Linux Sunucularda CPU Darboğazının Anlamı ve İşletmenize Etkileri

Kurumsal BT altyapılarında Linux işletim sistemleri; kararlılıkları, güvenlik mimarileri ve yüksek performansları nedeniyle açık ara en çok tercih edilen sistemlerdir. Ancak en optimize edilmiş Linux dağıtımlarında bile zaman zaman donanım kaynaklarının tamamen tükenmesiyle karşılaşılabilir. Bu sorunların en kritik olanı ve sistem yöneticilerinin (Sysadmin) en hızlı müdahale etmesi gereken durum, %100 CPU kullanımı sorunudur.

Merkezi İşlem Birimi (CPU), sunucunuza gelen her isteği, çalışan her scripti ve veri tabanındaki her sorguyu işleyen ana motordur. Bu motorun %100 doluluk oranına ulaşması, sunucunun yeni gelen taleplere yanıt verememesi, zaman aşımı (Timeout) hatalarının oluşması ve nihayetinde web sitelerinin veya kurumsal servislerin (ERP, CRM, Mail sunucuları) tamamen erişilemez hale gelmesi anlamına gelir. Dijital dünyada saniyelerin bile ciro kaybına yol açtığı 2026 yılı standartlarında, CPU kilitlenmelerini hızlıca teşhis etmek ve kalıcı olarak optimize etmek bir lüks değil, operasyonel zorunluluktur.

Linux’ta %100 CPU Kullanımının Temel Nedenleri

Sistem optimizasyonuna geçmeden önce, işlemciyi tüketen anomalilerin kaynağını doğru tespit etmek gerekir. Linux mimarisinde CPU darboğazları genellikle şu dört ana başlık altında toplanır:

1. Kötü Optimize Edilmiş Veri Tabanı Sorguları: İndekslenmemiş tablolar üzerinde çalışan devasa SQL sorguları, işlemci çekirdeklerini milisaniyeler yerine dakikalarca meşgul edebilir.
2. Yazılımsal Sonsuz Döngüler (Infinite Loops): PHP, Python, Node.js veya Java ile geliştirilen uygulamalardaki mantık hataları, bir sürecin (process) sonsuz döngüye girmesine ve tek başına bir çekirdeği tamamen tüketmesine yol açar.
3. Siber Saldırılar ve Zararlı Trafik: Katman 7 (Application Layer) seviyesindeki HTTP Flood veya kaba kuvvet (Brute Force) saldırıları, web sunucusunun (Nginx, Apache) işlem kapasitesini aşarak CPU’yu kilitler.
4. Zombi ve Yetim Süreçler (Zombie & Orphan Processes): Üst süreçleri (Parent Process) kapandığı halde arka planda RAM ve CPU döngülerini işgal etmeye devam eden başıboş süreç birikimidir.

Adım Adım CPU Sorunu Teşhis ve İzleme Protokolü

Linux tabanlı bir sunucuda işlemci krizini çözmek için sistem mühendislerinin uyguladığı hiyerarşik bir teşhis protokolü mevcuttur. Terminal üzerinden gerçekleştireceğiniz bu adımlar, sorunun kaynağını doğrudan gözler önüne serecektir.

top ve htop ile Canlı Sistem İzleme

Sunucunuza SSH üzerinden bağlandığınızda çalıştırmanız gereken ilk komut top veya daha görsel ve gelişmiş bir versiyonu olan htop olmalıdır. Eğer sunucunuzda htop yüklü değilse, dağıtımınıza uygun olarak apt install htop veya yum install htop komutuyla hızlıca kurabilirsiniz.

htop

htop

htop arayüzünde en üstte bulunan çubuklar, her bir CPU çekirdeğinin doluluk oranını renk kodlarıyla gösterir. Alt kısımda ise çalışan süreçlerin listesi yer alır. Süreçleri CPU tüketimine göre sıralamak için klavyeden P tuşuna basabilir veya farenizle %CPU sütununa tıklayabilirsiniz. Bu ekranda, en üstte yer alan ve %90’ın üzerinde CPU tüketen süreçlerin PID (Process ID) numarasını ve hangi kullanıcı (User) tarafından çalıştırıldığını not etmelisiniz.

ps Komutu ile Sorunlu Süreçleri Detaylandırma

Anlık dalgalanmaları filtrelemek ve arka planda en çok CPU tüketen ilk 10 süreci net bir liste halinde dökümlemek için gelişmiş ps kombinasyonunu kullanabilirsiniz:

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 11

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 11

Bu komut size PID, Üst PID (PPID), komut yolu, CPU yüzdesi ve RAM yüzdesi bilgilerini içeren temiz bir tablo sunacaktır. Buradaki çıktı sayesinde, sorunun bir sistem servisinden mi (örneğin mysqld) yoksa bir kullanıcı scriptinden mi kaynaklandığını kesinleştirirsiniz.

strace ve lsof ile Derinlemesine Sistem Analizi

Eğer sorun yaratan sürecin hangi dosyaya eriştiğini veya arka planda hangi sistem çağrılarını (system calls) yaptığını anlamak istiyorsanız, strace aracı en büyük yardımcınızdır. Örneğin, PID numarası 4231 olan yüksek CPU tüketen bir süreci incelemek için:

strace -p 4231 -c

strace -p 4231 -c

Bu komut, sürecin yaptığı sistem çağrılarının istatistiksel bir özetini çıkarır. Eğer süreç sürekli read veya write yapıyorsa, bir disk darboğazı veya büyük dosya işleme sorunu vardır. Sürecin hangi açık dosyaları veya network portlarını kullandığını görmek için ise şu komut çalıştırılmalıdır:

lsof -p 4231

lsof -p 4231

En Sık Karşılaşılan CPU Canavarları ve Çözüm Yolları

1. Veri Tabanı (MySQL / MariaDB) Optimizasyonu

Eğer listede en üstte mysqld sürecini görüyorsanız, veri tabanınız alarm veriyor demektir. İlk yardım olarak yavaş sorguları (Slow Queries) yakalamanız gerekir. /etc/mysql/my.cnf dosyasına giderek yavaş sorgu günlüğünü aktif edin:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-queries.log
long_query_time = 2

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-queries.log
long_query_time = 2

Bu ayar, 2 saniyeden uzun süren tüm sorguları kaydedecektir. Ardından mysqltuner scriptini çalıştırarak veri tabanı önbellek (InnoDb Buffer Pool, Query Cache) optimizasyon önerilerini uygulayabilirsiniz.

2. Kötü Niyetli Süreçlerin Sonlandırılması (Sinyal Yönetimi)

Eğer bir scriptin sistemi kilitlediğinden eminseniz ve bu süreç sistem için kritik bir servis değilse, süreci sonlandırmanız gerekir. Yumuşak sonlandırma sinyali (SIGTERM) için:

kill 4231

kill 4231

Eğer süreç bu sinyale yanıt vermiyorsa, zorla sonlandırma sinyali (SIGKILL) gönderilmelidir:

kill -9 4231

kill -9 4231

Gelişmiş Linux Çekirdek (Kernel) ve Kaynak Optimizasyonu

Sorun anlık olarak çözüldükten sonra, gelecekte oluşabilecek kilitlenmeleri önlemek adına Linux çekirdeğinde ve kaynak sınırlandırma mekanizmalarında kalıcı iyileştirmeler yapılmalıdır.

sysctl.conf İnce Ayarları

Ağ trafiği ve bellek yönetimi nedeniyle CPU’nun aşırı yüklenmesini engellemek için /etc/sysctl.conf dosyasına şu parametreler eklenerek network yığını (network stack) optimize edilebilir:

# Ağ arabellek boyutlarını optimize etme
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Zaman aşımına uğramış bağlantıların hızlıca kapatılması
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# Ağ arabellek boyutlarını optimize etme
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Zaman aşımına uğramış bağlantıların hızlıca kapatılması
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

Değişiklikleri kaydettikten sonra sysctl -p komutu ile ayarları canlıya alabilirsiniz.

systemd ile Servis Seviyesinde CPU Sınırlandırma (CGroups)

Belirli bir servisin (örneğin Apache web sunucusunun) sistemdeki tüm CPU kaynaklarını tüketmesini engellemek için Linux’un Control Groups (CGroups) mimarisinden yararlanabilirsiniz. İlgili servisin systemd unit dosyasına (/lib/systemd/system/apache2.service) şu satırları ekleyerek o servisin toplam CPU’nun en fazla %60’ını kullanmasını sağlayabilirsiniz:

[Service]
CPUAccounting=true
CPUQuota=60%

[Service]
CPUAccounting=true
CPUQuota=60%

Donanım ve Altyapı Faktörü: Hostider Güvencesi

Yazılımsal olarak ne kadar optimizasyon yaparsanız yapın, eğer kullandığınız sunucu altyapısı “Overselling” (aşırı satım) yapılan, eski nesil işlemcilere sahip paylaşımlı bir yapıdaysa, CPU kilitlenmelerinden kaçınmanız imkansızdır. Sanal sunucunun barındığı fiziksel sunucunun ve disk altyapısının kalitesi, optimizasyonun temel direğidir.

Aşağıdaki tabloda, optimize edilmemiş geleneksel altyapılar ile Hostider’ın kurumsal sanal sunucu (VDS) mimarisi arasındaki farklar net bir şekilde ortaya konmuştur:

Hostider Bilişim Hizmetleri olarak, BTK lisanslı altyapımızda sunduğumuz tüm VDS (Virtual Dedicated Server) paketlerinde, müşterilerimize donanımsal olarak mühürlenmiş işlemci çekirdekleri tahsis ediyoruz. Bu sayede, diğer sanal sunucuların yoğunluğu sizin işlemci performansınızı asla etkilemez. Ayrıca, Layer 7 seviyesindeki bot ve DDoS saldırıları daha sizin işletim sisteminize ulaşıp CPU’nuzu %100 seviyesine getirmeden, Hostider’ın gelişmiş donanımsal siber güvenlik katmanlarında filtrelenir. NVMe SSD disklerimizin sunduğu ultra yüksek okuma/yazma (IOPS) değerleri ise işlemcinin diskten veri beklerken (I/O Wait) harcadığı atıl CPU döngülerini sıfıra indirir.

Sonuç ve Kurumsal Eylem Çağrısı (CTA)

Linux sunucularda %100 CPU kullanımı sorunu, doğru teşhis araçları ve sistem seviyesinde uygulanan optimizasyon politikaları ile kontrol altına alınabilir bir durumdur. Ancak sürdürülebilir bir dijital operasyon için yazılımsal optimizasyon, güçlü ve izole bir donanım altyapısı ile taçlandırılmalıdır. Altyapı kaynaklı performans kayıplarını hayatınızdan tamamen çıkarmak, projenizin milisaniyeler içinde yanıt vermesini sağlamak ve siber tehditlere karşı sunucunuzu güvence altına almak sizin elinizde.

Kurumsal iş yükleriniz için özel olarak optimize edilmiş, AMD EPYC işlemci gücüne ve kesintisiz uptime garantisine sahip donanımsal izole sunucularımızı keşfedin. Projenize en uygun altyapıyı seçmek ve yüksek performans dünyasına adım atmak için hemen [Hostider VDS Sunucu Çözümlerini] inceleyin ve profesyonel ekosistemimize dahil olun!