Linux Sistem Neden Yavaşladı: İlk Kontrol Adımları

Gece 2’de telefon çalıyor ve “site açılmıyor” mesajı geliyor. Sunucuya bağlanıyorsun, komutlar yavaş yanıt veriyor, her şey ağır çekimde gibi. Tanıdık geldi mi? Linux sistemlerin yavaşlaması en sık karşılaşılan ve aynı zamanda en sinir bozucu durumların başında gelir. Ama iyi haber şu: sistematik yaklaşırsan, problemin kaynağını genellikle 10-15 dakika içinde bulabilirsin. Bu yazıda, yavaşlayan bir Linux sistemine ilk bağlandığında ne yapacağını, hangi sırayla kontrol edeceğini ve çıktıları nasıl yorumlayacağını anlatacağım.

Önce Büyük Resme Bak

Sisteme bağlandığında refleks olarak hemen spesifik bir şeye atlama. Önce genel durumu görmek çok daha verimli bir başlangıç noktası sunar. uptime komutu basit ama son derece bilgilendirici bir başlangıçtır.

uptime
# Örnek çıktı:
# 02:14:33 up 47 days, 3:22, 2 users, load average: 8.43, 6.21, 4.15

Buradaki load average değerleri sırasıyla son 1 dakika, 5 dakika ve 15 dakikayı temsil eder. Bu sayıları değerlendirmek için CPU çekirdek sayısını bilmen gerekir. 4 çekirdekli bir sistemde load average 4.0 demek sistem tam kapasitede çalışıyor demektir. 8.43 görüyorsan sistem kapasitesinin iki katı iş yükü altında eziliyor demektir.

# CPU çekirdek sayısını öğren
nproc
# ya da daha detaylı:
lscpu | grep "^CPU(s):"

Load average’ın 1 dakikalık değeri 15 dakikalık değerden çok daha yüksekse, problem yeni başlamış demektir. Tam tersi durumda, yani 15 dakikalık değer yüksek ve düşüyorsa, en kötüyü zaten atlatmışsın demektir. Bu ayrım, müdahalenin aciliyeti açısından kritiktir.

top ve htop ile Anlık Durumu Gör

top komutu neredeyse her Linux sistemde mevcut olduğu için ilk detaylı analize buradan başlamak mantıklıdır.

top
# Daha okunabilir çıktı için:
top -c
# Belirli bir kullanıcının proseslerini görmek için:
top -u www-data

top çalışırken bazı kısayollar hayat kurtarır:

• M: Bellek kullanımına göre sırala
• P: CPU kullanımına göre sırala (varsayılan)
• T: Çalışma süresine göre sırala
• k: Proses öldür (PID gir)
• 1: Her CPU çekirdeğini ayrı göster

top çıktısının en üstündeki satırlara dikkat et. %Cpu(s) satırında şunları görürsün:

• us (user): Kullanıcı proseslerinin CPU kullanımı
• sy (system): Kernel proseslerinin CPU kullanımı
• wa (iowait): I/O beklemesi yüzünden boşa harcanan zaman
• st (steal): Sanal makinelerde hypervisor’ın çaldığı CPU zamanı

Eğer wa değeri yüksekse (örneğin %30’un üzerinde), problem CPU’da değil disk veya ağ I/O’sundadır. Bu çok önemli bir ayrım çünkü CPU’yu suçlarken aslında disk sorununu gözden kaçırabilirsin.

htop varsa çok daha rahat bir deneyim sunar:

# htop yoksa kur
apt install htop    # Debian/Ubuntu
yum install htop    # CentOS/RHEL

htop

CPU Sorunlarını Derinlemesine İncele

CPU kullanımı anormal görünüyorsa, hangi prosesin ne kadar tükettiğini daha net görmek için şu komutları kullan:

# CPU kullanımına göre sıralı proses listesi, anlık değil ortalama
ps aux --sort=-%cpu | head -20

# Belirli bir prosesin detayını gör
ps aux | grep nginx

# Proses ağacını gör, hangi proses hangisini başlatmış
pstree -p | head -50

Bazen bir proses hem çok CPU hem de çok bellek kullanıyor olabilir. Bu durumda prosesin ne yaptığını anlamak için strace kullanabilirsin, ancak dikkatli ol, production’da yoğun kullanım sistemleri biraz daha yavaşlatabilir:

# Proses ne sistem çağrısı yapıyor
strace -p <PID> -c

# Hangi dosyalara erişiyor
lsof -p <PID>

Gerçek dünya senaryosu: Bir müşterinin web sunucusu yavaşlamıştı. top çıktısında PHP-FPM prosesleri %95 CPU kullanıyordu. ps aux ile baktığımda onlarca PHP-FPM worker’ın çatallandığını gördüm. lsof ile hangi dosyalara baktıklarına bakınca, hepsi aynı büyük log dosyasını okuyordu. Uygulama geliştiricisi yanlışlıkla her request’te tüm log dosyasını parse eden bir kod yazmıştı. Sorun bulundu, 20 dakika sürdü.

Bellek Durumunu Analiz Et

Bellek sorunları genellikle swap kullanımıyla kendini ele verir. Sistem RAM dolunca swap’a yazar ve bu disk I/O olduğu için inanılmaz yavaşlamaya neden olur.

free -h

Çıktıyı yorumlarken şunlara dikkat et:

• available sütunu, uygulamaların kullanabileceği gerçek belleği gösterir. free sütunundan daha güvenilirdir çünkü kernel cache’i de hesaba katar.
• Swap used değeri yüksekse (örneğin swap’ın %50’sinden fazlası kullanılıyorsa) ciddi bir bellek baskısı var demektir.

# Hangi prosesler ne kadar bellek kullanıyor
ps aux --sort=-%mem | head -20

# Daha detaylı bellek bilgisi
cat /proc/meminfo

# Swap kullanan prosesleri bul
for pid in $(ls /proc | grep '^[0-9]'); do
    swap=$(grep VmSwap /proc/$pid/status 2>/dev/null | awk '{print $2}')
    if [ ! -z "$swap" ] && [ "$swap" != "0" ]; then
        comm=$(cat /proc/$pid/comm 2>/dev/null)
        echo "$pid ($comm): ${swap} kB"
    fi
done | sort -t: -k2 -rn | head -20

Bu script biraz karmaşık görünebilir ama aslında /proc dosya sistemini tarayarak her prosesin swap kullanımına bakıyor. Swap kullanan en büyük prosesleri bulman için oldukça işlevseldir.

OOM Killer (Out of Memory Killer) devreye girip girmediğini kontrol etmek de önemlidir:

dmesg | grep -i "oom|killed process|out of memory"
# veya
grep -i "oom|killed" /var/log/syslog | tail -20

Eğer OOM Killer log’larda görünüyorsa, sistem kritik bellek sıkıntısı çekmiş ve prosesleri öldürmeye başlamış demektir.

Disk I/O Darboğazlarını Tespit Et

Yavaşlamaların çok büyük bir kısmının arkasında disk I/O sorunları yatar. İostat bu konuda temel araçtır:

# iostat yoksa sysstat paketini kur
apt install sysstat    # Debian/Ubuntu
yum install sysstat    # CentOS/RHEL

# 2 saniyede bir güncelle, 5 kez göster
iostat -x 2 5

iostat -x çıktısında dikkat etmen gereken değerler:

• await: Ortalama I/O bekleme süresi (milisaniye). HDD için 20ms altı normal, SSD için 1ms altı normal. Bu değer yüksekse disk ya çok meşgul ya da arızalıdır.
• %util: Diskin meşguliyet yüzdesi. %100’e yaklaşırsa disk doymuş demektir.
• r/s ve w/s: Saniyedeki okuma ve yazma işlemi sayısı.

# Hangi prosesler disk I/O yapıyor, iotop gerektirir
apt install iotop
iotop -o    # Sadece aktif I/O yapanları göster

# iotop yoksa alternatif
pidstat -d 2 5

Gerçek dünya senaryosu: Bir veritabanı sunucusu vardı, iowait sürekli %60-70’lerde seyrediyor ve MySQL sorguları timeout veriyordu. iostat -x baktım, await değeri 200ms’nin üzerindeydi. iotop ile baktığımda MySQL’in sürekli yazdığını görüyordum. Sonradan anlaşıldı ki birisi yanlışlıkla sync_binlog=1 ve innodb_flush_log_at_trx_commit=1 ayarlarını yapmıştı, bu da her transaction’da zorunlu disk yazımına neden oluyordu. Eski SATA HDD’ler bu yükü kaldıramıyordu.

Ağ Katmanını Kontrol Et

Uygulama katmanında bir yavaşlama varsa ağ sorunları da listeye girmeli. Özellikle web sunucuları veya veritabanı sunucuları için bağlantı sayısı kritik bir göstergedir.

# Aktif ağ bağlantılarını say
ss -s

# Duruma göre bağlantıları listele
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

# TIME_WAIT durumundaki bağlantı sayısı
ss -tan | grep TIME_WAIT | wc -l

# Hangi porta kaç bağlantı var
ss -tan | grep ESTAB | awk '{print $5}' | cut -d: -f2 | sort | uniq -c | sort -rn

Eğer binlerce TIME_WAIT bağlantısı görüyorsan, bu her zaman problem değildir ama kernel parametrelerini ayarlamayı düşünebilirsin. Asıl kritik olan ESTAB (established) bağlantılarının sayısı ve portlara dağılımıdır.

Ağ trafiğinin kendisini incelemek için:

# Anlık bant genişliği kullanımı (nload kurulumu gerekebilir)
nload eth0

# Alternatif olarak
sar -n DEV 2 5

# Hangi prosesler ağ kullanıyor (nethogs gerektirir)
nethogs eth0

Sistem Log’larını Hızlıca Tara

Her şeyi manuel incelemeden önce log’lar sana hazır bir hikaye anlatabilir.

# Son sistem hataları
journalctl -p err -n 50
# veya
journalctl -p err --since "1 hour ago"

# Kernel mesajları
dmesg | tail -50
dmesg | grep -E "error|warning|fail|critical" -i | tail -30

# Auth loglarına bak, brute force olabilir
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -10

Brute force saldırıları bazen gözden kaçan yavaşlama sebeplerinden biridir. Binlerce başarısız SSH denemesi hem CPU hem de log yazma açısından yük bindirabilir. fail2ban yoksa ve böyle bir durum varsa, ilk iş IP’yi bloklamaktır.

# Belirli bir servisin log'larına bak
journalctl -u nginx --since "30 min ago" | grep -i error
journalctl -u mysql --since "1 hour ago" | tail -100

vmstat ile Sistem Davranışını Takip Et

vmstat birden fazla kaynağı aynı anda özetleyen ve zaman içindeki değişimi gösteren çok faydalı bir araçtır:

# 2 saniyede bir, 10 kez göster
vmstat 2 10

Çıktıdaki sütunların anlamları:

• r: Çalışmayı bekleyen proses sayısı. CPU çekirdek sayısından sürekli yüksekse CPU darboğazı var demektir.
• b: Uyuyan (blocked) proses sayısı, genellikle I/O bekleyen prosesler.
• si / so: Saniyede swap’a giren ve çıkan veri (KB). Sıfır olması idealdir.
• bi / bo: Saniyede blok cihazdan okunan ve yazılan blok sayısı.
• wa: CPU iowait yüzdesi.
• cs: Saniyedeki context switch sayısı. Çok yüksekse (örneğin 100.000’in üzeri) proses/thread yönetimi sorunlu olabilir.

Proses Durumlarına Dikkat Et

Bazen prosesler D durumunda (uninterruptible sleep) takılır. Bu genellikle NFS mount veya disk I/O sorunlarının göstergesidir.

# D durumundaki prosesleri bul
ps aux | awk '$8 == "D" {print}'

# Veya
ps -eo pid,stat,comm | grep "^[0-9]* D"

D durumundaki prosesler kill -9 ile dahi öldürülemez. Bu prosesleri görmek, genellikle altındaki depolama katmanında (NFS, iSCSI, SAN) bir problem olduğuna işaret eder. Reboot olmadan çözülmeleri nadiren mümkündür.

Kaynakların Sınırlarını Kontrol Et

Sistem kaynak limitleri de gözden kaçan yavaşlama sebeplerinden biridir.

# Açık dosya limiti (system geneli)
cat /proc/sys/fs/file-max
cat /proc/sys/fs/file-nr    # kullanılan / boş / maksimum

# Kullanıcı bazlı limitler
ulimit -a

# Belirli bir proses'in limitleri
cat /proc/<PID>/limits

# Network bağlantı limitleri
cat /proc/sys/net/ipv4/ip_local_port_range
cat /proc/sys/net/core/somaxconn

Bir web sunucusu için file-nr‘nin neredeyse file-max‘a ulaşmış olması, yeni bağlantıların ve dosya açma işlemlerinin başarısız olacağı anlamına gelir. Bu genellikle logda Too many open files hatası olarak görünür.

Hızlı Kontrol Script’i

Tüm bu kontrolleri tek seferde yapmak için basit bir script hazırlayabilirsin. Bunu /usr/local/bin/quickcheck olarak kaydedip çalıştırılabilir yapabilirsin:

#!/bin/bash
echo "=== UPTIME ==="
uptime

echo ""
echo "=== CPU/MEMORY ==="
free -h
echo ""
vmstat 1 3

echo ""
echo "=== TOP 10 CPU ==="
ps aux --sort=-%cpu | head -11

echo ""
echo "=== TOP 10 MEM ==="
ps aux --sort=-%mem | head -11

echo ""
echo "=== DISK IO ==="
iostat -x 1 3

echo ""
echo "=== NETWORK CONNECTIONS ==="
ss -s

echo ""
echo "=== RECENT ERRORS ==="
journalctl -p err --since "30 min ago" --no-pager | tail -20

echo ""
echo "=== DMESG ERRORS ==="
dmesg | grep -E "error|fail|oom" -i | tail -10

chmod +x /usr/local/bin/quickcheck
quickcheck 2>&1 | tee /tmp/quickcheck-$(date +%Y%m%d-%H%M%S).txt

Çıktıyı aynı zamanda dosyaya kaydetmek, ileride karşılaştırma yapmak veya başkalarıyla paylaşmak için değerlidir.

Sorun Gideriminde Önceliklendirme

Tüm bu kontrolleri yaptıktan sonra bulgularını önceliklendirmen gerekir. Genel olarak şu sırayı takip et:

• Yüksek iowait + yüksek await: Disk I/O darboğazı, hemen disk sağlığını ve I/O yapan prosesleri kontrol et.
• Yüksek load + düşük iowait: CPU darboğazı, CPU tüketen proseslere odaklan.
• Swap kullanımı artıyor: Bellek yetersizliği, bellek sızdıran veya aşırı tüketen prosesleri bul.
• Çok sayıda D durumu proses: Storage katmanı sorunu, NFS veya disk donanımını kontrol et.
• Load normal ama uygulama yavaş: Ağ, veritabanı bağlantısı veya uygulama kodu sorununa bak.

Burada kritik nokta şu: bulguları izole etmeden hemen bir şey değiştirme. “Şunu kapatayım bakayım” diye production’da denemeler yapmak bazen işleri daha da karıştırabilir. Önce anla, sonra müdahale et.

Sonuç

Linux sistem yavaşlamalarında panik yapmanın hiçbir faydası yok. Sistematik bir yaklaşım, doğru araçları doğru sırayla kullanmak ve çıktıları doğru yorumlamak, seni çoğu zaman sorunun kaynağına hızlıca götürür. uptime ile genel durumu gör, top veya htop ile anlık yükü izle, iostat ile disk I/O’yu kontrol et, free ve swap durumuna bak, log’ları hızlıca tara. Bu beş adım, yavaşlama sorunlarının büyük çoğunluğunu açıklamaya yeter.

Zamanla bu kontrolleri refleks gibi yapar hale gelirsin ve gece 2’deki panik senin için sadece “biraz fazla mesai” haline dönüşür. Her yavaşlayan sistem aslında bir şey anlatıyor, sen sadece iyi bir dinleyici olmayı öğrenmen gerekiyor.