Linux Load Average Nasıl Yorumlanır

Bir sistem yöneticisinin sunucuya bağlanınca ilk yazdığı komutlardan biri uptime'dır ve çoğu zaman gözü doğrudan satırın sonundaki üç sayıya kayar: load average. "Yük yüksek" diye panik yapan da, "0.80 sorun değil" diye rahatlayan da bu üç sayıya bakar. Oysa aynı 4.0 değeri bir sunucuda tam kapasite çalışmayı, bir başkasında ise sistemin boğulduğunu anlatabilir. Load average, doğru yorumlandığında sunucunuzun sağlığı hakkında saniyeler içinde fikir veren güçlü bir göstergedir; yanlış yorumlandığında ise sizi olmayan bir sorunun peşinde koşturur ya da gerçek bir sorunu görmezden gelmenize yol açar.

Bu rehberde load average'ın gerçekte neyi saydığını, 1-5-15 dakikalık üç değerin ne anlattığını, bu sayıyı neden mutlaka çekirdek sayısıyla birlikte okumanız gerektiğini ve en kritik ayrımı — yükün CPU'dan mı yoksa disk beklemesinden (I/O) mi geldiğini — nasıl ayırt edeceğinizi uygulamalı örneklerle ele alacağız. Ardından yüksek yükün kaynağına adım adım nasıl ineceğinizi göstereceğiz. Terminal komutlarına henüz yabancıysanız önce temel Linux komutları yazımıza göz atmanız, buradaki örnekleri daha rahat takip etmenizi sağlar.

Load Average Tam Olarak Neyi Sayar#

Load average, sisteminizin belirli bir zaman aralığındaki ortalama "iş talebini" gösteren bir sayıdır. En yaygın yanlış anlama, bunun bir CPU yüzdesi olduğunu sanmaktır; oysa load average bir yüzde değil, bir süreç sayısı ortalamasıdır. Daha teknik söylersek, ortalama olarak kaç sürecin ya çalışmakta (running) ya da çalışmayı bekliyor (runnable) durumda olduğunu ifade eder.

Linux'ta burada önemli bir ayrıntı vardır ve bu, load'ı doğru yorumlamanın anahtarıdır. Diğer bazı Unix sistemlerinden farklı olarak Linux, load hesabına yalnızca CPU sırasında bekleyen süreçleri değil, kesintisiz uykuda (uninterruptible sleep, D durumu) bekleyen süreçleri de katar. Bu D durumundaki süreçler neredeyse her zaman diskten ya da ağ depolamasından veri gelmesini bekleyen süreçlerdir. Yani Linux'ta load, saf CPU talebi değil, "CPU + disk beklemesi" karışık bir talep göstergesidir. Bu yüzden yüksek bir load, CPU'nun yanmasından da diskin yavaşlığından da kaynaklanabilir; hangisi olduğunu ayırt etmek ise ayrı bir iştir ve ilerideki bölümde tam olarak buna değineceğiz.

Değeri en hızlı görmenin yolu uptime komutudur:

$ uptime
 14:32:07 up 12 days,  3:41,  2 users,  load average: 0.42, 0.75, 1.10

Aynı üç sayıyı çekirdek verisini ayrıştırmak isterseniz doğrudan çekirdekten de okuyabilirsiniz:

$ cat /proc/loadavg
0.42 0.75 1.10 2/345 18294

Buradaki ilk üç sayı yine 1, 5 ve 15 dakikalık load değerleridir. Dördüncü alandaki 2/345 ise "o an çalışan/toplam süreç" sayısını, son alandaki 18294 ise en son oluşturulan sürecin PID'sini verir. top, htop ve w komutları da aynı load average değerlerini üst satırlarında gösterir; hepsi çekirdeğin tuttuğu aynı kaynaktan okur.

1, 5 ve 15 Dakikalık Değerler Ne Anlatır#

Load average'ın üç ayrı sayı olarak verilmesi rastlantı değildir. Bu üç değer sırasıyla son 1 dakikanın, son 5 dakikanın ve son 15 dakikanın ağırlıklı ortalamasıdır. Tek bir anlık değer yerine üç farklı pencere sunulmasının nedeni, size yükün yönünü — artıyor mu, azalıyor mu, sabit mi — okuma imkânı vermesidir.

Mantık şöyle işler. 1 dakikalık değer en tepkiseldir, ani sıçramaları hemen yansıtır. 15 dakikalık değer ise en yavaş, en "sakin" olandır; kısa dalgalanmaları yutar ve genel eğilimi gösterir. Üçünü birlikte okuduğunuzda şu tabloyu çıkarabilirsiniz:

Somut bir örnek üzerinden gidelim. load average: 4.80, 2.10, 1.05 gördüğünüzde, 1 dakikalık değer 15 dakikalık değerin neredeyse beş katı demektir; bu, dakikalar öncesine kadar sakin olan bir sunucuda şu anda bir şeyin patladığını anlatır (belki bir trafik dalgası, belki yeni başlayan ağır bir sorgu). Tersine load average: 0.90, 2.30, 4.50 gördüğünüzde, yakın geçmişte ciddi bir yük olmuş ama artık geçiyordur; bu durumda hemen müdahale etmek yerine sistemin kendiliğinden toparlanmasını izleyebilirsiniz. Bu yön okuması, tek başına anlık bir değere bakmaktan çok daha değerlidir; çünkü size sorunun evresini söyler.

Çekirdek Sayısıyla Normalize Etmek#

Şimdi rehberin en kritik kuralına geldik. Load average'ı tek başına bir sayı olarak yorumlamak neredeyse anlamsızdır; bu sayı ancak sunucunuzun CPU çekirdek sayısıyla kıyaslandığında bir anlam kazanır. Nedeni basittir: load, CPU'nun işleyebileceğinden kaç kat fazla iş talebi olduğunu ölçer ve her çekirdek aynı anda bir işi çalıştırabilir.

Çekirdek sayınızı öğrenmek için nproc yeterlidir; daha ayrıntısı için lscpu kullanabilirsiniz:

# Toplam mantıksal çekirdek (thread) sayısı
$ nproc
4

# CPU mimarisi ve çekirdek detayları
$ lscpu | grep -E '^CPU\(s\)|Core|Thread'

Temel kural şudur: load değerini çekirdek sayısına bölün. Sonuç, çekirdek başına düşen yükü verir.

• load / çekirdek = 1.0 → CPU tam kapasitede, ama henüz kuyruk birikmemiş. İdeal- üst sınır.
• load / çekirdek < 1.0 → Boş kapasite var, sistem rahat.
• load / çekirdek > 1.0 → İş kuyruğu birikiyor, süreçler CPU sırasında bekliyor, gecikme başlıyor.

Bunu tabloyla netleştirelim. Aynı 4.0 load değeri farklı sunucularda çok farklı anlamlar taşır:

Gördüğünüz gibi tek çekirdekli bir VPS'te 4.0 yangın alarmıyken, 8 çekirdekli bir VDS'te aynı değer gayet sağlıklıdır. Pratikte pek çok yönetici "çekirdek başına 0.7'nin altı huzur, 1.0 civarı dikkat, 2.0 ve üstü acil" gibi bir eşik benimser. Kendi normalize edilmiş değerinizi tek satırda hesaplamak isterseniz:

# 1 dakikalık load'u çekirdek sayısına böler (çekirdek başına yük)
awk -v c=$(nproc) '{printf "Cekirdek basina yuk: %.2f\n", $1/c}' /proc/loadavg

Bir uyarı: nproc mantıksal çekirdek (Hyper-Threading dahil thread) sayısını verir. Hyper-Threading'li fiziksel bir çekirdek iki mantıksal çekirdek gösterir ama gerçek paralel iş gücü bire bir iki kat değildir; bu yüzden eşiklerinizi biraz temkinli tutmakta fayda vardır.

CPU mu, IO mu? Darboğazı Ayırt Etmek#

Load average yüksek çıktı diyelim — peki suçlu CPU mu, yoksa disk mi? Bu, yanlışlıkla en çok karıştırılan noktadır ve yanlış teşhis, yanlış çözüme (gereksiz CPU yükseltmeye ya da boşuna kod optimizasyonuna) yol açar. Hatırlayın: Linux'ta load hesabına hem CPU bekleyen hem de disk bekleyen (D durumu) süreçler girer. Dolayısıyla yüksek load tek başına "CPU yetmiyor" demek değildir.

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

%Cpu(s):  6.2 us,  1.8 sy,  0.0 ni, 12.4 id, 79.1 wa,  0.0 hi,  0.5 si

Burada kritik alanlar şunlardır. us (user) kullanıcı programlarının, sy (system) çekirdeğin harcadığı CPU oranıdır; ikisi de yüksekse gerçek bir CPU darboğazı var demektir. id (idle) boşta geçen orandır. Ama asıl bakmanız gereken wa (I/O wait), yani CPU'nun disk/ağ yanıtı beklerken boş oturduğu orandır. Yukarıdaki örnekte wa %79'dur — bu, yükün neredeyse tamamının disk beklemesinden geldiğini, CPU'nun aslında boş ama bekleyerek boş olduğunu anlatan tipik bir disk darboğazı tablosudur.

Basit bir ayrım kılavuzu:

Disk beklemesini doğrulamak için vmstat çok kullanışlıdır. Çıktının wa sütununu ve b (uninterruptible sleep'te bekleyen süreç sayısı) sütununu izleyin:

# Her 1 saniyede bir örnek al
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1 6      0 128400  35120 890244    0    0  4820   120  980 1450  5  2  9 84  0

Burada b sütunu 6'dır, yani altı süreç disk bekliyor; wa %84'tür. Bu ikisi birlikte, load'ın disk kaynaklı olduğunu net biçimde söyler. Tersine r (çalışmayı bekleyen süreç) sütunu yüksek ve wa düşükse, sorun CPU sırasındaki kuyruktur.

Yüksek Load'ın Kaynağını Adım Adım Bulmak#

Teoriyi bir teşhis akışında birleştirelim. Sunucu yavaşladığında ve load yüksek çıktığında şu sırayı izlerseniz birkaç dakikada suçluya inersiniz.

1. Yükü normalize edin. Önce panik yapmayın; load'u çekirdek sayısına bölün. nproc çıktısıyla kıyaslayıp gerçekten yüksek olup olmadığına karar verin. 8 çekirdekli bir sunucuda 5.0 sorun değildir.

2. Yük tipini belirleyin. top açıp CPU satırına bakın. us/sy mi yüksek, yoksa wa mı? Bu, sizi ya CPU ya da disk yoluna sokar.

3. CPU darboğazıysa en obur süreci bulun. ps çıktısını CPU'ya göre sıralamak en hızlısıdır:

# CPU'yu en çok tüketen 6 süreç ve PID'leri
ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head -n 7

Çıktının ilk sütunu aradığınız PID'dir. Belirli bir uygulamanın (örneğin PHP-FPM ya da MySQL) mi yoksa beklenmedik bir betiğin mi (örneğin kaynak çalan zararlı bir işlem) yükü ürettiğini burada görürsünüz. Süreç izlemenin bütün araçlarını süreçleri izleme (ps, top, htop) yazımızda ayrıntılı ele aldık.

4. Disk darboğazıysa diski meşgul eden süreci bulun. iotop bunun için idealdir (kurulu değilse apt install iotop ya da dnf install iotop):

# Diski en çok kullanan süreçleri canlı göster (yalnızca aktif olanlar)
sudo iotop -oPa

Ayrıca ps çıktısında bol miktarda D durumundaki süreç görmek de disk beklemesinin güçlü bir işaretidir:

# D (uninterruptible sleep) durumundaki süreçleri listele
ps -eo pid,stat,comm | awk '$2 ~ /D/'

5. Deseni bir dakika gözleyin. Suçlu PID'yi bulunca hemen öldürmek yerine pidstat ile süreci bir süre izleyin. Kısa süreli bir yedekleme ya da güncelleme işi CPU'yu geçici yükseltebilir; asıl sorun, dakikalarca yüksek kalan ve iş yükünüzle açıklanamayan süreçtir.

# 1187 numaralı sürecin CPU ve IO kullanımını 2 saniyede bir izle
pidstat -p 1187 -u -d 2

Servisleri kill -9 ile öldürmek yerine — özellikle MySQL, Nginx gibi kalıcı servisleri — her zaman servis yöneticisi üzerinden yeniden başlatın (systemctl restart mysql); aksi halde servis yarım bir durumda takılabilir. Bu konuyu systemd servis yönetimi yazımızda derinlemesine anlattık.

Load Average Yorumlarken Sık Yapılan Hatalar#

Yıllar içinde en çok tekrarlanan hataları görmek, doğru yorumu pekiştirir. Bunları bilerek çoğu yanlış teşhisin önüne geçersiniz.

Load'u yüzde sanmak. Load 1.0, "CPU %100 dolu" demek değildir; "ortalama bir süreç sürekli koşuyor ya da bekliyor" demektir. 8 çekirdekli bir sistemde 1.0 load, CPU'nun yaklaşık sekizde birinin kullanıldığını gösterir. Load bir sayaçtır, yüzde değil.

Çekirdek sayısını hesaba katmamak. En yaygın hata budur. "Load 6, felaket!" tepkisi 2 çekirdekli bir sunucuda doğru, 16 çekirdekli bir sunucuda tamamen yanlıştır. Normalize etmeden yorum yapmayın.

1 dakikalık değere takılıp kalmak. Anlık bir sıçrama (cron ile başlayan bir yedek, bir dağıtım anı) 1 dakikalık değeri fırlatabilir. Kalıcı bir sorun olup olmadığını anlamak için 5 ve 15 dakikalık değerlere ve eğilime bakın.

Yüksek load'ı hep CPU sanmak. Linux'ta D durumundaki disk-bekleyen süreçler de load'a girdiği için, yavaş bir disk load'ı CPU tamamen boşken bile tavana çakabilir. wa değerini kontrol etmeden "CPU yetmiyor" demeyin.

buff/cache'i dolu bellek sanmak. Linux boş RAM'i disk önbelleği olarak kullanır ve gerektiğinde anında boşaltır. Gerçek boş bellek için free -h çıktısındaki available sütununa bakın. Bellek gerçekten bittiğinde swap devreye girer, disk I/O artar ve wa üzerinden load'a yansır — döngü buradan kapanır.

Son bir pratik nokta: load average kısa ömürlü darboğazları 15 dakikaya kadar taşıdığı için, tek bir ekran görüntüsü yerine bir süre watch -n 5 uptime ile izlemek daha sağlıklı bir tablo verir.

# Load'u 5 saniyede bir tazeleyerek izle
watch -n 5 uptime

Sürekli Yüksek Load İçin Kalıcı Çözümler#

İzleme araçları "şu an ne oluyor" sorusunu yanıtlar; ama bazen yanıt basittir: sunucunuz mevcut iş yükü için gerçekten yetersizdir. Normalize edilmiş load sürekli 1.0'ın üzerinde geziyor, tek bir "suçlu" süreç yok ve tüm süreçler topluca kaynak için yarışıyorsa, sorun bir eklenti değil kapasitedir.

Böyle durumlarda önce yazılım tarafını sıkıştırın: gereksiz servisleri kapatın, PHP-FPM işçi sayısını RAM'inize göre ayarlayın, ağır veritabanı sorgularını indeksleyip optimize edin ve önbellek (cache) ekleyerek hem CPU hem disk yükünü düşürün. WordPress gibi uygulamalarda yüksek load'ın büyük bölümü kötü yazılmış eklentilerden ve önbelleksiz çalışmaktan doğar; düzenli bakım bu yükü ciddi biçimde azaltır. Bu bakımı kendiniz üstlenmek istemezseniz WordPress bakım hizmetimiz devreye girer. Disk kaynaklı (yüksek wa) darboğazlarda ise en etkili adım, yavaş diskten NVMe tabanlı hızlı depolamaya geçmektir.

Donanım tarafında en temiz çözüm daha güçlü bir plana yükselmektir. Paylaşımlı bir hosting paketinde komşu hesapların yükü sizi etkileyebilir; kaynaklarınızın size ayrıldığı bir sanal sunucuya ya da yüksek performanslı bir VDS sunucuya geçmek çoğu darboğazı kökten çözer. Doğru boyutu seçmek için mevcut kullanımınızı bir süre load average ve top ile gözlemlemek, tahmin yürütmekten her zaman daha isabetlidir. İşin yönetim yükünü hiç taşımak istemiyorsanız, load takibi dahil tüm sistem sağlığını sizin adınıza izlediğimiz sunucu yönetimi hizmetimizle sunucunuzu uzman ellere bırakabilirsiniz.

Sıkça Sorulan Sorular#

Load average yüzde midir?#

Hayır, load average bir yüzde değildir; ortalama süreç sayısıdır. 1.0 değeri, ortalama olarak bir sürecin sürekli çalıştığını ya da CPU sırasında beklediğini gösterir. Bu yüzden değeri asla "%100 CPU" gibi okumayın. Anlamlı bir yorum için load'u sunucunuzun çekirdek sayısına bölmeniz gerekir; örneğin 8 çekirdekli bir sistemde 2.0 load, kabaca kapasitenin dörtte birinin kullanıldığı rahat bir durumu anlatır.

Kaç değerin üzerindeki load tehlikelidir?#

Bunun evrensel bir sayısı yoktur çünkü çekirdek sayısına bağlıdır. Genel kural, load'u çekirdek sayısına bölüp çekirdek başına yükü bulmaktır. Çekirdek başına 1.0 tam kapasiteyi, 1.0'ın üzeri iş kuyruğunun birikmeye başladığını ve gecikme yaşandığını gösterir. Pratikte çoğu yönetici çekirdek başına 0.7 altını rahat, 1.0 civarını dikkat, 2.0 ve üstünü acil kabul eder. Yani 4 çekirdekli bir sunucuda 4.0 sınır, 8.0 ise ciddi bir sorundur.

Load yüksek ama CPU kullanımı düşük, bu nasıl olur?#

Bu son derece tipik bir durumdur ve genellikle disk darboğazına işaret eder. Linux, load hesabına yalnızca CPU bekleyen süreçleri değil, disk ya da ağ yanıtı bekleyen (kesintisiz uykudaki, D durumu) süreçleri de katar. Dolayısıyla yavaş bir disk, CPU tamamen boşken bile load'u tavana çıkarabilir. Bunu doğrulamak için top çıktısındaki wa (I/O wait) değerine bakın; yüksekse sorun CPU değil disktir ve iotop ile diski meşgul eden süreci bulmanız gerekir.

1, 5 ve 15 dakikalık değerlerden hangisine bakmalıyım?#

Üçüne birden bakmalısınız çünkü asıl bilgi aralarındaki ilişkidedir. 1 dakikalık değer anlık durumu, 15 dakikalık değer genel eğilimi gösterir. Eğer 1 dakikalık değer 15 dakikalıktan büyükse yük artıyor, tersi ise geçiyor demektir. Anlık bir sıçramayı kalıcı bir sorundan ayırmak için tek bir değere değil, üç değerin yönüne bakın; kısa ömürlü bir cron işi 1 dakikalık değeri fırlatıp geçebilir ama 15 dakikalık değeri pek oynatmaz.

Load average'ı hangi komutla görebilirim?#

En hızlısı uptime komutudur; satırın sonunda üç load değerini verir. Aynı bilgiyi top ve htop araçları da üst satırlarında gösterir, ayrıca w komutu da içerir. Ham veriyi doğrudan çekirdekten okumak isterseniz cat /proc/loadavg çalıştırabilirsiniz; bu çıktı üç load değerine ek olarak o an çalışan/toplam süreç sayısını ve son PID'yi de verir. Sürekli izlemek için watch -n 5 uptime kullanmak, tek bir anlık görüntüden çok daha sağlıklı bir tablo sunar.

Hyper-Threading çekirdekleri load hesabında sayılır mı?#

Evet, normalize ederken pratikte mantıksal çekirdek sayısını kullanırız ve nproc bu sayıyı Hyper-Threading dahil verir. Ancak gerçek paralel iş gücü fiziksel çekirdek başına birebir iki kat değildir; iki thread aynı fiziksel çekirdeğin kaynaklarını paylaşır. Bu nedenle Hyper-Threading'li bir sunucuda eşiklerinizi biraz temkinli tutmak, örneğin çekirdek başına 1.0 yerine 0.8 civarını üst sınır kabul etmek daha güvenlidir.

Kapanış#

Load average, sunucu yöneticiliğinin en pratik göstergelerinden biridir; ama gücü, doğru okunmasına bağlıdır. Bu sayıyı bir yüzde değil bir süreç sayısı olarak görmeyi, mutlaka çekirdek sayısıyla normalize etmeyi, 1-5-15 dakikalık değerlerin yönünü izlemeyi ve en önemlisi yükün CPU'dan mı yoksa disk beklemesinden (wa) mi geldiğini ayırt etmeyi alışkanlık haline getirdiğinizde, "sunucu yavaş" gibi belirsiz bir şikâyeti dakikalar içinde somut bir teşhise indirgersiniz.

Bu teşhis sonunda sorun izlemede değil kapasitede çıkarsa, doğru adım daha güçlü bir altyapıya geçmektir. İhtiyacınıza uygun bir hosting paketi, kaynaklarınızın size ayrıldığı bir sanal sunucu ya da yüksek performanslı bir VDS için Clou.TR ürün sayfalarına göz atabilirsiniz. Kurulumdan güncellemeye, load takibinden performans optimizasyonuna kadar tüm sistem sağlığını bize bırakmak isterseniz sunucu yönetimi hizmetimizle sunucunuzu uzman ellere teslim edebilirsiniz.