Sunucuya bağlandınız, uptime yazdınız ve "load average: 7.84, 6.20, 4.11" gibi bir satır gördünüz. Bu sayı yüksek mi, düşük mü, panik yapmanız gerekiyor mu? Load average (yük ortalaması), Linux sunucularda en sık bakılan ama en sık yanlış yorumlanan göstergelerden biridir. Çoğu kişi onu "CPU kullanım yüzdesi" sanır; oysa Linux'ta bu sayı yalnızca işlemciyi değil, diski bekleyen süreçleri de sayar.
Bu rehberde load average'ın Linux'ta tam olarak neyi saydığını, CPU çekirdek sayısıyla nasıl karşılaştırılacağını, uptime, top, htop, vmstat ve iostat çıktılarının nasıl okunacağını ve "load yüksek ama CPU boşta" durumunun neden çoğu zaman bir disk (I/O) sorunu olduğunu adım adım anlatıyoruz. Komutlar Ubuntu 24.04 LTS için yazıldı; diğer dağıtımlarda da büyük ölçüde aynıdır.
Load average Linux'ta neyi sayar?
Kaynak, çekirdeğin sunduğu /proc/loadavg dosyasıdır. proc_loadavg(5) kılavuz sayfasına göre ilk üç alan, çalışma kuyruğundaki (durum R) veya disk G/Ç'sini bekleyen (durum D) işlerin 1, 5 ve 15 dakikalık ortalamalarıdır. uptime(1) sayfası da aynı şeyi söyler: yük ortalaması, çalışabilir ya da kesintisiz uyku (uninterruptible) durumundaki süreçlerin ortalama sayısıdır ve kesintisiz uykudaki bir süreç örneğin diski beklemektedir.
cat /proc/loadavg
# Örnek çıktı biçimi:
# 2.15 1.80 1.42 3/412 98765
# 1 dk | 5 dk | 15 dk | çalışabilir/toplam görev | son oluşturulan PID- R (running/runnable): CPU üzerinde çalışan veya CPU sırası bekleyen süreçler.
- D (uninterruptible sleep): Genellikle disk veya ağ dosya sistemi gibi bir G/Ç işleminin bitmesini bekleyen, sinyalle bile kesilemeyen süreçler.
- Sayılmayanlar: Normal uykudaki (S) süreçler, örneğin bağlantı bekleyen boşta bir Nginx işçisi, yükü artırmaz.
Üç sayı nasıl okunur?
Üç değer sırasıyla son 1, 5 ve 15 dakikayı özetler. Aralarındaki ilişki, yükün yönünü gösterir:
| Örnek | Yorum |
|---|---|
0.50, 2.40, 4.10 | Yük düşüyor; sorun geçmiş veya bitiyor. |
6.80, 3.10, 1.20 | Yük yeni yükseliyor; şimdi bakmanın tam zamanı. |
4.00, 4.05, 3.98 | Uzun süredir sabit bir yük var; çekirdek sayısıyla karşılaştırın. |
Çekirdek sayısıyla karşılaştırma
uptime(1) açıkça belirtir: load average, CPU sayısına göre normalize edilmez. Tek CPU'lu bir sistemde 1 yükü, işlemcinin sürekli dolu olduğu anlamına gelir; 4 CPU'lu bir sistemde ise aynı 1 değeri, zamanın yüzde 75'inde boşta kalındığını gösterir. Önce sunucunuzun kaç mantıksal işlemcisi olduğunu öğrenin:
nproc
lscpu | grep -E "^CPU\(s\)|Thread|Core|Model name"| Load / çekirdek oranı | Kaba yorum |
|---|---|
| 1'in altında | Kaynaklar talebi karşılıyor, bekleyen iş az. |
| 1 civarı | Kapasite dolmak üzere; yanıt süreleri izlenmeli. |
| Sürekli 1'in üzerinde | İş birikiyor; nedeni (CPU mu, G/Ç mi) bulunmalı. |
Adım 1: uptime ve top ile ilk bakış
uptime
toptop(1) çıktısının üst kısmındaki %Cpu(s) satırı, yükün kaynağını hemen ayırt etmenizi sağlar:
| Alan | Anlamı (top kılavuzu) | Yüksekse |
|---|---|---|
us | Nice değeri değiştirilmemiş kullanıcı süreçleri | Uygulama kodu CPU yakıyor (PHP, Node, Python) |
sy | Çekirdek (kernel) süreçleri | Çok sayıda sistem çağrısı, ağ trafiği, bağlam değişimi |
wa | G/Ç tamamlanmasını bekleme | Disk darboğazı; load yükselir ama CPU aslında boşta |
st | Hipervizörün bu VM'den aldığı süre (steal) | Sanal sunucuda fiziksel CPU paylaşımı kaynaklı bekleme |
id | Boşta geçen süre | Load yüksek ve id yüksekse büyük ihtimalle G/Ç sorunu |
top içinde 1 tuşu her çekirdeği ayrı satırda gösterme ile tek özet satır arasında geçiş yapar; P CPU'ya, M belleğe göre sıralar. S sütununda D görünen süreçler doğrudan load'a eklenen G/Ç bekleyenlerdir. Daha okunaklı bir arayüz isterseniz sudo apt install htop ile htop kurabilirsiniz; aynı bilgileri renkli çubuklarla gösterir.
Adım 2: vmstat ile R ve B sütunları
vmstat(8) birkaç saniyelik örneklerle yükün bileşenlerini ayırır. İlk satır açılıştan beri ortalamadır; asıl bakmanız gerekenler sonraki satırlardır:
vmstat 2 10 # 2 saniye arayla 10 örnek| Sütun | Anlamı | Ne aramalı? |
|---|---|---|
r | Çalışabilir süreçler (çalışan veya sıra bekleyen) | Çekirdek sayısından sürekli büyükse CPU darboğazı |
b | G/Ç bitmesini bekleyen bloklu süreçler | Sürekli 0'dan büyükse disk darboğazı |
si / so | Diskten belleğe / bellekten diske swap (saniyede) | Sürekli sıfırdan büyükse RAM yetmiyor |
bi / bo | Blok cihazdan okunan / yazılan KiB/s | Disk trafiğinin büyüklüğü |
wa | G/Ç bekleme yüzdesi | Yüksekse sorun diskte |
st | Sanal makineden çalınan süre | Yüksekse fiziksel CPU paylaşımı yoğun |
Kabaca: r yüksekse yük CPU kaynaklıdır, b ve wa yüksekse disk kaynaklıdır, si/so sürekli hareketliyse bellek yetersizliği diski de meşgul ediyordur. Bellek tarafı için OOM killer rehberi ve swap alanı yazısı işinize yarar.
Adım 3: Yüksek load, düşük CPU: I/O wait
En kafa karıştıran tablo budur: load 10, ama top CPU'nun yüzde 70'inin boşta olduğunu söylüyor. Linux'ta bunun en olası açıklaması, D durumunda bekleyen süreçlerdir. Hangi cihazın tıkandığını görmek için sysstat paketindeki iostat aracını kullanın:
sudo apt install sysstat
iostat -xz 2 5Ubuntu 24.04 iostat(1) sayfasındaki tanımlarla en önemli alanlar:
| Alan | Anlamı | Yorum |
|---|---|---|
%iowait | CPU boştayken bekleyen disk isteği olan zamanın yüzdesi | Sistem genelinde G/Ç beklemesi |
r_await / w_await | Okuma / yazma isteklerinin ortalama karşılanma süresi (ms) | NVMe'de genelde çok düşüktür; belirgin artış darboğaz işaretidir |
aqu-sz | Cihaza gönderilen isteklerin ortalama kuyruk uzunluğu | Büyüyen kuyruk, diskin yetişemediğini gösterir |
%util | Cihaza istek gönderilen zamanın yüzdesi | Paralel istek işleyebilen NVMe/SSD'lerde yüzde 100 olması tek başına doygunluk demek değildir |
Sonra diski kimin kullandığını bulun. D durumundaki süreçleri listelemek ve süreç bazında G/Ç görmek için:
# D durumundaki süreçler ve çekirdekte bekledikleri fonksiyon
ps -eo pid,stat,wchan:32,cmd | awk '$2 ~ /^D/'
# Süreç bazında okuma/yazma (sysstat paketi)
pidstat -d 2 5- Disk dolmak üzereyse yazma işlemleri yavaşlar ve hatalar başlar; disk doldu hatası ve inode doldu hatası yazılarına bakın.
- Büyüyen log dosyaları sürekli yazma yükü yaratabilir; logrotate rehberi bu konuyu anlatır.
- Yedekleme saatleri: rsync, mysqldump veya sıkıştırma işleri belirli saatlerde load'u yükseltiyorsa bunları düşük trafikli saatlere taşıyın; rsync ile yedekleme.
- Swap fırtınası:
si/sosürekli hareketliyse sorun disk değil RAM'dir; disk yalnızca belirtidir. - Veritabanı sorguları: İndekssiz sorgular büyük tabloları diskten tekrar tekrar okur.
Adım 4: Yük CPU kaynaklıysa
us veya sy yüksek ve vmstat içinde r çekirdek sayısını sürekli aşıyorsa, yükü hangi sürecin oluşturduğunu bulmanız gerekir. Bunun ayrıntılı yöntemi (ps sıralama, pidstat, iş parçacığı bazında inceleme, PHP-FPM, MySQL ve Node örnekleri) CPU yüzde 100 tespit rehberinde anlatılıyor.
Önleme: load'u izlemek
- Load, CPU,
iowaitve disk doluluğunu düzenli kaydedin. Temeller için sunucu izleme temelleri, grafik ve uyarılar için Prometheus ve Grafana yazılarına bakın. - Sitenizin dışarıdan erişilebilirliğini ayrı bir sunucudan izleyin; Uptime Kuma kurulumu bunun için uygun bir başlangıçtır.
- Uyarıyı tek bir 1 dakikalık değere değil, 5 veya 15 dakikalık ortalamanın çekirdek sayısını uzun süre aşmasına bağlayın; kısa sıçramalar normaldir.
- Yeni bir eklenti, cron işi veya yazılım güncellemesinden sonra load profilinin değişip değişmediğini kontrol edin.
Sık Sorulan Sorular
Load average 1 ne demek?
Son dakikada ortalama bir sürecin çalıştığı veya beklediği anlamına gelir. Tek çekirdekli sunucuda bu tam doluluktur; 4 çekirdekli sunucuda ise kapasitenin dörtte biri kullanılıyor demektir. Değeri mutlaka nproc çıktısıyla birlikte yorumlayın.
Load yüksek ama CPU boşta, neden?
Linux load average'a disk G/Ç'sini bekleyen D durumundaki süreçleri de katar. top içindeki wa, vmstat içindeki b sütunu ve iostat -xz ile diski kontrol edin. Ağ üzerinden bağlanmış bir dosya sistemi (NFS gibi) yanıt vermediğinde de süreçler D durumunda takılabilir.
Load average yüzde olarak ifade edilebilir mi?
Hayır, load bir yüzde değil, ortalama süreç sayısıdır. Yüzdeye benzer bir fikir için load değerini çekirdek sayısına bölebilirsiniz; ama G/Ç bekleyen süreçler de sayıldığı için bu oran CPU kullanımıyla aynı şey değildir.
Sunucuyu yeniden başlatmak load'u düzeltir mi?
Geçici olarak düşürebilir, ama nedeni ortadan kaldırmaz. Yeniden başlatmadan önce top, vmstat 2 10 ve iostat -xz 2 5 çıktılarını kaydedin; aksi halde sorunun izini kaybedersiniz. Logların nerede olduğunu Linux loglarını okuma yazısında bulabilirsiniz.
Yazılım ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen projeler veya şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.
İlgili içerikler: CPU yüzde 100 tespiti · OOM killer çözümü · inode doldu hatası · logrotate rehberi · Sunucu izleme temelleri · Disk doldu hatası · Linux sunucu komutları