Load Average Nedir? Sunucu Yükü Nasıl Yorumlanır?

Load average nedir, sunucu yükünü nasıl gösterir?

Load average, Linux'ta CPU üzerinde çalışan ya da çalışmak için sırada bekleyen süreçler ile disk gibi bir giriş çıkış işlemini kesintisiz uykuda bekleyen süreçlerin 1, 5 ve 15 dakikalık ortalamasıdır. Değer çekirdek sayısına göre normalleştirilmez; bu nedenle onu her zaman çekirdek sayısıyla birlikte okursunuz.

Türkçede bu kavrama genellikle "sunucu yükü" deriz. Ancak sunucu yükü kulağa tek bir yüzde gibi gelir, oysa load average bir yüzde değil, bir kuyruk ölçüsüdür. Yani "sunucu yüzde kaç dolu" sorusuna değil, "kaç iş aynı anda kaynak bekliyor" sorusuna cevap verir.

uptime kılavuz sayfası bunu açıkça yazar: load average, çalıştırılabilir ya da kesintisiz durumdaki süreçlerin ortalama sayısıdır. Çalıştırılabilir süreç CPU'yu kullanan ya da CPU sırası bekleyen süreçtir. Kesintisiz durumdaki süreç ise örneğin diskten gelecek veriyi bekler.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yazıda Linux kılavuz sayfalarına, çekirdek belgelerine ve cPanel dokümantasyonuna dayanarak load average değerini nasıl okuyacağınızı, yüksek yükün nedenini nasıl ayıracağınızı ve hangi noktada işi hosting sağlayıcınıza bırakmanız gerektiğini anlatıyoruz.

Load average ile CPU kullanım yüzdesi aynı şey mi?

Hayır, ikisi farklı şeyleri ölçer. CPU kullanım yüzdesi, işlemcinin belirli bir zaman diliminde ne kadarını meşgul geçirdiğini söyler. Load average ise işlemciyi kullanan ve sıra bekleyen işlerin sayısını verir. Dolayısıyla CPU yüzde 100 dolu olsa da kuyruğun uzunluğunu ancak load average gösterir.

Bir örnekle düşünelim. Tek çekirdekli bir sunucuda CPU sürekli yüzde 100 çalışıyor olabilir. Kuyrukta yalnız bir iş varsa load average 1 civarında kalır. Kuyrukta beş iş varsa CPU yine yüzde 100 görünür, ama load average 5'e yaklaşır. İkinci durumda her istek daha uzun süre sıra bekler.

Linux'ta önemli bir fark daha vardır. Load average yalnız CPU'yu değil, disk bekleyen süreçleri de sayar. Bu yüzden CPU kullanımı düşükken bile load average yüksek çıkabilir. Böyle bir tabloda sorun çoğu zaman işlemcide değil, depolama tarafındadır.

• CPU yüzdesi: İşlemcinin ne kadar meşgul olduğunu gösterir.
• Load average: Kaynak bekleyen iş kuyruğunun ortalama uzunluğunu gösterir.
• %wa (iowait): CPU'nun boşta olduğu, ama bekleyen bir disk isteğinin bulunduğu zamanın oranını gösterir.

Kısacası teşhis için bu üç değeri birlikte okumanız gerekir; tek başına hiçbiri tam resmi vermez.

Load average değerlerini hangi komutlarla görürsünüz?

Bu değerleri görmek için ek paket kurmanıza gerek yoktur. Linux dağıtımlarının çoğunda gelen temel araçlar bu bilgiyi doğrudan verir. En hızlı yol uptime komutudur.

uptimewcat /proc/loadavgtop

Örnek çıktı (değerler temsilidir): 10:15:02 up 12 days, 3:04, 2 users, load average: 0.52, 0.61, 0.70. Sondaki üç sayı sırasıyla son 1, 5 ve 15 dakikanın ortalamasıdır. w komutu aynı satırı oturum açmış kullanıcı listesiyle birlikte gösterir. top ise ilk satırında aynı üç değeri canlı olarak günceller.

/proc/loadavg kılavuz sayfası, bu dosyanın ilk üç alanının, çalışma kuyruğundaki (R durumu) ya da disk girdi çıktısı bekleyen (D durumu) işlerin 1, 5 ve 15 dakikalık ortalaması olduğunu belirtir. Dördüncü alan "çalıştırılabilir/toplam" biçiminde iki sayı içerir. Beşinci alan ise sistemde en son oluşturulan sürecin kimliğini (PID) verir.

Üstelik bu dosya, izleme betikleri için en temiz kaynaktır. Bir betik yazıyorsanız uptime çıktısını ayrıştırmak yerine doğrudan /proc/loadavg dosyasını okumanız daha sağlamdır, çünkü biçimi dile ve yerel ayara göre değişmez.

1, 5 ve 15 dakikalık üç değer size ne anlatır?

Üç değer aynı ölçünün farklı zaman pencerelerindeki ortalamasıdır. Asıl bilgi, sayıların kendisinden çok birbirleriyle ilişkisinde gizlidir. Bu ortalamalar basit aritmetik ortalama değildir; eski ölçümlerin etkisi zamanla azalır. Bu nedenle 1 dakikalık değer hızlı tepki verir, 15 dakikalık değer ise yavaş değişir.

• 1 dakika büyük, 15 dakika küçük: Yük yeni başlamıştır. Ani bir trafik dalgası, bir cron işi ya da bir yedekleme olabilir.
• 1 dakika küçük, 15 dakika büyük: Yük azalıyordur. Sorun büyük olasılıkla geride kalmıştır, ama nedenini yine de kayıtlardan bulmalısınız.
• Üçü de yüksek ve birbirine yakın: Yük kalıcıdır. Sunucu uzun süredir kapasitesinin üzerinde çalışıyordur.
• Üçü de düşük: Kuyruk kısadır; yavaşlık varsa nedeni büyük olasılıkla başka bir katmandadır.

Örneğin bir sabah 1 dakikalık değeri yüksek görüp paniğe kapılabilirsiniz. Ancak 5 ve 15 dakikalık değerler düşükse, kısa süreli bir dalga yaşanmış olabilir. Öte yandan 15 dakikalık değer günlerce yüksek kalıyorsa, bu artık geçici bir dalga değil, kapasite ya da yazılım sorunudur.

Böylece üç değeri bir eğilim okuması gibi kullanırsınız: yük artıyor mu, azalıyor mu, yoksa kalıcı mı?

Çekirdek sayısını neden bilmeniz gerekir?

Load average değeri, sunucudaki CPU sayısına göre normalleştirilmez. uptime kılavuz sayfası bunu bir örnekle anlatır: load average 1, tek CPU'lu bir sistemde sürekli dolu çalışma anlamına gelir; 4 CPU'lu bir sistemde ise zamanın yüzde 75'inde boşta kalındığını gösterir.

Yani aynı sayı, farklı sunucularda tamamen farklı bir durumu anlatır. Bu yüzden ilk iş, sunucunuzun kaç mantıksal işlemciye sahip olduğunu öğrenmektir.

nproclscpu

nproc, geçerli sürecin kullanabileceği işlem birimi sayısını tek bir sayı olarak verir. lscpu ise çekirdek, iş parçacığı ve soket bilgisini daha ayrıntılı listeler. Hiper iş parçacığı (hyper-threading) açık sunucularda mantıksal işlemci sayısı fiziksel çekirdek sayısından büyük görünebilir.

Sanal sunucularda (VPS) bir ayrıntıya daha dikkat edin. Size atanan sanal CPU sayısı, fiziksel makinedeki gerçek çekirdeklerle bire bir eşleşmeyebilir. Üstelik aynı fiziksel makinedeki diğer müşteriler de işlemci zamanını paylaşır. Bu yüzden VPS üzerinde aynı load average değeri, fiziksel bir sunucudakinden farklı bir baskıyı yansıtabilir.

Load average kaç olmalı, çekirdek başına 1.0 kuralı doğru mu?

Yaygın kural şudur: load average değeri çekirdek sayısına yaklaştığında CPU kuyruğu dolmaya başlamıştır. Çekirdek başına 1.0 civarı, kaba bir doygunluk eşiği olarak kabul görür. Ancak bu kesin bir sınır değil, başlangıç noktası niteliğinde bir genel kuraldır.

Kuralın mantığı kılavuz sayfasındaki örnekten gelir. 4 çekirdekli bir sunucuda load average 4 ise, ortalamada her çekirdeğin tam bir işi vardır ve beklemede iş yoktur. Load average 6 ise, ortalamada iki iş sırada bekliyordur. Dolayısıyla değer çekirdek sayısını aştıkça istekler gecikmeye başlar.

Yine de kuralı körü körüne uygulamayın, çünkü Linux'taki yük ortalaması disk bekleyen süreçleri de sayar. Disk tarafında takılan on süreç, CPU neredeyse boştayken bile değeri yükseltir. Bu durumda "çekirdek sayısını artıralım" kararı sorunu çözmez.

Bu nedenle biz şu yaklaşımı öneriyoruz:

1. Önce sunucunuzun normal günlerdeki load average aralığını not edin.
2. Değeri çekirdek sayısıyla karşılaştırın, ama tek ölçüt yapmayın.
3. Değer yükseldiğinde CPU mu, disk mi, bellek mi olduğunu ayrı araçlarla doğrulayın.
4. Kararı, kullanıcıların gerçekten yavaşlık yaşayıp yaşamadığına göre verin.

Kısacası kendi sunucunuzun normalini bilmek, internetteki herhangi bir sabit eşikten daha değerlidir.

Örnek hesap: 4 çekirdekli sunucuda load average nasıl yorumlanır?

Aşağıdaki tablo, 4 mantıksal işlemcili bir sunucu için örnek hesap niteliğindedir. Değerler gerçek bir ölçüm değil, yorumlama mantığını göstermek için seçilmiş temsili sayılardır. Sizin sunucunuzda normal aralık farklı olabilir.

Tablodaki son satır özellikle önemlidir. Load average yüksekken CPU boşta görünüyorsa, işlemciye para harcamak yerine depolama tarafını incelemeniz gerekir. Öte yandan üçüncü satırdaki gibi kısa dalgalar, çoğu zaman zamanlanmış bir işin ya da ani bir ziyaretçi artışının izidir.

Yüksek load average hangi nedenlerle oluşur?

Yüksek load average bir sonuçtur, neden değildir. Aynı sayı birbirinden çok farklı sorunlardan doğabilir. Web sitesi barındıran sunucularda en sık karşılaşılan başlıkları şöyle özetleyebiliriz:

• CPU yoğun işler: Önbelleksiz dinamik sayfalar, ağır PHP betikleri, görsel işleme, sıkıştırma ve arama dizinleme işleri.
• Disk girdi çıktısı beklemesi: Yavaş ya da dolu disk, büyük yedekleme işleri, yoğun günlük (log) yazımı, indekssiz veritabanı sorguları.
• Bellek yetersizliği ve swap: RAM bittiğinde çekirdek bellek sayfalarını diske taşır, bu da disk beklemesini artırır.
• PHP-FPM ve MySQL birikmesi: Çok sayıda eş zamanlı istek, uzun süren sorgular ve kilitlenen tablolar kuyruğu uzatır.
• Bot ve saldırı trafiği: Giriş sayfasına kaba kuvvet denemeleri ya da agresif tarayıcılar, gerçek ziyaretçi olmadan yük üretir.
• Sanallaştırma kaynaklı bekleme: VPS'te fiziksel makineyi paylaşan diğer sanal makineler işlemci zamanını alabilir.

Örneğin bir e-ticaret sitesinde kampanya saatinde yük artıyorsa neden büyük olasılıkla gerçek trafiktir. Ancak gece yarısı, ziyaretçinin en az olduğu saatte yük artıyorsa, zamanlanmış yedekleme ya da bot trafiği ihtimali öne çıkar. Bot kaynaklı yükü ayırt etmek için erişim günlüklerini log analizi aracı ile incelemek iyi bir başlangıçtır.

Sonraki bölümlerde bu nedenleri tek tek nasıl ayıracağınızı anlatıyoruz.

CPU kaynaklı yüksek yükü nasıl ayırt edersiniz?

İlk olarak top komutunu açın ve üst kısımdaki %Cpu(s) satırına bakın. Bu satırda us (kullanıcı alanı), sy (çekirdek), id (boşta), wa (girdi çıktı beklemesi) ve st (sanal makineden çalınan zaman) gibi alanlar bulunur.

CPU kaynaklı bir yükte us ya da sy yüksek, id düşük olur. Ayrıca top içinde 1 tuşuna basarak her işlemcinin kullanımını ayrı ayrı görebilirsiniz. Tek bir çekirdek sürekli doluyken diğerleri boşsa, tek iş parçacığıyla çalışan bir süreç darboğaz oluşturuyor olabilir.

ps -eo pid,user,%cpu,%mem,comm --sort=-%cpu | head -n 15

Bu komut, en çok CPU kullanan on beş süreci listeler. Listenin başında php-fpm, mysqld ya da bir yedekleme aracı görüyorsanız, aramanızı o yöne daraltırsınız.

VPS kullanıyorsanız st değerini de izleyin. iostat kılavuz sayfası steal değerini, sanal CPU'nun, hipervizör başka bir sanal işlemciye hizmet verirken istemeden beklediği zamanın oranı olarak tanımlar. Bu değer düzenli olarak yüksekse, sorun sizin yazılımınızda değil, fiziksel makinenin paylaşımındadır. Böyle bir durumda optimizasyon yerine hosting sağlayıcınızla konuşmanız gerekir.

Disk I/O beklemesi load average değerini nasıl şişirir?

Linux'ta disk bekleyen süreçler "kesintisiz uyku" durumuna, yani D durumuna geçer. Yük ortalaması bu süreçleri de sayar. Bu yüzden disk yavaşladığında CPU boştayken bile değer yükselir. Web sunucularında yanıltıcı tabloların en sık nedeni budur.

Teşhis için önce top çıktısındaki wa değerine bakın. Ardından D durumundaki süreçleri listeleyin ve disk başına ayrıntılı istatistik alın:

ps -eo stat,pid,user,comm | awk '$1 ~ /^D/'iostat -x 2 5

iostat, sysstat paketinin bir parçasıdır; kurulu değilse dağıtımınızın paket yöneticisiyle sysstat paketini kurarsınız. iostat kılavuz sayfasına göre %iowait, CPU'nun boşta olduğu ve bekleyen bir disk isteğinin bulunduğu zamanın oranıdır. await değerleri bir isteğin kuyrukta bekleme ve işlenme süresini milisaniye cinsinden verir. %util ise cihazın meşgul olduğu zamanın oranıdır.

Ancak %util değerini yorumlarken dikkatli olun. Kılavuz, bu değerin yüzde 100'e yaklaşmasının istekleri sırayla işleyen cihazlar için doygunluk anlamına geldiğini belirtir. Paralel çalışan SSD ve NVMe disklerde yüksek %util her zaman doygunluk demek değildir. Bu yüzden await değerindeki artışı daha güvenilir bir işaret olarak kullanırsınız.

Disk dar boğazında kalıcı çözüm çoğu zaman donanım ya da paket değişikliğidir.

Bellek yetersizliği ve swap yükü nasıl artırır?

RAM yetmediğinde çekirdek, az kullanılan bellek sayfalarını diskteki swap alanına taşır. Swap, sunucunun ani bellek ihtiyacında çökmesini önleyen bir emniyet payıdır. Ancak disk RAM'den çok daha yavaştır. Sayfalar sürekli diske yazılıp geri okunduğunda süreçler disk bekler ve sunucu yükü artar.

free -hswapon --showvmstat 2 5

free -h toplam, kullanılan ve kullanılabilir belleği okunabilir birimlerle gösterir. swapon --show etkin swap alanlarını listeler. vmstat kılavuz sayfasına göre si diskten belleğe, so ise bellekten diske saniyede taşınan bellek miktarıdır.

Burada önemli olan, swap alanının dolu olması değil, swap trafiğinin sürmesidir. Swap kullanımı yüksek ama si ve so sıfıra yakınsa, eski ve az kullanılan sayfalar diskte duruyordur; bu genellikle sorun değildir. Öte yandan si ve so sürekli sıfırın üzerindeyse sunucu bellek sıkıntısı yaşıyordur.

Bellek tamamen tükenirse çekirdeğin bellek yetersizliği mekanizması bir süreci sonlandırabilir. Bunun izini çekirdek günlüklerinde ararsınız: journalctl -k | grep -i "out of memory". Swap alanını doğru boyutta oluşturmayı Linux swap oluşturma ve SSH güvenliği rehberimizde adım adım anlattık.

PHP-FPM ve MySQL load average değerini nasıl tetikler?

Web sitelerinde yükün iki klasik kaynağı PHP-FPM ve MySQL'dir. PHP-FPM her dinamik isteği bir alt süreçte çalıştırır. Bu süreçlerin üst sınırını pm.max_children ayarı belirler. Sınır çok yüksekse, eş zamanlı süreçler belleği tüketip swap kullanımına yol açar. Sınır çok düşükse istekler kuyrukta bekler ve PHP-FPM günlüğünde server reached pm.max_children setting uyarısını görürsünüz.

MySQL tarafında ise yavaş, indekssiz sorgular hem CPU hem disk tüketir. Aynı anda çalışan sorguları görmek için MySQL içinde SHOW FULL PROCESSLIST; komutunu kullanırsınız. Kalıcı teşhis için slow_query_log ve long_query_time değişkenleriyle yavaş sorgu günlüğünü açarsınız. Bu ayarları güvenli biçimde yapmayı MySQL kurulumu ve performans optimizasyonu yazımızda anlattık.

Ayrıca önbellek eksikliği iki tarafı da yorar. PHP'nin her istekte betikleri yeniden derlememesi için OPcache ayarlarını kontrol edin. Sık tekrarlanan sorgular ve oturum verileri için de Redis ya da Memcached ile önbellekleme yükü belirgin biçimde azaltabilir.

Kısacası PHP-FPM ve MySQL sorunlarında çözüm genellikle daha güçlü sunucu değil, daha az tekrar eden iş ve daha iyi sorgudur.

vmstat çıktısıyla teşhisi nasıl yaparsınız?

vmstat, CPU, bellek, swap ve disk bilgisini tek satırda özetlediği için hızlı teşhis aracınızdır. vmstat 2 5 komutu, iki saniye arayla beş rapor üretir. Kılavuz, gecikme verilmezse yalnız açılıştan bu yana ortalamaları içeren tek bir rapor basıldığını belirtir. Bu yüzden ilk satırı değil, sonraki satırları okursunuz.

vmstat kılavuz sayfasındaki tanımlara göre okumanız gereken başlıca alanlar şunlardır:

• r: Çalıştırılabilir süreç sayısı, yani CPU'yu kullanan ya da sırasını bekleyen süreçler. Bu sayı çekirdek sayısını sürekli aşıyorsa CPU kuyruğu oluşmuştur.
• b: Girdi çıktının tamamlanmasını bekleyen engellenmiş süreç sayısı. Değer sürekli sıfırın üzerindeyse disk tarafına bakın.
• si / so: Swap giriş ve çıkış miktarı. Sürekli sıfırın üzerindeyse bellek sıkışıktır.
• wa: Girdi çıktı beklemesinde geçen zaman.
• st: Sanal makineden çalınan zaman.

Böylece yükün hangi bileşenden beslendiğini görürsünüz. Örneğin r yüksek ve b düşükse yük CPU kaynaklıdır. Tam tersine b ve wa yüksekse disk beklemesi öndedir; si ve so de yüksekse bu beklemenin kaynağı büyük olasılıkla bellek yetersizliğidir.

top ve htop ekranında nelere bakmalısınız?

top neredeyse her Linux sunucusunda hazır gelir. htop ise daha okunaklı, renkli bir arayüz sunar; çoğu dağıtımda ayrı paket olarak kurarsınız. İki araç da aynı temel bilgiyi gösterir, fark yalnız sunumdadır.

Ekranı açtığınızda şu sırayla bakmanızı öneriyoruz:

1. Yük satırı: Üç değer ve eğilim. Çekirdek sayısıyla karşılaştırın.
2. CPU satırı: us, sy, wa ve st oranları. Yükün türünü burada ilk kez ayırırsınız.
3. Bellek ve swap satırları: Kullanılabilir bellek ve swap kullanımı.
4. Süreç listesi: En çok CPU ya da bellek kullanan süreçler. top içinde P tuşu CPU'ya, M tuşu belleğe göre sıralar.
5. Süreç durumu sütunu: S sütununda D görüyorsanız o süreç disk bekliyordur.

Bununla birlikte bu araçlar anlık görüntü verir. Sorun sabah üçte yaşanıyorsa ve siz sabah dokuzda bakıyorsanız, ekranda hiçbir şey göremezsiniz. Bu yüzden düzenli kayıt tutan bir izleme sistemine ihtiyaç duyarsınız. sysstat paketinin veri toplama özelliği ya da hosting sağlayıcınızın izleme paneli bu boşluğu kapatır.

PSI nedir, load average değerine ne ekler?

PSI (Pressure Stall Information), Linux çekirdeğinin kaynak baskısını ayrı ayrı ölçen bir mekanizmasıdır. Yük ortalaması tek bir sayıda CPU ve disk beklemesini birleştirirken, PSI CPU, bellek ve girdi çıktı için ayrı dosyalar sunar. Bu dosyalar /proc/pressure/ dizinindedir.

cat /proc/pressure/cpucat /proc/pressure/memorycat /proc/pressure/io

Linux çekirdeği PSI belgesine göre her dosya some ve full adlı iki satır içerir. some satırı, en az bir görevin o kaynakta beklediği zamanın payını gösterir. full satırı ise boşta olmayan tüm görevlerin aynı anda beklediği zamanın payıdır. avg10, avg60 ve avg300 alanları 10, 60 ve 300 saniyelik pencereleri temsil eder.

Pratik faydası şudur: yük yüksek olduğunda PSI size "hangi kaynak darda" sorusunun cevabını doğrudan verir. Örneğin io dosyasındaki değerler yüksek, cpu dosyasındakiler düşükse, sorun işlemcide değil depolamadadır.

Ancak bu dosyalar her ortamda bulunmayabilir; çekirdek sürümü ve yapılandırması belirleyicidir. Dosyalar yoksa vmstat ve iostat ile aynı ayrımı yaparsınız.

cPanel ve WHM'de sunucu yükünü nerede görürsünüz?

Kendi sunucunuzda WHM erişiminiz varsa, sunucu yükünü komut satırı olmadan da görebilirsiniz. cPanel dokümantasyonundaki Service Status sayfası, Sistem Bilgisi bölümünün sunucu yükünü, kullanılan belleği, kullanılan swap alanını ve bu öğelerin durumunu listelediğini belirtir.

Aynı belge durum simgelerini de açıklar. Onay işareti kaynağın yüzde 80'inden azını, uyarı üçgeni yüzde 80 ile 89 arasını, çarpı simgesi ise yüzde 90 ve üzerini kullandığınızı gösterir. Bu eşikler cPanel'in kendi gösterge eşikleridir; Linux'un genel bir kuralı değildir.

Paylaşımlı hostingte durum farklıdır. cPanel kullanıcısı olarak sunucunun toplam yük değeri sizin sitenizin durumunu doğru yansıtmaz, çünkü aynı makinede başka hesaplar da çalışır. Bazı sağlayıcılar hesap başına kaynak sınırı uygular ve cPanel içinde hesabınıza ait kaynak kullanımı ekranı sunar. Hesap izolasyonunun nasıl çalıştığını CageFS ve paylaşımlı hostingte hesap izolasyonu yazımızda anlattık.

Dolayısıyla paylaşımlı hostingte sunucu yükünü kendiniz düzeltmeye çalışmak yerine, kendi hesabınızın sınırlarına takılıp takılmadığınızı kontrol edersiniz.

Yüksek load average ne zaman gerçekten sorundur?

Yüksek load average her zaman acil durum değildir. Gece çalışan bir yedekleme işi birkaç dakika boyunca değeri yükseltebilir; kullanıcı fark etmiyorsa bu normal bir iş yüküdür. Sorunu ayırt etmek için şu işaretlere bakarsınız:

• 15 dakikalık değer, saatler ya da günler boyunca çekirdek sayısının belirgin biçimde üzerinde kalıyor.
• Sayfa yanıt süreleri artıyor, yönetim paneli yavaşlıyor ya da zaman aşımı hataları görülüyor.
• Ziyaretçiler zaman zaman 502 ya da 503 hatasıyla karşılaşıyor.
• Swap giriş çıkışı sürekli yüksek ya da çekirdek günlüklerinde bellek yetersizliği kayıtları var.
• Yük, trafik artışıyla açıklanamayan saatlerde artıyor.

Örneğin aşırı yükte PHP-FPM süreç sınırına ulaşır ve web sunucusu yeni istekleri geri çevirmeye başlar. Ziyaretçi bunu bir hata sayfası olarak görür. Bu hatanın teşhisini 503 Service Unavailable hatası yazımızda ayrıca ele aldık.

Kısacası ölçüt "sayı yüksek mi" değil, "kullanıcı deneyimi ve hizmet sürekliliği etkileniyor mu" olmalıdır.

Load average ile web sitesi yavaşlığı arasında nasıl bir ilişki var?

Sunucu yükü yüksek olduğunda her istek işlemci ya da disk için sıra bekler. Bu bekleme, sunucunun ilk bayta yanıt süresini uzatır. Sonuçta ziyaretçi sayfanın açılmasını daha uzun süre bekler. Yani yüksek yük, yavaşlığın doğrudan nedenlerinden biridir.

Ancak ilişki tek yönlü değildir. Site yavaşsa ama yük düşükse, sorun büyük olasılıkla başka bir yerdedir. Örneğin büyük görseller, ağır JavaScript dosyaları, uzak sunucudan çağrılan bir API ya da DNS gecikmesi bu değere yansımaz. Sunucu kaynaklı yavaşlık nedenlerinin tam listesini web sitesi neden yavaş açılır yazımızda topladık.

Ayrıca yavaşlık yalnız kullanıcıyı değil, arama görünürlüğünü de etkiler. Yavaş yanıt veren bir sunucu, hem ziyaretçiyi hem de sitenizi tarayan arama motoru botlarını bekletir.

Bu nedenle iki ölçümü birlikte okuyun: sunucu tarafında load average, kullanıcı tarafında gerçek sayfa yükleme süresi. Biri yüksek, diğeri normalse, sorunun hangi katmanda olduğunu hızla ayırırsınız.

Yüksek yükte hangi sırayla çözüm aramalısınız?

Panik anında sunucuyu yeniden başlatmak cazip gelir. Ancak yeniden başlatma, nedeni ortadan kaldırmaz; üstelik teşhis için gereken anlık bilgiyi de siler. Bunun yerine şu sırayı izlemenizi öneriyoruz:

1. Durumu kaydedin: uptime, top, vmstat 2 5 ve free -h çıktısını bir dosyaya alın.
2. Türünü belirleyin: CPU mu, disk mi, bellek mi? us, wa, si/so ve b değerleri yolu gösterir.
3. Süreci bulun: Yükü üreten süreci ve onun sahibini (site, kullanıcı, cron işi) tespit edin.
4. Trafiği doğrulayın: Erişim günlüklerinde ani artış, bot ya da kaba kuvvet denemesi var mı?
5. Kısa vadeli rahatlatma yapın: Gereksiz cron işini erteleyin, kötü niyetli trafiği engelleyin, takılan sorguyu inceleyin.
6. Kalıcı çözüme geçin: Önbellek, sorgu optimizasyonu, PHP-FPM ayarı ya da kaynak artırımı.

Örneğin giriş sayfasına yönelik kaba kuvvet denemeleri yük üretiyorsa, bunu sunucu düzeyinde engellemek için Fail2ban kurulumu iyi bir adımdır. Kaynak artırımını ise en sona bırakın; yazılım sorununu daha büyük sunucuyla örtmek, maliyeti artırır ve sorunu bir süre sonra geri getirir.

Ne zaman işi hosting sağlayıcınıza bırakmalısınız?

Dürüst olmak gerekirse, her yüksek yük sorununu kendiniz çözmek zorunda değilsiniz. Bazı durumlarda doğru adım, hosting sağlayıcınızın destek ekibine yazmaktır:

• Paylaşımlı hosting kullanıyorsanız ve sunucu genelinde yük yüksekse; bu sizin kontrolünüzde değildir.
• VPS'te st değeri sürekli yüksekse; fiziksel makinenin paylaşımı sağlayıcının sorumluluğundadır.
• Disk gecikmesi donanım kaynaklı görünüyorsa ya da çekirdek günlüklerinde disk hatası kayıtları varsa.
• Yönetilen (managed) bir hizmet satın aldıysanız; sunucu ayarlarını değiştirmek o hizmetin kapsamındadır.
• Kök (root) erişiminiz yoksa ya da komut satırında ayar değiştirmek konusunda kendinizi rahat hissetmiyorsanız.

Destek talebine kanıt ekleyin. Sorunun başladığı saat, uptime ve vmstat çıktısı, etkilenen site adresi ve son yaptığınız değişiklikler, destek ekibinin işini ciddi biçimde hızlandırır. Böylece talebiniz "site yavaş" şikayetinden ölçülebilir bir teknik bildirime dönüşür.

Sürekli kapasite sorunu yaşıyorsanız, paketinizin ihtiyacınıza uyup uymadığını da değerlendirin. Bu kararın kriterlerini web sitesi için hosting nasıl seçilir rehberimizde sıraladık.

Load average değerini düzenli izlemeyi nasıl alışkanlık haline getirirsiniz?

En iyi teşhis, sorun çıkmadan önce sunucunuzun normalini bilmektir. Bu yüzden yük değerlerini yalnız kriz anında değil, sakin dönemlerde de izleyin. Normal bir haftanın değerlerini bildiğinizde, anormal bir sabahı hemen fark edersiniz.

Pratik bir düzen şöyle olabilir: haftada bir kez uptime ve vmstat çıktısını not edin, kampanya ya da yoğun trafik dönemlerinden önce ve sonra kontrol edin, büyük bir eklenti ya da tema güncellemesinden sonra değerlerin değişip değişmediğine bakın. Ayrıca izleme panelinizde yük için çekirdek sayısını temel alan bir uyarı eşiği tanımlayın.

Yük sorunlarının önemli bir kısmı, sitenin kendisinden kaynaklanır: önbelleksiz sayfalar, gereksiz eklentiler, optimize edilmemiş sorgular. Ekibimiz web tasarım ve geliştirme projelerinde bu konuları baştan planlar; böylece site, aynı sunucuda daha az kaynakla daha çok ziyaretçiye hizmet verir.

Özetle load average, sunucunuzun nabzıdır. Tek başına teşhis koymaz, ama doğru soruyu sormanızı sağlar: kuyruk neden uzadı ve hangi kaynak darda?