Site yavaşladı, SSH komutları geç yanıt veriyor ve izleme aracınız CPU'nun yüzde 100'e dayandığını söylüyor. Bu noktada yapılacak ilk iş sunucuyu yeniden başlatmak değil, CPU'yu hangi sürecin ve hatta o sürecin hangi iş parçacığının (thread) kullandığını bulmaktır. Yeniden başlatma birkaç saat kazandırır; neden bulunmazsa sorun geri gelir.
Bu rehberde top, htop, ps ve pidstat ile CPU tüketen süreci bulmayı, iş parçacığı bazında inceleme yapmayı, rakamların ne anlama geldiğini, PHP-FPM, MySQL ve Node.js için tipik senaryoları ve tanımadığınız bir süreç gördüğünüzde nasıl davranmanız gerektiğini anlatıyoruz. Komutlar Ubuntu 24.04 LTS içindir.
Önce doğrulayın: gerçekten CPU mu?
"Sunucu yavaş" her zaman CPU demek değildir. Load average yüksek olabilir ama neden disk beklemesi olabilir. Önce top açın ve %Cpu(s) satırına bakın:
| Gözlem | Muhtemel neden | Nereye bakmalı |
|---|---|---|
us yüksek | Uygulama kodu (PHP, Node, Python, veritabanı) | Bu yazı |
sy yüksek | Çekirdek işi: çok sayıda sistem çağrısı, bağlantı, bağlam değişimi | Bu yazı + ağ trafiği |
wa yüksek, us düşük | Disk G/Ç beklemesi | load average rehberi |
st yüksek | Sanal CPU'nun fiziksel işlemciyi beklemesi | Sağlayıcı desteği |
si/so hareketli (vmstat) | RAM yetersiz, swap kullanımı | OOM killer rehberi |
Çekirdek başına durumu görmek için top içinde 1 tuşuna basın. Tek bir çekirdek yüzde 100 ve diğerleri boşsa, tek iş parçacıklı bir süreç (örneğin tek bir Node.js süreci veya tek bir ağır sorgu) sorumlu olabilir.
Adım 1: top ve htop ile süreci bulun
top # P: CPU'ya göre sırala, M: belleğe göre, 1: çekirdek başına
top -o %CPU # doğrudan CPU'ya göre sıralı başlat
sudo apt install htop && htoptop(1) kılavuzuna göre çok çekirdekli sistemlerde, iş parçacığı modunda değilken çok iş parçacıklı bir sürecin %CPU değeri yüzde 100'ü aşabilir. Yani 4 çekirdekli bir sunucuda bir sürecin yüzde 380 görünmesi, yaklaşık 4 çekirdeği birden kullandığı anlamına gelir; bu bir hata değildir. I tuşu (Irix modu) bu gösterimi değiştirir.
Anlık bir görüntüyü dosyaya kaydetmek (örneğin destek talebine eklemek) için top'u toplu (batch) modda çalıştırın:
top -b -n 1 -o %CPU | head -n 25 > ~/cpu-$(date +%F-%H%M).txtAdım 2: ps ile sıralı liste
ps(1) ile tüm süreçleri CPU'ya göre sıralayabilirsiniz:
ps -eo pid,ppid,user,%cpu,%mem,etime,stat,cmd --sort=-%cpu | head -n 15Adım 3: pidstat ile zaman aralıklı ölçüm
pidstat, sysstat paketinin parçasıdır ve belirli aralıklarla süreç bazında ölçüm yapar. Ubuntu 24.04 pidstat(1) sayfasındaki örneklere göre:
sudo apt install sysstat
pidstat 2 5 # 2 sn arayla 5 rapor, tüm aktif süreçler
pidstat -u -p 1234 2 5 # yalnızca PID 1234
pidstat -t -p 1234 2 5 # PID 1234 ve iş parçacıkları
pidstat -l 2 5 # komutu tüm argümanlarıyla göster| Sütun | Anlamı |
|---|---|
%usr | Sürecin kullanıcı seviyesinde (uygulama kodu) harcadığı CPU yüzdesi |
%system | Çekirdek seviyesinde harcanan CPU yüzdesi |
%wait | Sürecin çalışmak için sıra beklediği zamanın yüzdesi |
%CPU | Toplam CPU yüzdesi (çok çekirdekte yüzde 100'ü aşabilir) |
%wait belirgin şekilde yüksekse süreç CPU bulamıyordur; yani sunucudaki toplam talep, çekirdek sayısını aşmaktadır.
Adım 4: İş parçacığı bazında inceleme
MySQL, Java veya PHP-FPM gibi programlarda sorunlu kısım tek bir iş parçacığı olabilir. top(1) kılavuzuna göre -H seçeneği veya top içindeki H tuşu iş parçacıklarını ayrı ayrı gösterir:
top -H -p 1234
ps -L -o pid,lwp,%cpu,stat,comm -p 1234 --sort=-%cpu | headBurada LWP, iş parçacığının kimliğidir. MySQL'de bu bilgi, hangi bağlantının veya arka plan işinin CPU kullandığını bulmak için başlangıç noktasıdır.
Sık senaryolar
PHP-FPM süreçleri CPU'yu dolduruyor
Çok sayıda php-fpm: pool www süreci CPU'yu paylaşıyorsa ya trafik gerçekten arttı, ya bot trafiği var, ya da yavaş bir sayfa/eklenti her istekte ağır iş yapıyor. PHP Manual: FPM yapılandırması belgesine göre request_slowlog_timeout ile belirli süreyi aşan isteklerin PHP backtrace'i slowlog dosyasına yazılır; pm.status_path ile havuzun durum sayfası açılabilir (varsayılan olarak ikisi de kapalıdır). Havuz ayarı:
; /etc/php/8.3/fpm/pool.d/www.conf (sürüm numarası sizde farklı olabilir)
request_slowlog_timeout = 5s
slowlog = /var/log/php8.3-fpm-slow.log
pm.status_path = /fpm-durumsudo systemctl reload php8.3-fpm
sudo tail -f /var/log/php8.3-fpm-slow.log
# Hangi URL'lerin yoğun istendiğini Nginx erişim logundan görün:
sudo awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | headpm.max_children değerini artırmak CPU sorununu çözmez; yalnızca aynı anda daha fazla işçinin CPU için yarışmasına yol açar. Havuz boyutlandırması için PHP-FPM yapılandırma yazısına bakın.
MySQL / MariaDB CPU kullanıyor
mysqld veya mariadbd listenin başındaysa çoğu zaman neden indekssiz veya kötü yazılmış sorgulardır. Çalışan sorguları görün:
sudo mysql -e "SHOW FULL PROCESSLIST;"Uzun süredir Query durumunda bekleyen aynı tür sorgular, hangi tabloya indeks gerektiğini gösterir. Veritabanı temelleri için MySQL nedir yazısını, önbellekleme ile veritabanı yükünü azaltmak için Redis rehberini inceleyebilirsiniz.
Node.js süreci tek çekirdeği yüzde 100 kullanıyor
Node.js uygulama kodunu tek bir ana iş parçacığında çalıştırır. Bu nedenle tek çekirdeğin yüzde 100 olması, olay döngüsünü (event loop) bloklayan senkron bir iş (büyük JSON işleme, senkron dosya işlemleri, sonsuz döngü) olduğuna işaret edebilir. Çok çekirdeği kullanmak için cluster modu ve PM2 seçenekleri Node.js cluster ve PM2 yazısında anlatılıyor.
Tanımadığınız bir süreç CPU'yu yakıyor
Adı anlamsız, /tmp, /dev/shm veya /var/tmp altından çalışan, sizin kurmadığınız ve sürekli yüksek CPU kullanan bir süreç görüyorsanız, bunu kötü amaçlı süreç olarak değerlendirin. Önce bilgi toplayın, sonra müdahale edin:
PID=1234
sudo ls -l /proc/$PID/exe # çalışan dosyanın gerçek yolu
sudo tr '\0' ' ' < /proc/$PID/cmdline; echo
ps -o user,ppid,lstart,cmd -p $PID
sudo ss -tnp | grep "pid=$PID" # açık ağ bağlantıları
sudo crontab -l; sudo ls /etc/cron.d/ ; crontab -lGeçici müdahale: nice ve renice
Kritik olmayan bir işi (yedekleme, sıkıştırma, rapor üretimi) durdurmak yerine önceliğini düşürebilirsiniz. Nice değeri yükseldikçe süreç CPU için daha az öncelik alır:
nice -n 19 tar -czf /yedek/site.tar.gz /var/www/site # düşük öncelikle başlat
sudo renice -n 19 -p 1234 # çalışan süreci düşürÖnleme
- CPU, load ve süreç sayısını sürekli kaydedin; sorun anına geri dönüp bakabilmek, anlık müdahaleden daha değerlidir. Sunucu izleme temelleri ve Prometheus ve Grafana.
- Site erişilebilirliğini ayrı bir sunucudan izleyin: Uptime Kuma kurulumu.
- Ağır cron işlerini düşük trafikli saatlere alın ve
niceile çalıştırın. - Bellek baskısı CPU'yu da etkiler; swap fırtınası ve OOM için OOM killer rehberi.
- Sistem paketlerini ve uygulamalarınızı güncel tutun; bilinen açıklar kötü amaçlı süreçlerin en yaygın giriş yoludur.
Sık Sorulan Sorular
top yüzde 400 gösteriyor, bu mümkün mü?
Evet. Çok çekirdekli bir sistemde çok iş parçacıklı bir süreç birden fazla çekirdeği aynı anda kullanabilir; top bunu toplayarak gösterir. 4 çekirdekte yüzde 400 yaklaşık tam doluluktur.
ps ve top neden farklı CPU değeri gösteriyor?
ps sürecin tüm ömrü boyunca ortalamasını, top ise son yenileme aralığını gösterir. Şu anki sorunu bulmak için top veya pidstat daha doğrudur.
CPU yüzde 100 olması her zaman kötü mü?
Hayır. Kısa süreli tam kullanım (derleme, yedek sıkıştırma, trafik sıçraması) normaldir. Sorun, yüksek kullanımın uzun sürmesi ve yanıt sürelerini, hata oranlarını etkilemesidir. Sitede 502 veya 504 hataları görüyorsanız arka uç süreçler zamanında yanıt veremiyordur.
steal (st) değeri yüksek, ne yapmalıyım?
Steal, hipervizörün sanal CPU'nuza fiziksel işlemci veremediği süredir ve sunucu içinden düzeltilemez. Değerleri zaman damgasıyla kaydedip sağlayıcınızın destek ekibine iletin.
Yazılım ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen projeler veya şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.
İlgili içerikler: Load average nedir · OOM killer çözümü · logrotate rehberi · Uptime Kuma kurulumu · PHP-FPM yapılandırma · VPS güvenlik sertleştirme · Sunucu izleme temelleri