Sunucuna SSH ile bağlandığında terminalden seni karşılayan o üç sihirli sayıyı muhtemelen görmüşsündür: load average: 0.52, 0.48, 0.61. Peki bu sayılar tam olarak ne anlama geliyor? Sisteminiz gerçekten yük altında mı, yoksa sadece normal mi çalışıyor? Bu soruların cevabını bilmeden bir sunucuyu yönetmek, hastanın nabzını ölçmeden ameliyata girmek gibidir.
Load Average Nedir?
Load average, sistemin belirli zaman dilimlerinde ne kadar iş yükü taşıdığını gösteren bir ortalama değerdir. Linux çekirdeği bu değeri 1 dakika, 5 dakika ve 15 dakikalık periyotlar için ayrı ayrı hesaplar ve raporlar.
Teknik olarak load average, şu iki durumun toplamını ifade eder:
- CPU bekleme kuyruğundaki işlem sayısı: CPU’ya erişmek için sıra bekleyen süreçler
- Disk I/O bekleyen işlem sayısı: Kesintisiz uyku (uninterruptible sleep) modundaki süreçler, yani I/O tamamlanmasını bekleyenler
Bu ikinci nokta çok önemli. Bir çok sysadmin load average’ı sadece CPU kullanımıyla özdeşleştirir, oysa yüksek disk I/O da load average’ı dramatik biçimde artırabilir. Dolayısıyla “CPU %20 kullanımda ama load average 8” gibi bir durumla karşılaştığında sürprise uğramamak için bu ayrımı aklında tutman gerekiyor.
Nerede Görüntülenir?
Load average değerlerine ulaşmak için birden fazla yol var. En sık kullanılanlardan başlayalım:
# uptime komutu ile hızlı bakış
uptime
# Çıktı: 14:32:10 up 42 days, 3:15, 2 users, load average: 1.23, 0.98, 0.87
# top ile gerçek zamanlı izleme
top
# htop ile daha görsel izleme
htop
# /proc/loadavg dosyasını direkt okuma
cat /proc/loadavg
# Çıktı: 1.23 0.98 0.87 3/412 28741
# w komutu ile oturum bilgileriyle birlikte
w/proc/loadavg çıktısındaki son iki değere de dikkat etmek gerekiyor. 3/412 ifadesi şu an çalışan 3 süreç olduğunu, sistemde toplamda 412 süreç bulunduğunu gösterir. 28741 ise son oluşturulan sürecin PID’idir.
CPU Sayısı ile İlişki: Temel Yorum Kuralı
Load average değerini yorumlamanın en kritik adımı, sistemindeki CPU çekirdeği sayısını bilmektir. Load average değeri tek başına anlamsızdır, çekirdek sayısına göre normalize edilmesi gerekir.
# CPU çekirdek sayısını öğrenmek için
nproc
# veya
grep -c ^processor /proc/cpuinfo
# Daha detaylı CPU bilgisi
lscpu | grep -E "^CPU(s)|^Core|^Socket|^Thread"Mantık şu şekilde işler: 4 çekirdekli bir sistemde load average 4.0 ise sistem tam kapasitede çalışıyor demektir. 4.0 değerinin altındaki her şey teknik olarak tolere edilebilir, üzerindeki her şey ise işlemler sıraya girmeye başlıyor demektir.
Bunu somutlaştıralım:
- Load average 1.0, tek çekirdekli sistem: CPU tamamen dolu, işlemler sıralanıyor
- Load average 1.0, 4 çekirdekli sistem: CPU kapasitesinin sadece %25’i kullanılıyor, gayet rahat
- Load average 8.0, 4 çekirdekli sistem: Her çekirdek için ortalama 2 işlem bekliyor, sistem zorlanıyor
- Load average 0.5, tek çekirdekli sistem: CPU %50 boşta, her şey yolunda
# Normalize edilmiş load average hesaplama
# (Bu bash one-liner'ı kolayca kullanabilirsin)
echo "$(uptime | awk '{print $10}' | tr -d ',') / $(nproc)" | bc -lGenel kural olarak çekirdek sayısına eşit veya altındaki bir load average değeri sağlıklı kabul edilir. Çekirdek sayısının 2 katına ulaşan değerler dikkat gerektiren seviyedir. 3 katını aşan değerler ise acil müdahale sinyalidir.
Üç Zaman Dilimiyle Trend Analizi
Load average’ın üç farklı zaman dilimi vermesi tesadüf değil. Bu değerlerin birbiriyle ilişkisini okumayı öğrenmek, sorunun yönünü anlamak açısından kritik.
# Sürekli izleme için watch komutu ile uptime
watch -n 2 uptimeŞimdi farklı senaryoları inceleyelim:
Senaryo 1 – Yük artıyor: 0.45, 0.32, 0.21 1 dakikalık değer en yüksek, 15 dakikalık en düşük. Sistem bu an yük altına girmeye başlıyor. Acele etmeden ne olduğunu araştırmak gerekiyor.
Senaryo 2 – Yük düşüyor: 0.21, 0.45, 0.89 1 dakikalık değer en düşük. Az önce bir sorun vardı ama geçiyor. Belki cron job bitti, belki toplu istek dalgası dindi.
Senaryo 3 – Stabil yüksek yük: 4.12, 4.08, 4.15 Uzun süredir yüksek yük var. Geçici değil, kalıcı bir sorunla karşı karşıyasın. Kapasite planlaması gerekebilir.
Senaryo 4 – Ani spike sonrası: 0.80, 2.10, 1.95 Bir süre önce ciddi bir spike olmuş ama şu an düşüyor. Log analizi yaparak o dönemde ne çalıştığını bulmak gerekiyor.
Yüksek Load Average Kaynaklarını Bulmak
Load average yüksek olduğunda kaynağı bulmak için sistematik bir yaklaşım benimsemek gerekiyor.
CPU Kaynaklı Yük Tespiti
# CPU kullanımına göre sıralı süreç listesi
ps aux --sort=-%cpu | head -20
# top ile CPU hog süreçlerini görme (interaktif)
top -b -n 1 | head -30
# Sadece yüksek CPU tüketen süreçleri filtrele
ps aux | awk '$3 > 10.0 {print $0}' | sort -k3 -rnI/O Kaynaklı Yük Tespiti
Yüksek load average ama düşük CPU kullanımı varsa suçlu genellikle disk I/O’dur. Bunu tespit etmek için:
# iostat ile disk I/O izleme (sysstat paketi gerekli)
iostat -x 2 5
# iotop ile hangi sürecin I/O yaptığını görme
iotop -o -b -n 3
# vmstat ile genel sistem durumu (r: run queue, b: blocked)
vmstat 2 10vmstat çıktısında r kolonu çalışmayı bekleyen süreç sayısını, b kolonu ise I/O bekleyen bloke süreç sayısını gösterir. Yüksek load average ile birlikte b kolonunun yüksek olması, I/O kaynaklı yük olduğunun kesin göstergesidir.
D State (Uninterruptible Sleep) Süreçleri
Bazen load average yüksek ama ne CPU ne de belirgin bir I/O göremezsin. Bu durumda “D state” süreçlere bakmak gerekir:
# D state (disk wait) süreçleri listeleme
ps aux | awk '$8 == "D" {print $0}'
# Alternatif yöntem
ps -eo pid,stat,cmd | grep "^[0-9]* D"
# Daha detaylı bilgi için
for pid in $(ps -eo pid,stat | awk '$2 ~ /^D/ {print $1}'); do
echo "PID: $pid"
cat /proc/$pid/status | grep -E "Name|State|voluntary"
doneD state’teki süreçler NFS mount problemleri, bozuk disk sektörleri veya aşırı yüklenmiş depolama sistemi nedeniyle oluşur. Bu süreçleri normal yollarla kill edemezsin, çoğunlukla yeniden başlatma kaçınılmaz olur.
Gerçek Dünya Senaryoları
Senaryo 1: Web Sunucusu Aniden Yavaşladı
Sabah 09:15’te bir müşteri araması: “Site çok yavaş!” Sunucuya bağlanıyorsun ve şunu görüyorsun:
$ uptime
09:18:32 up 127 days, 14:22, 1 user, load average: 18.43, 12.67, 6.214 çekirdekli bir sunucu için bu değerler ciddi alarm veriyor. Yük artıyor (1dk > 5dk > 15dk). İlk adımlar:
# Kimin CPU tükettiğini bul
ps aux --sort=-%cpu | head -10
# Aynı anda kaç Apache/Nginx worker var
pgrep -c apache2
# veya
pgrep -c nginx
# Aktif bağlantı sayısı
ss -s
# Son 30 dakikadaki istek patlamasını kontrol et
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20Büyük ihtimalle bir bot saldırısı, kötü yazılmış bir sorgu ya da viral içerik nedeniyle sunucu kapasitesi aşılmıştır. Bu senaryoda rate limiting ve süreç sayısı kısıtlaması acil çözümdür.
Senaryo 2: Gece Yarısı Yükselen Load
Sabah geldin, geceden kalan log dosyalarını inceliyorsun. Monitoring sistemin saat 02:30 ile 03:15 arasında yüksek load uyarısı vermiş. Ama şu an her şey normal:
$ uptime
08:45:10 up 89 days, 2:30, 1 user, load average: 0.82, 0.71, 0.68Bu klasik “gece cron job” problemi. Araştırma:
# O saatlerde çalışan cron jobları kontrol et
grep "02:[23]" /var/log/syslog | grep cron
# veya
grep "02:[23]" /var/log/cron
# Sisteme ait tüm cron jobları listele
for user in $(cut -f1 -d: /etc/passwd); do
crontab -u $user -l 2>/dev/null | grep -v "^#" | grep -v "^$" | while read line; do
echo "$user: $line"
done
done
# Anacron görevlerini de kontrol et
ls -la /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/Büyük ihtimalle bir backup scripti, log rotation veya database maintenance görevi o saatte çalışıyordur. Birden fazla yoğun iş aynı saate denk gelmişse bunları farklı zaman dilimlerine yaymak çözümdür.
Senaryo 3: Sürekli Yüksek Load, Düşmüyor
Bu senaryo en can sıkıcı olanı. Birkaç günden bu yana load average normal değerlerin üzerinde seyrediyor:
$ uptime
15:22:44 up 18 days, 0:45, 2 users, load average: 6.21, 6.08, 5.978 çekirdekli bir sunucu için bu değerler kabul edilebilir sınırda ama sürekli bu seviyede kalmak uzun vadeli bir kapasite sorununa işaret ediyor. Daha derin analiz:
# Süreç bazlı kaynak kullanımı snapshot
ps auxf --sort=-%cpu > /tmp/process_snapshot_$(date +%Y%m%d_%H%M).txt
# Memory ve swap durumunu kontrol et
free -h
# Swap kullanımı varsa hangi süreçler swap'ta
for pid in /proc/[0-9]*/status; do
awk '/VmSwap|Name/{printf $2 " "}' $pid
echo
done | awk '$2 > 0 {print $0}' | sort -k2 -rn | head -10
# perf ile CPU'yu en çok kullanan kernel fonksiyonları (opsiyonel, perf kurulu olmalı)
perf top -gBu tür kalıcı yüksek yük genellikle uygulama seviyesinde optimizasyon, vertical scaling veya iş yükünü birden fazla sunucuya dağıtmayı gerektirir.
Load Average İzleme ve Alerting
Manuel kontrol yetmez, otomatik izleme şart. Birkaç pratik yaklaşım:
# Basit bash script ile load average alerting
#!/bin/bash
# /usr/local/bin/check_load.sh
THRESHOLD=$(echo "$(nproc) * 1.5" | bc)
CURRENT_LOAD=$(uptime | awk '{print $10}' | tr -d ',')
HOSTNAME=$(hostname)
if (( $(echo "$CURRENT_LOAD > $THRESHOLD" | bc -l) )); then
echo "UYARI: $HOSTNAME sunucusunda yük yüksek!" |
mail -s "High Load Alert: $HOSTNAME ($CURRENT_LOAD)" [email protected]
fi# Crontab'a her 5 dakikada bir ekle
# crontab -e ile açıp ekle:
*/5 * * * * /usr/local/bin/check_load.shPrometheus ve node_exporter kullanıyorsan alertmanager kuralı şu şekilde yazılabilir:
# /etc/prometheus/alerts/load.yml (yaml formatında)
# Örnek alert rule içeriği - bash değil yaml olduğu için referans amaçlı:
# alert: HighLoadAverage
# expr: node_load1 / count(node_cpu_seconds_total{mode="idle"}) by (instance) > 1.5
# for: 5m
# labels: severity: warningSık Yapılan Yorum Hataları
Hata 1 – Çekirdek sayısını göz ardı etmek: Load average 3.5 görünce paniğe kapılan ama sunucusunun 16 çekirdekli olduğunu unutan sysadmin sayısı az değildir. Her zaman nproc çıktısıyla normalize et.
Hata 2 – Tek bir değere odaklanmak: Sadece 1 dakikalık değere bakıp karar vermek yanıltıcı olabilir. Üç değeri birlikte yorumlamak trend analizi için gereklidir.
Hata 3 – Load average’ı CPU kullanımıyla karıştırmak: Yüksek load, yüksek CPU demek değildir. I/O bekleme de load’u artırır. vmstat ve iostat ile doğrulama yapmadan karar verme.
Hata 4 – Kısa süreli spike’lara aşırı tepki vermek: Bir backup scripti çalıştığında veya büyük bir dosya kopyalandığında load geçici olarak yükselebilir. 15 dakikalık trend düşükse endişelenme.
Hata 5 – Sadece load average’a bakmak: Load average tek başına yeterli bir metrik değil. CPU kullanımı, memory durumu, I/O wait, network trafiği ile birlikte değerlendirilmeli.
Faydalı Tek Satır Komutlar
# Normalize edilmiş load average (yüzde olarak)
echo "scale=2; $(cat /proc/loadavg | awk '{print $1}') / $(nproc) * 100" | bc | awk '{print $1"%"}'
# Son 1 saatin load average logunu sar loglardan çek
sar -q 1 60 2>/dev/null | head -20
# Load average ile birlikte CPU ve memory özeti
echo "Load: $(uptime | awk -F'load average:' '{print $2}')" &&
echo "CPU cores: $(nproc)" &&
free -h | grep MemSonuç
Load average, doğru yorumlandığında sistem sağlığı hakkında son derece değerli bilgi veren basit ama güçlü bir metriktir. Akılda tutman gereken temel nokta şudur: Değer tek başına anlamsız, çekirdek sayısına göre normalize edilmesi zorunludur.
Bir sunucuyu yönetirken load average’ı üç boyutlu düşünmek gerekir. Mevcut anlık değer, trendin yönü (artıyor mu azalıyor mu?) ve altta yatan kaynak (CPU mu, I/O mu?). Bu üç sorunun cevabını bildiğinde önünde çok daha net bir tablo çıkar.
Monitoring altyapını kur, threshold’larını çekirdek sayısına göre ayarla, alarmların hem false positive’e neden olacak kadar hassas hem de gerçek sorunları kaçıracak kadar kör olmasın. Ve her yüksek load’da paniklemeden önce vmstat, iostat ve ps aux üçlüsünü çalıştır. Büyük ihtimalle sebebi 5 dakika içinde bulursun.
Sunucu izlemenin temeli iyi sorular sormaktır. Load average da sana “sistemim ne kadar meşgul?” sorusunun cevabını veren en temel araçlardan biridir. Geri kalanını ise deneyim ve biraz araştırmayla halledersin.