Linux Performans Analizi: Temel Metrikler ve Araçlar

Sunucuya SSH ile bağlandığınızda sizi karşılayan o siyah terminal ekranı, aslında onlarca hikaye anlatır. CPU’nun nefes alıp almadığı, belleğin dolup dolmadığı, diskin çığlık atıp atmadığı… Bunları okuyabilmek için doğru araçları bilmek ve doğru soruları sormak gerekiyor. Bu yazıda Linux sistemlerde performans analizine temel oluşturan metrikleri, kullandığım araçları ve gerçek dünyadan senaryoları paylaşacağım.

Performans Analizine Genel Bakış

Linux performans analizi temelde dört ana kaynağı inceler: CPU, bellek, disk I/O ve ağ. Bu dördünden herhangi birindeki darboğaz, sistemin tamamını etkiler. Bir veritabanı sunucusunda disk I/O tıkandığında CPU boşta bile olsa sistem yavaşlar. Bir web sunucusunda bellek tükenince swap devreye girer ve bu durum performansı ciddi biçimde düşürür.

Performans sorunlarını çözerken izlediğim genel akış şu şekilde:

• Sistemi bir bütün olarak incele, genel durumu kavra
• Hangi kaynak darboğaz oluşturuyor? Tespit et
• O kaynağı daha derin incele
• Sorumlu süreci veya uygulamayı bul
• Düzeltici aksiyon al, sonucu doğrula

Bunu yaparken paniklemeden, metodolojik ilerlemek çok önemli. Üretim ortamında aceleci kararlar genellikle işleri daha da kötüleştirir.

Genel Sistem Durumuna Hızlı Bakış

uptime ve load average

Bir sunucuya bağlandığınızda yapmanız gereken ilk şey genel yük durumuna bakmak:

uptime
# Çıktı: 14:32:05 up 47 days, 3:21, 2 users, load average: 2.45, 1.87, 1.23

Load average değerleri sırasıyla son 1, 5 ve 15 dakikayı gösterir. Bu değerlerin anlamlı olması için CPU çekirdek sayısıyla karşılaştırmanız gerekir. 4 çekirdekli bir sistemde load average 4.0 demek sistem tam kapasitede çalışıyor demektir, 8.0 demek ise ciddi bir sorun var demektir.

# Kaç çekirdek var?
nproc
# Ya da daha detaylı:
cat /proc/cpuinfo | grep "processor" | wc -l

Eğer load average giderek artıyorsa (15 dakika > 5 dakika > 1 dakika) sorun büyüyor demektir. Tam tersi durumda sorun geçiyor olabilir.

vmstat ile Hızlı Genel Bakış

vmstat aracı CPU, bellek, swap, disk ve I/O hakkında tek satırda özet bilgi verir. Sisteme ilk bağlandığımda sıklıkla kullandığım komutlardan biridir:

vmstat 2 5
# Her 2 saniyede bir, toplam 5 kez çıktı ver

Çıktıdaki önemli sütunlar:

• r: Çalışmak için bekleyen işlem sayısı (CPU queue)
• b: Uyku modundaki işlem sayısı (genellikle I/O bekliyor)
• si / so: Swap giriş/çıkışı (bunlar sıfır olmalı idealde)
• wa: CPU’nun I/O beklemesi için harcadığı süre yüzdesi
• us / sy: Kullanıcı alanı ve kernel alanı CPU kullanımı

wa değeri sürekli yüksekse disk I/O probleminiz var, r değeri çekirdek sayısından sürekli yüksekse CPU darboğazı yaşıyorsunuz demektir.

CPU Analizi

top ve htop

Klasik top komutu her Linux sysadmin’in ilk başvurduğu araçtır:

top
# Etkileşimli modda açılır
# 'P' tuşu: CPU kullanımına göre sırala
# 'M' tuşu: Bellek kullanımına göre sırala
# 'k' tuşu: Süreç öldür
# '1' tuşu: Her CPU çekirdeğini ayrı göster

Ama ben genellikle htop tercih ederim, çok daha kullanışlı:

# Kurulum
apt install htop   # Debian/Ubuntu
yum install htop   # RHEL/CentOS

htop

htop ile renk kodlamalı CPU grafiklerini, bellek kullanımını ve işlemleri çok daha kolay takip edebilirsiniz. F6 tuşuyla sıralama kriterini değiştirebilir, F9 ile sinyal gönderebilirsiniz.

Belirli Bir Sürecin CPU Kullanımını İzlemek

Gerçek dünya senaryosu: Üretim ortamında bir Java uygulaması CPU’yu yiyor, hangi thread’in suçlu olduğunu bulmamız gerekiyor.

# PID'i bul
ps aux | grep java | grep -v grep

# O PID'e ait thread'leri CPU kullanımına göre sırala
top -H -p <PID>

# Daha detaylı için
ps -eLf | grep <PID>

Yüksek CPU kullanan thread’in TID’ini (Thread ID) bulduktan sonra Java için thread dump alabilir ve hangi kod bloğunun sorun çıkardığını tespit edebilirsiniz.

perf ile Derinlemesine CPU Analizi

Daha ileri seviye analiz için perf aracını kullanıyorum:

# 30 saniye boyunca sistem genelinde CPU profili al
perf top

# Belirli bir sürecin CPU profilini al
perf record -g -p <PID> sleep 30
perf report

Bu araç özellikle uygulamanın hangi fonksiyonlarda zaman harcadığını görmek için çok değerlidir.

Bellek Analizi

free Komutu

free -h
# İnsan okunabilir formatta bellek durumu

free -h -s 2
# Her 2 saniyede bir güncelle

Çıktıyı yorumlarken dikkat edilmesi gereken nokta: Linux, boş belleği cache olarak kullanır. Bu yüzden “used” değeri yüksek görünse bile “available” sütununa bakmanız gerekir. Available, uygulamaların gerçekte kullanabilecekleri bellek miktarını gösterir.

Asıl tehlike işareti şudur: Swap kullanımının sürekli artması. Bu durum belleğin yetersiz kaldığını ve sistemin diske yazmaya başladığını gösterir, performans bu noktada büyük ölçüde düşer.

/proc/meminfo ile Detaylı Bellek Bilgisi

cat /proc/meminfo

# Özellikle şu değerlere bakın:
grep -E "MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree|Cached|Buffers" /proc/meminfo

Bellek Sızdıran Süreci Bulmak

Gerçek dünya senaryosu: Sunucu her birkaç günde bir yavaşlıyor, OOM killer devreye giriyor ve bir servis ölüyor.

# En fazla bellek kullanan 10 süreci listele
ps aux --sort=-%mem | head -11

# Belirli bir sürecin bellek haritası
pmap -x <PID>

# Zaman içinde bellek büyümesini izle (her 5 saniyede bir)
watch -n 5 "ps aux --sort=-%mem | head -5"

OOM (Out of Memory) killer’ın devreye girdiğini syslog’dan takip edebilirsiniz:

grep -i "oom|out of memory|killed process" /var/log/syslog
# RHEL/CentOS için:
grep -i "oom|killed process" /var/log/messages

Disk I/O Analizi

iostat Kullanımı

iostat, disk I/O performansını analiz etmek için temel araçtır. sysstat paketinin içinde gelir:

# Kurulum
apt install sysstat

# Temel kullanım - her 2 saniyede bir, 10 kez
iostat -x 2 10

Önemli metrikler:

• %util: Diskin ne kadar meşgul olduğu, yüzde cinsinden. Sürekli yüksek (90%+) ise disk darboğazı var
• await: I/O isteklerinin ortalama bekleme süresi (milisaniye). HDD için 20ms altı normal, SSD için 1ms altı beklenir
• r/s ve w/s: Saniyedeki okuma ve yazma işlemi sayısı
• rkB/s ve wkB/s: Saniyedeki okuma ve yazma miktarı (KB olarak)

# Sadece disk cihazlarını göster, daha temiz çıktı
iostat -xd 2 5

# Belirli bir disk için
iostat -x sda 2 5

iotop ile Disk I/O’yu Süreç Bazında İzlemek

Hangi sürecin diski öldürdüğünü bulmak için iotop kullanıyorum:

# Kurulum
apt install iotop

# Sadece aktif I/O yapan süreçleri göster
iotop -o

# Akümüle edilmiş değerleri göster
iotop -a -o

Gerçek dünya senaryosu: Gece 2’de monitoringden alarm geldi, disk I/O %100. iotop ile baktığımda MySQL’in büyük bir dump operasyonu yaptığını gördüm. Birisi production’da mysqldump çalıştırmıştı. Klasik.

lsof ile Açık Dosyaları Kontrol Etmek

# En fazla dosya açan süreçler
lsof | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

# Belirli bir dizini kullanan süreçler
lsof +D /var/log

# Silinen ama hala açık tutulan dosyalar (disk alanı sorununun yaygın sebebi)
lsof | grep deleted

Bu son komut özellikle önemli. Bir log dosyasını silerseniz ama onu açan süreç hala çalışıyorsa, disk alanı geri gelmez. Süreci restart etmeniz gerekir.

Ağ Performansı Analizi

ss ve netstat

# Aktif bağlantıları listele
ss -tunapl

# ESTABLISHED bağlantı sayısı
ss -s

# Belirli bir porta gelen bağlantılar
ss -tnp | grep :80

# TIME_WAIT durumundaki bağlantı sayısı (yüksekse sorun var)
ss -tan | grep TIME_WAIT | wc -l

TIME_WAIT bağlantı sayısı binlere ulaşıyorsa bu genellikle yüksek trafikli bir web sunucusunda yaşanan normal bir durumdur, ama kernel parametrelerini ayarlayarak iyileştirilebilir.

iftop ve nethogs

# Kurulum
apt install iftop nethogs

# Ağ arayüzü bazında anlık trafik
iftop -i eth0

# Süreç bazında ağ kullanımı (bence en kullanışlısı)
nethogs eth0

nethogs özellikle hangi uygulamanın ne kadar bant genişliği tükettiğini görmek için mükemmel. Bir keresinde bir PHP uygulaması saniyede yüzlerce MB dış API çağrısı yapıyordu, nethogs olmadan bulmak çok daha uzun sürerdi.

sar ile Tarihsel Veri İncelemek

sar (System Activity Reporter), sysstat paketinin bir parçasıdır ve tarihsel performans verisi toplar. Dün gece neyin olduğunu araştırırken çok işe yarar:

# sysstat'ı etkinleştir
systemctl enable sysstat
systemctl start sysstat

# Bugünkü CPU verilerini göster
sar -u

# Dün akşam 22:00-23:00 arası CPU kullanımı
sar -u -s 22:00:00 -e 23:00:00 -f /var/log/sysstat/sa$(date -d yesterday +%d)

# Ağ istatistikleri
sar -n DEV 1 5

# Bellek kullanımı tarihçesi
sar -r

Bu araç özellikle “dün gece bir şeyler oldu ama ne?” sorusunu cevaplamak için biçilmiş kaftan.

Sistem Genelinde Kapsamlı Analiz Araçları

dstat

dstat, birden fazla aracı tek ekranda birleştiren harika bir araçtır:

apt install dstat

# CPU, disk, ağ ve bellek birlikte
dstat -cdnm

# Tam detaylı görünüm
dstat -cdnmgs --top-cpu --top-mem --top-io 2

glances

Modern ve kapsamlı bir monitoring aracı arıyorsanız glances tam size göre:

pip3 install glances
# ya da
apt install glances

glances

glances tek ekranda CPU, bellek, disk, ağ, süreçler ve çok daha fazlasını gösterir. Ayrıca web arayüzü ve API desteği ile monitoring sistemlerine entegre edilebilir.

Gerçek Dünya Senaryosu: Yavaş Web Sunucusu Teşhisi

Birkaç ay önce yaşadığım bir olayı örnek olarak aktarayım. Sabah 9’da bir e-ticaret sitesinin yavaşladığına dair şikayet geldi. İzlediğim adımlar:

1. Adım: Genel duruma bak

uptime
# load average: 18.5, 12.3, 8.1 (8 çekirdekli sunucu, yük çok yüksek)

vmstat 1 5
# 'b' sütunu sürekli 5-10 arasında, 'wa' %60-70 arası
# Bu disk I/O problemi işareti

2. Adım: Disk I/O’yu incele

iostat -x 1 5
# sda: %util 99%, await 450ms (ciddi problem!)

iotop -o
# MySQL süreci saniyede 150MB yazıyor

3. Adım: MySQL’de ne oluyor?

# MySQL slow query log'a bak
tail -f /var/log/mysql/mysql-slow.log

# Aktif sorguları gör
mysql -e "SHOW FULL PROCESSLIST;"

Sonuç: Birinin yazdığı ve index kullanmayan bir rapor sorgusu, full table scan yaparak 50 milyonluk tabloyu diskten okuyordu. Sorgu optimize edildi, gerekli index eklendi, 5 dakika içinde sistem normale döndü.

Kernel ve Sistem Parametrelerini Kontrol Etmek

Bazen sorun uygulama değil, kernel parametrelerindedir:

# Tüm kernel parametrelerini listele
sysctl -a

# Önemli ağ parametreleri
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.ip_local_port_range

# Dosya sistemi limitleri
sysctl fs.file-max
ulimit -n  # Açık dosya limiti

# Geçici olarak değiştir
sysctl -w net.core.somaxconn=65535

# Kalıcı değişiklik için
echo "net.core.somaxconn = 65535" >> /etc/sysctl.conf
sysctl -p

Performans Verisi Toplamak için Script Örneği

Bir sorun sırasında veya sonrasında veri toplamak için kullandığım basit bir script:

#!/bin/bash
# Performans snapshot'ı al
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
OUTPUT_DIR="/tmp/perf_snapshot_$TIMESTAMP"
mkdir -p $OUTPUT_DIR

echo "Snapshot alınıyor: $TIMESTAMP"

# Temel sistem bilgileri
uptime > "$OUTPUT_DIR/uptime.txt"
free -h > "$OUTPUT_DIR/memory.txt"
df -h > "$OUTPUT_DIR/disk_usage.txt"

# Süreç bilgileri
ps auxf > "$OUTPUT_DIR/processes.txt"
top -b -n 3 > "$OUTPUT_DIR/top.txt"

# Ağ durumu
ss -tunapl > "$OUTPUT_DIR/network_connections.txt"
ss -s > "$OUTPUT_DIR/network_summary.txt"

# Disk I/O
iostat -x 1 10 > "$OUTPUT_DIR/iostat.txt" &
vmstat 1 10 > "$OUTPUT_DIR/vmstat.txt"

# Log dosyalarından son hatalar
tail -100 /var/log/syslog > "$OUTPUT_DIR/syslog_tail.txt" 2>/dev/null
tail -100 /var/log/messages > "$OUTPUT_DIR/messages_tail.txt" 2>/dev/null

echo "Snapshot tamamlandı: $OUTPUT_DIR"
tar -czf "${OUTPUT_DIR}.tar.gz" "$OUTPUT_DIR"
echo "Arşiv: ${OUTPUT_DIR}.tar.gz"

Bu scripti sorun sırasında çalıştırdığınızda, sonradan inceleme yapabileceğiniz kapsamlı bir snapshot elde edersiniz. Özellikle müşteriye veya geliştiriciye iletmek için çok pratik.

İzleme Alışkanlıkları ve İpuçları

Yıllar içinde edindiğim bazı önemli alışkanlıklar:

• Baseline belirleyin: Sisteminizin normal durumunu bilmeden anormal durumu fark edemezsiniz. Normal zamanlarda metriklerinizi kaydedin.
• Alarm eşiklerini dikkatli seçin: Her yükselen metrik alarm gerektirmez. CPU’nun 5 dakika boyunca %90 üzerinde olması alarm gerektirirken, anlık spike’lar normal olabilir.
• Log rotasyonunu ihmal etmeyin: Dolmuş disk, performans sorunlarının en yaygın ve en aptalca nedenlerinden biridir. /var/log altını düzenli kontrol edin.
• Değişiklikleri belgeleyin: “Dün bir şeyler değişti mi?” sorusu performans analizinde çok kritik. Change log tutun.
• Tek bir metriğe güvenmeyin: CPU düşük, bellek normal ama sistem yavaş olabilir. Her zaman bütüncül bakın.

Sonuç

Linux performans analizi bir sanat kadar bilimdir. Araçları bilmek önemlidir, ama daha önemlisi doğru soruyu sormak ve verileri doğru yorumlamaktır. top, vmstat, iostat, iotop, ss gibi temel araçlar çoğu senaryoda yeterlidir. Derinlemesine analiz için perf, strace veya uygulama özelinde araçlara geçebilirsiniz.

En önemli tavsiyem şudur: Bu araçları sorun çıkmadan önce öğrenin. Üretim ortamında kriz anında yeni araç öğrenmeye çalışmak hem stresi artırır hem de değerli zamanı kaybettirir. Test ortamınızda bu komutları düzenli olarak çalıştırın, çıktıları anlamlandırmayı alışkanlık haline getirin. Bir sunucunun “normal” nasıl göründüğünü bildiğinizde, “anormal” anında göze çarpar.

Performans sorunları genellikle karmaşık görünür ama metodolojik bir yaklaşımla büyük çoğunluğu saatler içinde çözülür. Paniklemeden, adım adım, veriyle ilerleyin.