Load Average Nasıl Okunur

Sunucuya SSH ile bağlandığında karşına çıkan ilk satırlardan biri load average değeridir ve muhtemelen onu "yüksekse kötü, düşükse iyi" diye okuyorsun. Bu kaba yaklaşım çoğu zaman yanlış karar vermene yol açar: 8 çekirdekli bir makinede 6,00 load tamamen sağlıklıyken, tek çekirdekli bir VPS'te 2,00 load sitenin çoktan yavaşladığı anlamına gelir. Üstelik load average yalnızca CPU'yu ölçmez; Linux'ta disk beklemesindeki süreçler de bu sayıya dahildir, yani CPU boşta dururken load 20'ye tırmanabilir.

Bu rehberde load average'ın tam olarak neyi saydığını, üç sayının neden farklı zaman pencerelerini temsil ettiğini, çekirdek sayısına bölerek nasıl normalize edeceğini ve yüksek yükün kaynağını top, vmstat, iostat, pidstat gibi araçlarla nasıl ayıracağını anlatacağım. Sonunda kendi sunucun için makul bir alarm eşiği belirleyebilecek ve "load 15'e çıktı, panik" refleksinden çıkıp "load 15 ama iowait %0, bu bir derleme işi, sorun yok" diyebilecek düzeye geleceksin.

Load Average Aslında Neyi Sayar#

Load average, sistemdeki çalıştırılabilir (runnable) ve kesintisiz uykuda (uninterruptible sleep) olan süreçlerin zamana yayılmış üstel hareketli ortalamasıdır. Çalıştırılabilir süreçler ya o an bir CPU çekirdeğinde koşuyordur ya da sırada çekirdek bekliyordur. Kesintisiz uyku ise klasik olarak disk veya ağ dosya sistemi I/O'sunu bekleyen, ps çıktısında D durumunda görünen süreçlerdir. Bu ikinci grup, Linux'un load average tanımını diğer Unix türevlerinden ayıran kritik farktır ve çoğu yanlış yorumun kaynağıdır.

Pratikte şu şekilde düşün: load average, "şu an ilerlemek isteyen ama ilerleyemeyen ya da ilerlemek için sıra bekleyen iş sayısı"dır. Bir markette kasa metaforu işe yarar. Tek kasan (tek çekirdek) varsa ve kuyrukta ortalama 1 kişi varsa, kasa tam kapasite çalışıyor ama kimse beklemiyor demektir; load 1,00. Kuyrukta 4 kişi varsa üçü bekliyordur; load 4,00 ve bekleme süresi hissedilir. Ama 4 kasan varsa (4 çekirdek), 4 kişilik kuyruk hiç bekleme üretmez. Load değerinin mutlak sayı olarak hiçbir anlamı yoktur; çekirdek sayısıyla birlikte anlam kazanır.

Değeri okumanın en hızlı yolu uptime komutudur:

# Yük ortalamalarını ve sistemin ne kadar süredir açık olduğunu göster
uptime
# Örnek çıktı:
#  14:32:07 up 42 days,  3:11,  2 users,  load average: 1.42, 2.08, 3.65

# Aynı bilgi ham hâliyle proc dosya sisteminde durur
cat /proc/loadavg
# Örnek çıktı:
# 1.42 2.08 3.65 3/512 28841

/proc/loadavg çıktısındaki dördüncü alan 3/512, o an çalışan süreç sayısı / toplam süreç sayısıdır; beşinci alan ise sistemde oluşturulmuş son sürecin PID'idir. Bu iki alan alarm kurarken işine yaramaz ama "512 süreç mi var?" diye şaşırdığında nereden geldiğini bilmen iyi olur.

Üç Sayı: 1, 5 ve 15 Dakika#

Load average tek sayı değil, üç sayıdır ve bunlar sırasıyla son 1 dakika, son 5 dakika ve son 15 dakikalık üstel ağırlıklı ortalamalardır. Bu üçlüyü yan yana okumak sana bir trend verir ve tek başına anlık bir değerden çok daha değerlidir. Aralarındaki ilişkiyi okumayı öğrendiğinde, "sorun büyüyor mu, geçiyor mu" sorusunu tek bakışta yanıtlarsın.

Bu tabloyu ezberlemene gerek yok; mantığı şudur ki 15 dakikalık değer sistemin "normal"ini, 1 dakikalık değer ise "şu an"ını gösterir. Bir alarm aldığında sunucuya bağlanıp yalnızca 1 dakikalık değere bakıp panikleme; üçünü birlikte oku. 15 dakikalık değer hâlâ düşükse, yaşadığın şey büyük ihtimalle bir yedekleme işi, bir cron görevi ya da bir arama motoru botunun ani taraması gibi geçici bir olaydır. Bu tür periyodik sıçramaların kalıcı hâle gelip gelmediğini anlamak için site belirli saatlerde yavaşlıyor yazısındaki saat bazlı analiz yöntemi işini kolaylaştırır.

Çekirdek Sayısına Bölmeden Yorum Yapmayın#

Load average'ı anlamlı kılan tek işlem, onu mevcut CPU çekirdeği sayısına bölmektir. Buna normalize edilmiş yük diyoruz ve 1,00 değeri "sistem tam kapasitede, kuyruk yok" anlamına gelir. 1,00'in üzeri bekleme, altı ise boşta kapasite demektir. Çekirdek sayını öğrenmek için:

# Mantıksal çekirdek (thread) sayısı
nproc
# Örnek çıktı: 4

# Ayrıntılı bilgi: soket, çekirdek, thread dağılımı
lscpu | grep -E '^CPU\(s\)|Thread|Core|Socket'

Dört çekirdekli bir sunucuda 4,00 load, tüm çekirdeklerin dolu ama kimsenin beklemediği ideal noktadır. 6,00 ise yaklaşık %50 fazladan kuyruk demektir ve web isteklerinin yanıt süresine yansımaya başlamıştır. Aşağıdaki tablo pratikte kullandığım kaba yorumlama ölçeğidir:

Bu hesabı her seferinde kafadan yapmak yerine tek satırlık bir kontrol yazabilirsin:

# Normalize edilmiş 1 dakikalık yükü hesapla
awk -v c="$(nproc)" '{printf "Normalize yuk: %.2f\n", $1 / c}' /proc/loadavg
# Örnek çıktı:
# Normalize yuk: 0.36

Sanal sunucularda ek bir incelik var: nproc sana vCPU sayısını verir ama komşu sanal makinelerin aynı fiziksel çekirdeği paylaştığı yoğun ortamlarda gerçek erişebildiğin kapasite daha az olabilir. Bunu top içindeki st (steal time) sütunundan anlarsın; kalıcı olarak sıfırdan büyük bir steal değeri, hipervizörün CPU'yu senden başkasına verdiğini gösterir. Bu tür belirsizliklerin olmadığı ayrılmış kaynak istiyorsan VDS sunucular ya da dedicated sunucu tarafına bakmak gerekir.

Load Yüksek Ama CPU Boş: I/O Bekleme Tuzağı#

En kafa karıştırıcı senaryo şudur: load average 18,00, ama top çıktısında CPU kullanımı %5. Bu bir ölçüm hatası değil; yükün tamamı disk beklemesinden geliyordur. Linux, D durumundaki süreçleri de load'a saydığı için yavaş bir disk, dolu bir I/O kuyruğu ya da ağ üzerinden bağlı bir depolama birimi tek başına load'ı tavana vurdurabilir. CPU'yu büyütmek bu durumda hiçbir işe yaramaz; sorun depolamadadır.

Ayrımı yapmanın en hızlı yolu top çıktısındaki CPU satırıdır:

# Tek seferlik özet al, ilk 5 satırı göster
top -b -n 1 | head -5
# Örnek çıktı:
# top - 15:04:22 up 12 days,  4:02,  1 user,  load average: 18.44, 16.02, 9.71
# Tasks: 431 total,   1 running, 187 sleeping,   0 stopped,   0 zombie
# %Cpu(s):  4.1 us,  1.2 sy,  0.0 ni, 12.7 id, 81.4 wa,  0.0 hi,  0.6 si,  0.0 st

Buradaki 81.4 wa değeri iowait'tir ve CPU'nun zamanının %81'ini disk yanıtı bekleyerek geçirdiğini söyler. id (idle) %12'de ama sistem tamamen kilitlenmiş hissi verir. Bu tabloyu gördüğünde bakman gereken yer depolamadır:

# Disk bazında kullanım oranı ve bekleme süresi (sysstat paketi gerekir)
iostat -x 2 3
# Anahtar sütunlar: %util (aygıt doluluk), await (ms cinsinden ortalama bekleme)

# Hangi süreç ne kadar okuyor/yazıyor
pidstat -d 2 3

# D durumundaki süreçleri listele
ps -eo state,pid,comm --no-headers | awk '$1 ~ /D/ {print}'

%util değerinin sürekli %90 üstünde olması ve await süresinin dönen disklerde 20 ms, SSD'lerde 5 ms üzerine çıkması, depolamanın darboğaz olduğunu doğrular. Bu noktada tipik suçlular şunlardır: optimize edilmemiş veritabanı sorguları yüzünden diske taşan geçici tablolar, yetersiz RAM nedeniyle swap kullanımı, aynı anda çalışan bir yedekleme işi ve log dosyalarına saniyede binlerce satır yazan bir uygulama. Veritabanı kaynaklı I/O baskısını hafifletmenin en etkili yolu genellikle sorgu önbelleği eklemektir; Memcached nedir yazısı bu katmanın nasıl kurulduğunu adım adım gösteriyor.

Yüksek Yükün Kaynağını Bulma Akışı#

Yüksek load gördüğünde rastgele komut denemek yerine sabit bir sıra izle. Aşağıdaki beş adım, sorunun sınıfını dakikalar içinde daraltır:

1. Yükü normalize et. nproc ile çekirdek sayısını al, 1/5/15 dakikalık değerleri böl. Trend yükseliyor mu, düşüyor mu belirle.
2. CPU mu, I/O mu ayır. top çıktısındaki us, sy, wa, st sütunlarına bak. wa yüksekse depolamaya, us yüksekse uygulamaya, sy yüksekse çekirdek/ağ katmanına, st yüksekse hipervizöre yönel.
3. Süreçleri sırala. top içinde büyük P harfiyle CPU'ya, M ile belleğe göre sırala. En üstteki üç süreci not al.
4. Zaman damgasıyla eşleştir. Web sunucusu erişim loglarında aynı dakikada ne olduğuna bak. Ani bir istek patlaması mı, tek bir ağır sayfa mı, bir bot mu?
5. Geçmişle karşılaştır. Bu yük dün aynı saatte de var mıydı? Cron tablosunda o dakikada çalışan bir iş var mı?

Dördüncü adım için pratik bir komut seti:

# Son 10 dakikada en çok istek atan IP'ler (Nginx varsayılan log biçimi)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# En çok istenen 10 yol
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Sistemdeki tüm cron tanımlarını tek yerde gör
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Bu akışın tamamını, uygulama katmanı da dahil olacak şekilde genişletilmiş hâlini yavaş site teşhis akışı yazısında bulabilirsin. Yükün kaynağı çoğu zaman insan trafiği değil otomatik tarayıcılardır; o senaryoyu bot trafiği ve sunucu yükü yazısı ayrıntılı işliyor.

Hangi Eşikte Alarm Kurmalı#

Sabit bir load eşiği ("5'i geçerse haber ver") farklı boyuttaki sunucularda anlamsız olduğu için alarmını her zaman normalize edilmiş değere kur. Pratikte iyi çalışan yapılandırma şudur: 5 dakikalık load / çekirdek sayısı 1,5'i 10 dakika boyunca aşarsa uyarı, 3,0'ı 5 dakika boyunca aşarsa kritik alarm. 1 dakikalık değere alarm kurmak gereksiz gürültü üretir; sabah çalışan bir yedekleme işi seni her gün uyandırır.

Basit bir kontrol betiği şöyle görünebilir:

#!/bin/bash
# 5 dakikalık normalize yükü eşikle karşılaştır
CORES=$(nproc)
LOAD5=$(awk '{print $2}' /proc/loadavg)
NORM=$(awk -v l="$LOAD5" -v c="$CORES" 'BEGIN{printf "%.2f", l/c}')
LIMIT=1.5

if awk -v n="$NORM" -v t="$LIMIT" 'BEGIN{exit !(n > t)}'; then
  echo "UYARI: normalize yuk $NORM (esik $LIMIT, cekirdek $CORES)"
  exit 1
fi
echo "OK: normalize yuk $NORM"

Bu betiği cron ile 5 dakikada bir çalıştırıp çıktısını izleme sistemine bağlayabilirsin. Ancak load tek başına iyi bir kullanıcı deneyimi göstergesi değildir; asıl bakman gereken şey ziyaretçinin gördüğü yanıt süresidir. Yani load alarmını destekleyici bir sinyal olarak tut, birincil alarmı sunucu yanıt süresi izleme yazısında anlattığım HTTP ölçümlerine kur. Uptime hedeflerini ve kabul edilebilir kesinti bütçesini hesaplarken uptime ve SLA hesaplayıcı aracımız işini kolaylaştırır.

Sık Yapılan Hatalar#

En yaygın hata, load average'ı yüzde olarak okumaktır. 1,00 değeri "%100 CPU" demek değildir; tek çekirdekli bir makinede öyle sayılabilir ama 8 çekirdekli bir makinede 1,00 kabaca %12,5 doluluğa denk gelir. İkinci hata, yüksek load görünce refleks olarak CPU büyütmektir. Yükün kaynağı iowait ise daha fazla çekirdek hiçbir şey değiştirmez, sadece faturayı büyütür.

Üçüncü hata, load'ı yalnızca sorun anında bakılan bir değer olarak görmektir. Geçmiş veri olmadan "bu yük normal mi" sorusunu yanıtlayamazsın; bu yüzden load'ı en az birkaç haftalık geçmişiyle saklayan bir izleme aracın olmalı. Dördüncü hata, konteynerli ortamlarda konteyner içinden okunan load'ın host'un yükünü gösterdiğini bilmemektir; /proc/loadavg konteyner sınırlarına göre izole değildir, yani konteyner içinde gördüğün değer komşularının yükünü de içerir.

Son olarak, nice ile düşük önceliğe alınmış işlerin de load'a sayıldığını unutma. Gece çalışan nice -n 19 bir yedekleme işi load'ı 10'a çıkarabilir ama web isteklerini neredeyse hiç etkilemez, çünkü zamanlayıcı öncelikli işlere yol verir. Bu yüzden yüksek load gördüğünde "kullanıcı gerçekten yavaşlık yaşıyor mu" sorusunu ayrıca yanıtla; iki soru aynı değildir.

Sıkça Sorulan Sorular#

Load average kaç olmalı#

Tek bir doğru sayı yok; değeri çekirdek sayısına bölerek yorumlaman gerekir. Normalize edilmiş değerin 0,70 altında olması rahat, 1,00 civarı tam kapasite, 2,00 üstü ise belirgin bekleme anlamına gelir. Yani 8 çekirdekli bir sunucuda 5,60 load sağlıklıyken, 2 çekirdekli bir VPS'te aynı değer ciddi bir darboğazdır.

Load average yüksek ama site hızlı, sorun var mı#

Genellikle yok. Yüksek load, düşük öncelikli arka plan işlerinden (yedekleme, log sıkıştırma, indeksleme) kaynaklanıyorsa web isteklerinin yanıt süresine yansımayabilir. Kullanıcı deneyimini ölçen gerçek gösterge, sayfaların yanıt süresi ve hata oranıdır. Load'ı destekleyici bir sinyal olarak izle, tek başına karar verme.

Load average CPU kullanımı ile aynı şey mi#

Hayır. CPU kullanımı, çekirdeklerin ne kadar süre meşgul olduğunu yüzde olarak verir. Load average ise çalışan artı bekleyen iş sayısını sayar ve Linux'ta disk beklemesindeki süreçleri de içerir. Bu yüzden CPU %5'te dururken load 20'ye çıkabilir; böyle bir tabloda sorun depolamadadır, işlemcide değil.

Yüksek load'ın disk kaynaklı olduğunu nasıl anlarım#

top komutunun CPU satırındaki wa (iowait) değerine bak. Bu değer kalıcı olarak %20'nin üzerindeyse sistem zamanının önemli kısmını disk bekleyerek geçiriyor demektir. Ardından iostat -x 2 ile %util ve await sütunlarını kontrol et; doluluk %90'ı, bekleme süresi SSD'de 5 ms'yi aşıyorsa depolama darboğazı doğrulanmış olur.

Load average'ı düşürmek için ne yapmalıyım#

Önce kaynağı sınıflandır. CPU kaynaklıysa ağır uygulama kodunu profille, önbellek katmanı ekle ve gereksiz cron işlerini seyrelt. I/O kaynaklıysa sorguları optimize et, RAM ekleyerek swap kullanımını bitir ve yedekleme saatlerini trafiğin düşük olduğu zamana al. Kaynak gerçekten yetmiyorsa çekirdek veya disk kapasitesini artırmak doğru adımdır.

Paylaşımlı hostingte load average'ı görebilir miyim#

Çoğu paylaşımlı hosting hesabında SSH erişimi kısıtlıdır ve gördüğün değer sunucunun tamamına ait olur, yalnızca senin sitene değil. Bu yüzden paylaşımlı ortamda load takibi yerine kendi sitenin yanıt süresini ve hata oranını izlemek çok daha anlamlıdır. Sunucu düzeyinde tam görünürlük istiyorsan root erişimi olan bir sanal ya da fiziksel sunucuya geçmen gerekir.

Konteyner içinde okuduğum load average doğru mu#

Kısmen. /proc/loadavg dosyası konteyner sınırlarına göre izole edilmez, dolayısıyla konteyner içinden okuduğun değer host makinenin tamamının yükünü yansıtır. Konteynerin kendi CPU tüketimini ölçmek için cgroup sayaçlarına ya da konteyner çalıştırıcısının sunduğu istatistik komutlarına bakman gerekir.

Kapanış#

Load average, doğru okunduğunda sunucunun sağlığı hakkında saniyeler içinde fikir veren güçlü bir göstergedir; yanlış okunduğunda ise seni gereksiz donanım harcamalarına ve yanlış teşhislere sürükler. Aklında kalması gereken dört alışkanlık şu: değeri her zaman çekirdek sayısına böl, üç sayıyı birlikte okuyup trendi çıkar, yükün CPU mu yoksa iowait kaynaklı mı olduğunu top satırından hemen ayır ve alarmlarını 1 dakikalık değere değil 5 dakikalık normalize değere kur.

Sunucunun kaynak profilini büyütmeyi düşünüyorsan ya da yüksek yükün kaynağını tek başına kovalamak istemiyorsan Clou.TR tarafında birkaç seçenek var. Ayrılmış çekirdek ve NVMe depolama isteyen projeler için VDS sunucular, tam donanım kontrolü gerektiren yükler için dedicated sunucu, izleme kurulumu ve performans ayarlarını bize bırakmak istersen sunucu yönetimi hizmetimiz bu işleri sizin yerinize üstlenir. Ölçümlerini derinleştirmek için ücretsiz araçlar sayfamıza da göz atabilirsin.