uptime ve w Komutları ile Sistem Yük Ortalamasını Anlama

yazar

Sunucuya bağlandığınız ilk anda, “bu makine iyi mi?” sorusunun cevabını bulmak için genellikle iki komuta bakarsınız: uptime ve w. Bu iki küçük komut, sistemin genel sağlığı hakkında inanılmaz derecede değerli bilgiler sunar. Ama işin püf noktası, çıktıyı okumaktan çok o çıktının ne anlama geldiğini doğru yorumlamaktır. “Load average 4.20 gösteriyor, bu kötü mü?” diye soran bir junior admin gördüğünüzde, cevabın “duruma göre” olduğunu anlarsınız. Bu yazıda, bu komutların çıktılarını gerçekten anlamak için ihtiyacınız olan her şeyi ele alacağız.

uptime Komutu ile Sistem Bilgisi Almak

uptime komutu, göründüğünden çok daha fazla bilgi taşır. Tek satırlık çıktısı dört temel bilgiyi bir arada verir.

$ uptime
 14:23:45 up 42 days, 3:17,  2 users,  load average: 0.52, 0.38, 0.29

Bu çıktıyı parçalara ayıralım:

  • 14:23:45: Sistemin mevcut saati
  • up 42 days, 3:17: Sistemin kesintisiz çalışma süresi (uptime)
  • 2 users: Sisteme bağlı kullanıcı sayısı
  • load average: 0.52, 0.38, 0.29: Sırasıyla son 1, 5 ve 15 dakikanın yük ortalaması

-p Parametresiyle Daha Okunabilir Çıktı

$ uptime -p
up 6 weeks, 14 hours, 17 minutes

Bu parametre özellikle script’lerde veya monitoring araçlarında uptime değerini parse etmeniz gerektiğinde işe yarar.

-s Parametresiyle Başlangıç Zamanı

$ uptime -s
2024-09-15 11:06:28

Sistemin tam olarak ne zaman boot edildiğini görmek için kullanışlıdır. Bir olay sonrası zaman çizelgesi oluştururken bu bilgi kritik olabilir.

Yük Ortalaması (Load Average) Nedir?

Load average, Linux sistemlerinin en çok yanlış anlaşılan kavramlarından biridir. Pek çok admin bunu “CPU kullanım yüzdesi” ile karıştırır, oysa bu tamamen farklı bir şeydir.

Load average, belirli bir zaman aralığında çalışmayı bekleyen veya çalışan süreçlerin ortalamasıdır. Linux çekirdeği, bunu hesaplarken iki tip süreci dahil eder:

  • Çalışan (running) durumundaki süreçler
  • Kesintisiz bekleme (uninterruptible sleep, D state) durumundaki süreçler, yani I/O bekleyen süreçler

Bu önemli bir fark. Yüksek load average, yalnızca CPU’nun meşgul olduğu anlamına gelmez. Disk I/O’nun tıkandığı, NFS mount’larının cevap vermediği veya veritabanının disk yazımlarını beklediği durumlarda da yük ortalaması tavan yapabilir.

CPU Sayısı ile İlişkisi

İşte yük ortalamasını anlamanın anahtarı: değeri CPU (veya CPU core) sayısına bölmeniz gerekir.

Sisteminizdeki CPU sayısını öğrenmek için:

$ nproc
8

# veya daha detaylı bilgi için
$ grep -c ^processor /proc/cpuinfo
8

# fiziksel core ve thread bilgisi için
$ lscpu | grep -E "^CPU(s)|Thread|Core|Socket"
CPU(s):                  8
Thread(s) per core:      2
Core(s) per socket:      4
Socket(s):               1

8 core’lu bir sistemde load average değerleri şu şekilde yorumlanır:

  • Load average 8.0: Sistem tam kapasitede çalışıyor, her core bir işle meşgul
  • Load average 4.0: Sistem yüzde elli kapasitede, durum ideal
  • Load average 16.0: Kapasitenin iki katı iş kuyruğa girmiş, sistem baskı altında
  • Load average 0.5: Sistem neredeyse boşta

Pratik bir formül olarak: load average / cpu sayısı hesabının 1.0’ın altında olması genellikle iyidir. 1.0 ile 2.0 arasında sistem biraz baskı altındadır ama yönetilebilir. 2.0’ın üzerinde sorun araştırılmalıdır.

Üç Değerin Birlikte Yorumlanması

load average: 0.52, 1.87, 3.42
#             1dk    5dk   15dk

Bu çıktı okunduğunda, grafiği zihnimizde ters çevirmeliyiz. 15 dakikalık değer yüksek, 1 dakikalık düşükse yük azalıyor demektir. Tam tersi durumda, yani 1 dakikalık değer yüksek, 15 dakikalık düşükse, ani bir yük artışı başlamış demektir.

Yukarıdaki örnekte: sistem 15 dakika önce oldukça yüklüydü (3.42), 5 dakika önce biraz hafifledi (1.87), şu an ise sakinleşti (0.52). Belki bir cron job tamamlandı ya da yoğun bir istek dalgası geçti.

load average: 4.21, 1.92, 0.87
#             1dk    5dk   15dk

Bu durumda ise tam tersi bir tablo var. Sistem sakin gidiyordu, son 5 dakikada yük artmaya başladı ve son 1 dakikada ciddi şekilde yükseldi. Bunu gördüğünüzde hemen w veya top ile ne olduğuna bakmanız gerekir.

w Komutu ile Anlık Sistem Durumu

w komutu, uptime çıktısını üst satırda gösterdikten sonra sisteme bağlı tüm kullanıcılar ve çalıştırdıkları işlemler hakkında detaylı bilgi verir.

$ w
 14:23:45 up 42 days,  3:17,  3 users,  load average: 1.42, 0.98, 0.71
USER     TTY      FROM             LOGIN@   IDLE JCPU   PCPU WHAT
ahmet    pts/0    192.168.1.45     13:15    2:45  0.12s  0.08s vim /etc/nginx/nginx.conf
deploy   pts/1    10.0.0.5         14:01    0.00s  2.31s  2.28s rsync -avz /var/www/ backup:/backup/
root     pts/2    192.168.1.10     14:20    1:32  0.04s  0.04s bash

Bu çıktıdaki kolonları anlamak önemlidir:

  • USER: Bağlı kullanıcının adı
  • TTY: Kullanıcının bağlı olduğu terminal (pts/0 uzak bağlantı, tty1 fiziksel konsol anlamına gelir)
  • FROM: Bağlantının geldiği IP adresi veya hostname
  • LOGIN@: Kullanıcının sisteme bağlandığı saat
  • IDLE: Son aktiviteden bu yana geçen süre (boş bekleme süresi)
  • JCPU: O terminal üzerinden çalışan tüm işlemlerin toplam CPU süresi
  • PCPU: Şu an çalışan işlemin tükettiği CPU süresi
  • WHAT: Kullanıcının şu an çalıştırdığı komut

w Komutunun Parametreleri

-h: Başlık satırını gizler, script’lerde çıktıyı parse ederken kullanışlıdır

-s: “Kısa” (short) format, LOGIN@ ve CPU sürelerini göstermez

-f: FROM kolonunu (bağlantı kaynağını) göster/gizle

-u: IDLE ve CPU sürelerini hesaplarken process zamanını değil kullanıcı zamanını kullan

# Belirli bir kullanıcıyı filtrele
$ w ahmet
 14:23:45 up 42 days,  3:17,  3 users,  load average: 1.42, 0.98, 0.71
USER     TTY      FROM             LOGIN@   IDLE JCPU   PCPU WHAT
ahmet    pts/0    192.168.1.45     13:15    2:48  0.12s  0.08s vim /etc/nginx/nginx.conf

# Header olmadan çıktı al
$ w -h
ahmet    pts/0    192.168.1.45     13:15    2:51  0.12s  0.08s vim /etc/nginx/nginx.conf
deploy   pts/1    10.0.0.5         14:01    0.00s  2.34s  2.31s rsync -avz /var/www/ backup:/backup/
root     pts/2    192.168.1.10     14:20    1:35  0.04s  0.04s bash

/proc/loadavg ile Ham Veri Okuma

Load average değerleri aslında /proc/loadavg dosyasından gelir. Bu dosyayı doğrudan okumak, özellikle monitoring script’leri yazarken çok daha pratiktir.

$ cat /proc/loadavg
1.42 0.98 0.71 2/387 24821

Bu çıktıdaki alanlar:

  • 1.42 0.98 0.71: Bildiğimiz 1, 5 ve 15 dakikalık load average
  • 2/387: Şu an çalışan süreç sayısı / toplam süreç sayısı (2 süreç aktif, toplam 387 süreç var)
  • 24821: En son oluşturulan sürecin PID numarası

Script yazarken bu dosyadan load average almak için:

#!/bin/bash
# Anlık yük ortalamasını al ve uyarı ver

CPU_COUNT=$(nproc)
LOAD_1MIN=$(cat /proc/loadavg | awk '{print $1}')
LOAD_RATIO=$(echo "scale=2; $LOAD_1MIN / $CPU_COUNT" | bc)

echo "CPU Sayisi: $CPU_COUNT"
echo "1 Dakikalik Load: $LOAD_1MIN"
echo "Load/CPU Orani: $LOAD_RATIO"

if (( $(echo "$LOAD_RATIO > 2.0" | bc -l) )); then
    echo "UYARI: Sistem ciddi yuk altinda!"
elif (( $(echo "$LOAD_RATIO > 1.0" | bc -l) )); then
    echo "DIKKAT: Sistem normalin ustunde yuklu"
else
    echo "TAMAM: Sistem normal"
fi

Gerçek Dünya Senaryoları

Senaryo 1: Gece Yarısı Yüksek Load Alarmı

Saat 02:30, telefonunuza bir alert geliyor: “Load average critical.” Sunucuya bağlanıyorsunuz.

$ uptime
 02:31:14 up 127 days, 14:22,  1 user,  load average: 12.43, 8.91, 4.22

$ w
 02:31:14 up 127 days, 14:22,  1 user,  load average: 12.43, 8.91, 4.22
USER     TTY      FROM             LOGIN@   IDLE JCPU   PCPU WHAT
root     pts/0    10.0.1.1         02:30    0.00s  0.04s  0.04s w

Kimse bağlı değil ama yük 12.43. 8 core’lu bir sistem için bu ciddi. Load 15 dakika önce 4.22’ydi, yani yük artıyor. İlk şüpheli: cron job’lar.

$ grep "2:30|2:31" /var/log/syslog | grep CRON
Oct 27 02:30:01 webserver CRON[24819]: (root) CMD (/usr/bin/find / -name "*.log" -mtime +30 -delete)

Bulunduk. Biri kök dizinden find komutunu çalıştıracak şekilde bir cron job yazmış. Bu hem CPU hem I/O’yu felç eder.

Senaryo 2: Web Sunucusunda Ani Trafik Artışı

$ uptime
 16:45:22 up 8 days,  2:11,  2 users,  load average: 28.71, 15.44, 6.83

$ w -h | grep -v "pts/[0-1]"

16 core’lu bu sunucuda load average 28’e çıkmış. 1 dakikalık değer çok yüksek, demek ki az önce başladı. w çıktısında tüm worker process’lerin Apache/PHP olduğunu görüyorsunuz. Bu bir trafik dalgası veya DDoS olabilir.

$ netstat -an | grep :80 | grep ESTABLISHED | wc -l
4821

$ netstat -an | grep :80 | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -5
    342 45.33.32.156
    298 198.199.14.255
    187 104.131.0.69
     43 192.168.1.0
     12 10.0.0.1

Üç IP’den anormal bağlantı. Bu noktada load average size ilk ipucunu verdi, gerisi araştırmanın getirdiği sonuç.

Senaryo 3: Yüksek Load ama Düşük CPU Kullanımı

Bu durum sysadmin’leri en çok şaşırtan senaryodur. uptime yüksek load gösteriyor ama top‘ta CPU yüzde on bile değil.

$ uptime
 09:15:33 up 15 days,  6:44,  1 user,  load average: 6.82, 6.91, 7.03

$ top -bn1 | head -5
top - 09:15:33 up 15 days,  6:44,  1 user,  load average: 6.82, 6.91, 7.03
Tasks: 312 total,   1 running, 287 sleeping,   0 stopped,  24 zombie
%Cpu(s):  3.2 us,  1.1 sy,  0.0 ni, 94.8 id,  0.9 wa,  0.0 hi,  0.0 si,  0.0 st

CPU yüzde doksan beş boşta ama load 6.82. Bunun tek açıklaması I/O bekleme durumundaki (D state) süreçler.

$ ps aux | awk '$8 == "D" {print $0}' | head -10
mysql    14823  0.1  2.3 1234568 189432 ?  D    08:52  0.21 /usr/sbin/mysqld
mysql    14824  0.0  2.1 1234568 172144 ?  D    08:52  0.18 /usr/sbin/mysqld
www-data 15012  0.0  0.1  89432   8921 ?  D    09:01  0.02 php-fpm: pool www
www-data 15013  0.0  0.1  89432   8918 ?  D    09:02  0.01 php-fpm: pool www

MySQL process’leri D state’te. Disk I/O sorunu var. iostat ile kontrol:

$ iostat -xz 1 3
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda       0.00  892.00  2.00 445.00  32.00 112340.00   503.77   142.83  318.19    4.50  318.75   2.24 100.00

%util yüzde yüz, await 318ms. Disk tamamen dolu kapasitede çalışıyor ve sıra uzadıkça uzuyor. Yüksek load average sizi doğru yere yönlendirdi.

Load Average İzleme Script’i

Aşağıdaki script, load average’ı düzenli aralıklarla kontrol edip log’a yazan basit bir izleme aracıdır:

#!/bin/bash
# load_monitor.sh - Sistem yuk izleme scripti

LOG_FILE="/var/log/load_monitor.log"
WARN_THRESHOLD=1.5   # CPU basina load uyari esigi
CRIT_THRESHOLD=3.0   # CPU basina load kritik esigi
CHECK_INTERVAL=60    # Saniye cinsinden kontrol araligi

CPU_COUNT=$(nproc)
HOSTNAME=$(hostname)

log_message() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$1] $2" >> "$LOG_FILE"
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$1] $2"
}

while true; do
    read LOAD_1 LOAD_5 LOAD_15 PROCS PID < /proc/loadavg

    RATIO_1=$(echo "scale=3; $LOAD_1 / $CPU_COUNT" | bc)
    RATIO_5=$(echo "scale=3; $LOAD_5 / $CPU_COUNT" | bc)

    D_STATE=$(ps aux | awk '$8 == "D"' | wc -l)

    STATUS="OK"
    if (( $(echo "$RATIO_1 >= $CRIT_THRESHOLD" | bc -l) )); then
        STATUS="CRITICAL"
    elif (( $(echo "$RATIO_1 >= $WARN_THRESHOLD" | bc -l) )); then
        STATUS="WARNING"
    fi

    log_message "$STATUS" "Load: ${LOAD_1}/${LOAD_5}/${LOAD_15} | CPU: ${CPU_COUNT} | Ratio: ${RATIO_1} | D-state procs: ${D_STATE} | Active: ${PROCS}"

    sleep "$CHECK_INTERVAL"
done

who ve last Komutlarıyla Ek Bağlam

w komutuna ek olarak, who ve last komutları da kullanıcı aktivitesi hakkında bilgi verir.

# Mevcut oturumlar (w'nun daha basit versiyonu)
$ who
ahmet    pts/0        2024-10-27 13:15 (192.168.1.45)
root     pts/1        2024-10-27 14:20 (192.168.1.10)

# Son giriş/çıkışları göster
$ last | head -10
ahmet    pts/0        192.168.1.45     Sun Oct 27 13:15   still logged in
root     pts/1        192.168.1.10     Sun Oct 27 14:20   still logged in
deploy   pts/2        10.0.0.5         Sun Oct 27 11:00 - 12:45  (01:45)
ahmet    pts/0        192.168.1.45     Sat Oct 26 09:30 - 18:22  (08:52)

# Sadece belli bir kullanıcının gecmisine bak
$ last ahmet | head -5

Uptime ve Load’u Cron ile Periyodik Log’lama

Basit ama etkili bir yöntem: sistem durumunu her 5 dakikada bir log’a atmak.

# /etc/cron.d/syslog_load dosyasina ekle
*/5 * * * * root echo "$(date '+%Y-%m-%d %H:%M') | $(uptime)" >> /var/log/load_history.log

Sonradan analiz için:

# Belirli bir gundeki yuksek load degerlerini bul
$ grep "2024-10-27" /var/log/load_history.log | awk -F'load average: ' '{print $2}' | 
  awk -F',' '{if ($1 > 4) print NR, $0}'

# En yuksek load anlari
$ grep "2024-10-27" /var/log/load_history.log | sort -t: -k4 -rn | head -5

Önemli İnce Noktalar

Yük ortalamasıyla ilgili bilmesi gereken birkaç kritik nokta:

  • Kısa süreli spike’lar normaldir: Web sunucusunda her gün aynı saatte 10 saniyeliğine load yüksekse ve sistem normale dönüyorsa, bu genellikle sorun değildir.
  • Sürekli yüksek load sorunludur: 15 dakikalık ortalama sürekli eşiğin üzerindeyse, kapasite planlaması veya optimizasyon gereklidir.
  • CPU sayısını asla unutma: Tek core’lu küçük bir VPS’te load average 2.0 ciddi bir sorundur. 64 core’lu bir sunucuda aynı değer neredeyse boşta anlamına gelir.
  • D state süreçleri CPU ile ilgili değildir: Yüksek load + düşük CPU = I/O problemi denklemi aklınızda kalsın.
  • Hyperthreading’e dikkat: nproc genellikle mantıksal CPU sayısını verir. Hyperthreading açıksa, fiziksel core sayısının iki katını görebilirsiniz. Performans değerlendirmesinde fiziksel core sayısı daha gerçekçi bir baz oluşturur.

Sonuç

uptime ve w komutları, sadece birkaç saniye içinde sistemin genel sağlık durumu hakkında size güvenilir bir fotoğraf çeker. Ancak bu fotoğrafı doğru okumak, yani load average değerini CPU sayısına göre normalize etmek ve üç zaman dilimindeki trendi birlikte değerlendirmek, deneyimli bir sysadmin’i ortalama bir kullanıcıdan ayıran şeydir.

Herhangi bir sunucuya bağlandığınızda alışkanlık olarak w yazın. Size hem uptime hem load average hem de kim ne yapıyor sorusunun cevabını tek bir ekranda verir. Yüksek load gördüğünüzde paniğe kapılmadan önce CPU sayısına bölün, trend yönüne bakın ve D state süreçlerini kontrol edin. Çoğu zaman sorunun kaynağı bu basit analiz süreciyle kendini ele verir.

Monitoring araçları, grafikler ve dashboard’lar ne kadar gelişmiş olursa olsun, terminal başındaki bir sysadmin için uptime ve w her zaman ilk refleks olmaya devam edecek.

Yorum yapın