load average nedir ve sunucuda hangi değer tehlikelidir?

Gece saat iki, site yavaşladı, SSH'a giriyorsunuz ve uptime yazıyorsunuz: load average: 14.62, 9.10, 4.33. Gerçek soru şu: 14 felaket mi yoksa hiçbir şey mi demek. Kısa cevap: o makinenin çekirdek sayısına bağlı, ve o 14'ün CPU'dan mı yoksa diskten mi geldiğine.

uptime çıktısı üç sayı verir: son 1, 5 ve 15 dakikadaki ortalama yük. Bu sayılar Linux çekirdeğinden gelir ve çalıştırma kuyruğunu (run queue) sayar; yani ya CPU'da çalışan ya da CPU sırası bekleyen süreçler, ve D durumunda (kesilemez uyku) disk veya ağ I/O'su bekleyen süreçler. İşte bu son cümle her şeyi özetliyor: load average sadece CPU değildir.

load average'ı sabit bir sayıyla değil, çekirdek sayısıyla ölçün

Pratik kural şudur: yükü mantıksal çekirdek sayısına bölün. Çekirdek başına 0.7'nin altı rahat olduğunuz anlamına gelir. Yaklaşık 1 tam doygunluk ama kuyruk yok demektir. Çekirdek başına 1.5'in üzeri kuyruğun oluştuğu ve kullanıcının beklediği anlamına gelir.

Çekirdek sayısını nproc veya lscpu | grep '^CPU(s):' ile alın. Dört çekirdekli bir VPS'te yük 4 tam demektir; 32 çekirdekli bir sunucuda yük 4 boş demektir. Yük sayısının tek başına hiçbir anlamı yoktur.

Çoğu kişinin gözden kaçırdığı önemli bir nokta: eğilim. Eğer 1 dakikalık yük 15 dakikadan yüksekse, sorun şu anda büyüyor demektir. Tersi ise, bir dalgayı geçmişsiniz demektir. uptime'ın bir değil üç sayı vermesinin nedeni de budur.

CPU yükü ile I/O yükü arasındaki farkı nasıl ayırt ederiz

İşte teşhislerin çoğunun yanlış gittiği yer burasıdır. CPU'su yüzde 15 kullanan bir sunucuda yük 12 ise, sorun CPU değil demektir; yani disk.

top ile girin ve her çekirdeğin ayrı gösterilmesi için 1 tuşuna basın, sonra %wa (iowait) sütununa bakın. Bu sayı 20'nin üzerinde kalıyorsa, darboğaz disktir. iostat -x 2 ile (sysstat paketinden) %util sütununa bakın; 100'e yakın olması diskin doygun olduğu anlamına gelir.

iostat -x 2 5
# %util ve await değerlerine bakın
# SSD'de 50ms üzeri await ciddi sorun demektir

Hangi sürecin D durumunda takıldığını görmek için ps kullanın:

ps -eo state,pid,comm | awk '$1=="D"'

Çıktı mysqld veya php-fpm ile doluysa, büyük olasılıkla ağır bir sorgu veya swap'a neden olan RAM yetersizliği vardır. vmstat 1 ile si ve so sütunlarına bakın; oradaki sıfır olmayan her sayı sistemin swap yaptığı anlamına gelir ve bu en kötü yük türüdür, çünkü diski de doyurur.

İşte burada hata yapıyorlar: yüksek yükü CPU ekleyerek çözüyorlar. Eğer kök neden I/O ise, daha fazla çekirdek sadece kuyruğu uzatır ve durum daha da kötüleşir. İşareti de şudur: plan yükseltmesinden sonra yük iki gün boyunca iyi gider ve sonra tam olarak önceki sayıya geri döner.

load average ne zaman gerçekten endişe vericidir

Üç koşulu ayrı ayrı değil, birlikte görün:

1. 1 dakikalık yük çekirdek sayısının 1.5 katının üzerinde olsun ve yükselişte olsun.
2. Site yanıt süresi (TTFB) aynı anda artmış olsun. Kullanıcı yavaşlığı olmadan yüksek yük, genellikle bir batch işinin çalıştığı anlamına gelir ve sorun yoktur.
3. 15 dakikalık yük de yüksek kalmış olsun. Gece yedeklemesindeki kısa bir spike normaldir.

Eğer üçü de geçerliyse, gerçek bir sorun var demektir. Eğer sadece birincisi geçerliyse, muhtemelen önemsiz bir sayıya tepki veriyorsunuz.

WordPress'te yaygın bir tuzak: her kullanıcı ziyaretinde çalışan wp-cron.php. Trafik yükseldiğinde, onlarca eşzamanlı örneği çalışır ve yükü yükseltir. Çözüm, dahili cron'u devre dışı bırakıp gerçek sistem cron'u ile değiştirmektir; ayrıntıları WordPress wp-cron; neden çalışmıyor ve gerçek cron ile nasıl değiştirilir yazısında bulunmaktadır. Eğer paylaşımlı hosting'deyseniz ve sistem cron'una erişiminiz yoksa, Linux hosting tam erişimle bunu mümkün kılar.

Gerçekten işe yarayan araçlar

Hızlı bakış için htop, geçmişe dönük inceleme için atop (çünkü yük ve disk geçmişini saklar), ve son 24 saatteki yük eğilimini görmek için sar -q. Eğer sunucuyu şimdi kurduysanız ve baseline almak istiyorsanız, sar'ı ilk günden etkinleştirin; sonradan tarihsel veri olmadan bu sunucu için yük 8'in normal olup olmadığını söyleyemezsiniz.

Dışarıdan hızlı kontrol için, ücretsiz araçlar ServerNet hız testi ve sunucu yanıtı kontrolü sunar. HTTP hatası görüyorsanız ve nereden geldiğini bilmiyorsanız, HTTP durum kodu: yaygın hatalar için pratik rehber iyi bir başlangıç noktasıdır.

Ve eğer sorun her seferinde tüm veritabanını okuyan bir WordPress eklentisindense, başka herhangi bir şey yapmadan önce WordPress eklenti denetimi yapın. Deneyimlerime göre, WordPress sunucularındaki 10'un üzerindeki yüklerin yarısından fazlası kaynak yetersizliğinden değil, iki veya üç kötü yazılmış eklentiden gelir.

Sık sorulan sorular

load average kaç iyidir?

Mutlak bir sayı yoktur. Yükü çekirdek sayısına bölün; çekirdek başına 0.7'nin altı iyidir ve çekirdek başına 1.5'in üzeri kuyruk ve gecikme anlamına gelir. 8 çekirdekli bir sunucuda yük 5 endişe verici değildir ama yük 14 öyledir.

Neden load average yüksek ama CPU kullanımı düşük?

Çünkü süreçler kesilemez uyku (D) durumunda disk veya ağ I/O'su bekliyor ve Linux onları da yükte sayıyor. top'ta %wa ve iostat -x'te %util sütununa bakın; yüksekse darboğaz işlemcide değil disktedir.

CPU eklemek yükü düşürür mü?

Sadece darboğaz gerçekten CPU ise. Eğer kök neden I/O, RAM yetersizliği veya swap ise, daha fazla çekirdek sorunu gizler ve kısa bir süre sonra yük aynı sayıya geri döner. Önce vmstat ve iostat ile kök nedeni bulun.

load average ile CPU kullanımı arasındaki fark nedir?

CPU kullanımı işlemcinin zamanının yüzde kaçını çalışarak geçirdiğini söyler; yük ise kaç işin kuyrukta olduğunu söyler. Bir CPU yüzde 100 meşgul olup yük 1 olabilir, ya da yüzde 10 meşgul olup yük 20 olabilir çünkü geri kalanı diski bekliyordur.

Sonraki adım: şimdi nproc ve uptime'ı yan yana koyun ve oranı hesaplayın. Eğer 1.5'in üzerindeyse, herhangi bir işlem yapmadan önce top'u açın ve o yükün CPU'dan mı yoksa %wa'dan mı geldiğini görmek için 1 tuşuna basın. Bu tek bakış, teşhisin yarısını bitirir.