Sunucu Yavaşladı: Darboğazı 15 Dakikada Bulma (CPU, RAM, Disk, Ağ)

Yavaşlayan bir Linux sunucuda önce top ile load average'ı çekirdek sayısıyla karşılaştırın ve CPU satırındaki wa (disk bekleme) ile st (sanallaştırma kaynaklı bekleme) değerlerine bakın. Ardından free ve vmstat ile swap kullanımını, iostat ile disk gecikmesini, ss ile bağlantı sayısını kontrol edin. Hangi kaynak doygunsa darboğaz odur; çözüm o katmanda aranır.

Aşağıdaki akış bu kontrolleri zaman kutularına bölerek yaklaşık 15 dakikada bitirmenizi sağlar. Mantığı USE yöntemine dayanır: her kaynak için kullanım (utilization), doygunluk (saturation) ve hata (errors) kontrol edilir. Sorunu kalıcı olarak çözmek için işi bir ekibe bırakmak isterseniz tek seferlik sunucu optimizasyonu için teklif alabilirsiniz.

Önce belirtiyi tanımlayın

Komut çalıştırmadan önce iki soruyu yanıtlayın; yanıtlar aramayı yarıya indirir.

Tüm site mi, tek sayfa mı?

Yalnızca belirli sayfalar (arama, sepet, yönetim paneli) yavaşsa sorun büyük olasılıkla o sayfanın çalıştırdığı sorgu veya koddadır. Statik dosyalar dahil her şey yavaşsa sunucu kaynakları ya da ağ öne çıkar.

Sürekli mi, belirli saatlerde mi?

Her gece aynı saatte yaşanan yavaşlık çoğunlukla yedekleme, zamanlanmış görev veya günlük döndürme işidir. Zamanlanmış işleri crontab -l, ls /etc/cron.d ve systemctl list-timers ile listeleyin.

Dakika 0–3: Genel tablo (uptime, top)

İlk üç dakikada yükün düzeyi ve CPU zamanının nereye gittiği belirlenir.

Load average ve çekirdek sayısı

uptime     # son 1, 5 ve 15 dakikanın load average değeri
nproc      # mantıksal çekirdek sayısı

Load average, çalışan veya çalışmayı bekleyen süreçlerin ortalama sayısıdır ve Linux'ta disk beklemesindeki (D durumu) süreçleri de içerir. Değeri çekirdek sayısına bölün: sürekli 1'in üzerindeki oran kuyruk oluştuğunu gösterir. 1 dakikalık değer 15 dakikalıktan yüksekse yük artıyordur.

%us, %sy, %wa, %st satırı

top çalıştırıp 1 tuşuna basarsanız her çekirdek ayrı görünür. CPU satırındaki alanlar:

• us: uygulama kodu (PHP, Node.js, veritabanı sorgu işleme). Yüksekse CPU'yu yiyen süreci bulun.
• sy: çekirdek. Çok yüksek bağlantı sayısında veya yoğun G/Ç'de artar.
• wa (iowait): CPU'nun disk işlemini beklediği süre. Yüksekse sorun diskte veya swap'tadır.
• st (steal): sanal makinenin fiziksel host tarafından bekletildiği süre. Yüksekse sorun sizin sunucunuzda değil, sağlayıcının host'undadır; sağlayıcıya bildirin. Bu değerin sanal sunucu türüyle ilişkisini VDS ile VPS arasındaki fark yazısında anlattık.

ps -eo pid,user,stat,pcpu,pmem,comm --sort=-pcpu | head -n 10

Dakika 3–6: Bellek (free, vmstat)

Bellek sorunu kendini swap trafiği ve sonlandırılan süreçlerle belli eder.

Swap kullanımı ve si/so

free -h
vmstat 1 5

free çıktısında bakılacak sütun available'dır; free sütununun düşük olması normaldir, çünkü Linux boş belleği disk önbelleği olarak kullanır. Swap'ta bir miktar veri bulunması tek başına sorun değildir. Sorun, vmstat'taki si (swap'tan okunan) ve so (swap'a yazılan) değerlerinin her saniye sıfırdan büyük olmasıdır: bu, sistemin sürekli bellek ile disk arasında sayfa taşıdığını gösterir. vmstat'ın ilk satırı açılıştan beri ortalamadır, sonraki satırlara bakın.

OOM killer izleri

Bellek tamamen bittiğinde çekirdeğin OOM killer mekanizması bir süreci sonlandırır; veritabanının "kendiliğinden" kapanması çoğu zaman budur.

sudo dmesg -T | grep -iE 'out of memory|killed process'
sudo journalctl -k --since yesterday | grep -i oom
ps -eo pid,rss,comm --sort=-rss | head -n 10     # en çok bellek kullananlar (KB)

Dakika 6–10: Disk (iostat, iotop, df)

Disk tarafında iki ayrı sorun aranır: yavaş yanıt ve dolu alan.

%util ve await

iostat -xz 1 5        # sysstat paketi: apt install sysstat / dnf install sysstat
sudo iotop -oPa       # yalnızca G/Ç yapan süreçler, birikimli

r_await ve w_await, okuma ve yazma isteklerinin kuyrukta bekleme dahil milisaniye cinsinden süresidir; aqu-sz ortalama kuyruk uzunluğudur. Bu değerleri sunucunuzun normal günlerdeki değerleriyle karşılaştırın. %util yüzde 100'e yakınsa sıralı çalışan disklerde doygunluk vardır; NVMe ve RAID gibi istekleri paralel işleyen aygıtlarda ise bu değer tek başına sınırı göstermez.

Dolu disk ve inode

df -h        # alan
df -i        # inode (dosya sayısı sınırı)
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -n 10

Disk ya da inode yüzde 100'e ulaştığında veritabanı yazamaz, oturum dosyaları oluşmaz ve site hata verir. Sık görülen nedenler büyüyen günlükler, eski yedekler ve temizlenmeyen önbellek veya oturum dosyalarıdır. Bir dosyayı silmeden önce hangi sürecin kullandığını kontrol edin; açık bir günlük dosyasını silmek alanı serbest bırakmaz, truncate -s 0 dosya daha güvenlidir.

Dakika 10–13: Ağ ve bağlantılar (ss)

Bağlantı sayısı normalin çok üstündeyse yavaşlığın kaynağı trafiğin kendisi olabilir.

Bağlantı sayısı ve TIME_WAIT

ss -s
ss -tan state time-wait | wc -l
ss -tan state syn-recv | wc -l

TIME_WAIT, kapanmış bir TCP bağlantısının bir süre daha tutulduğu durumdur ve yoğun sunucuda binlerce olması normaldir. Eski rehberlerdeki tcp_tw_recycle ayarını uygulamayın; Linux 4.12'de çekirdekten kaldırılmıştır. SYN-RECV sayısının olağan dışı yüksek olması ise el sıkışmasını tamamlamayan bağlantı denemelerine, yani olası bir SYN taşkınına işaret eder.

Olası saldırı işaretleri

Bağlantıların birkaç IP adresinde yoğunlaşıp yoğunlaşmadığına ve en çok istenen adreslere bakın:

# 80/443 portundaki kurulu bağlantılar, IP başına
ss -tn state established '( sport = :80 or sport = :443 )' | awk 'NR>1 {print $4}' | rev | cut -d: -f2- | rev | sort | uniq -c | sort -rn | head
# Erişim günlüğünde en çok istek yapan IP'ler ve adresler
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Tek bir IP'den yüzlerce bağlantı ya da giriş sayfası gibi tek bir adrese yoğun istek, bot veya saldırı trafiğine işaret eder. Site bir CDN ya da ters vekil arkasındaysa görünen IP'ler vekilindir. Hat kapasitesini dolduran hacimsel DDoS saldırıları sunucu içinden çözülemez; sağlayıcınızın ağ düzeyindeki korumasına başvurun.

Dakika 13–15: Uygulama katmanı

Kaynaklar normal görünüyorsa yavaşlık uygulama katmanındadır.

PHP-FPM max_children uyarısı

# Ubuntu/Debian
sudo grep -i 'max_children' /var/log/php*-fpm.log
# AlmaLinux/Rocky
sudo grep -i 'max_children' /var/log/php-fpm/error.log

server reached pm.max_children setting uyarısı, tüm PHP süreçlerinin dolu olduğunu ve yeni isteklerin beklediğini gösterir. Değeri körlemesine artırmayın; RAM'e göre hesaplama yöntemini kalıcı iyileştirme adımları rehberinde bulabilirsiniz. Süreçler yavaş sorgu beklediği için doluyorsa sorun veritabanındadır.

MySQL processlist

sudo mysql -e "SHOW FULL PROCESSLIST;"

Time sütunu yüksek sorgulara ve State alanında Waiting for table metadata lock gibi kilit beklemelerine bakın. Aynı ağır sorgunun onlarca kopyası genellikle eksik indekse işaret eder.

Web sunucusu logları

sudo tail -n 50 /var/log/nginx/error.log
awk '$9 ~ /^5/' /var/log/nginx/access.log | wc -l     # 5xx yanıt sayısı

Apache kullanıyorsanız günlükler Ubuntu/Debian'da /var/log/apache2/, AlmaLinux/Rocky'de /var/log/httpd/ altındadır. upstream timed out ve connect() ... failed satırları PHP-FPM'in yetişemediğini gösterir.

Belirti → olası neden → çözüm tablosu

Eşik değerleri kesin kural değil, pratikte kullanılan başlangıç noktalarıdır; en güvenilir referans sunucunuzun sorunsuz günlerdeki değerleridir.

Sık sorulan sorular

CPU kullanımı yüksekse ne yapmalı?

Önce hangi sürecin CPU kullandığını ps --sort=-pcpu veya top ile bulun. PHP süreçleriyse sayfa önbelleği ve OPcache'i kontrol edin, erişim günlüğünde bot trafiği arayın. Veritabanıysa yavaş sorgulara bakın; optimizasyondan sonra da yük sürekli çekirdek sayısını aşıyorsa CPU yükseltmesi gerekir.

Yüksek iowait ne anlama gelir?

CPU'nun boşta kaldığı sürede tamamlanmayı bekleyen disk işlemleri olduğunu gösterir. Genellikle yavaş veya indekssiz sorgulardan, swap trafiğinden ya da aynı anda çalışan yedekleme işinden kaynaklanır. iotop ile G/Ç yapan süreci bulmak ilk adımdır.

Swap kullanımı sorun mu?

Swap'ta veri durması tek başına sorun değildir; çekirdek uzun süredir kullanılmayan sayfaları oraya taşımış olabilir. Sorun, vmstat'taki si ve so değerlerinin sürekli sıfırdan büyük olmasıdır; bu durumda bellek gerçekten yetmiyordur.

Saldırı olup olmadığını nasıl anlarım?

Bağlantıların birkaç IP'de yoğunlaşması, SYN-RECV sayısının olağan dışı artması ve erişim günlüğünde tek bir adrese yüksek hızda istek gelmesi başlıca işaretlerdir. Uygulama katmanı saldırılarında IP engelleme ve hız sınırlama işe yarar; hattı dolduran hacimsel saldırılar sağlayıcı tarafında filtrelenmelidir.

Ne zaman uzmana başvurmalı?

Akış darboğazı gösterdiği halde çözüm yapılandırma değişikliği, sorgu analizi veya sistem mimarisi gerektiriyorsa ya da sorun kısa aralıklarla tekrar ediyorsa uzman desteği zaman kazandırır. Canlı sunucuda veritabanı veya web sunucusu ayarıyla deneme yapmak, kesintiyi uzatma riski taşır.

Bu kontrolleri kendiniz yapabilirsiniz; darboğazın kalıcı olarak giderilmesini bir ekibe bırakmak isterseniz sunucu optimizasyonu hizmeti için teklif alabilirsiniz. Sorunların kullanıcılar fark etmeden yakalanması için sunucu izleme, servis kontrolü ve log analizi içeren izlemeli sunucu yönetimi paketlerine de bakabilirsiniz.

Kaynaklar

• top(1) kılavuz sayfası
• vmstat(8) kılavuz sayfası
• iostat(1) kılavuz sayfası
• ss(8) kılavuz sayfası
• proc_loadavg(5): /proc/loadavg
• Brendan Gregg: The USE Method