Sunucu neden yavaş? top, htop, free ve iostat çıktılarını doğru okumak

Bir sunucu yavaşladığında ilk açılan araç genellikle top'tur. Ekranda bir sürü sayı akar ve çoğu zaman yanlış olanlara bakılır. "RAM dolmuş, sunucuyu büyütelim" kararının arkasında çoğu zaman yanlış okunmuş bir free çıktısı vardır.

Load average: En çok yanlış anlaşılan sayı

load average: 3.12, 2.45, 1.80

Bu üç sayı, son 1, 5 ve 15 dakikadaki ortalama yükü gösterir. Linux'ta yük, çalışan ya da çalışmak için sırada bekleyen süreçlerin sayısıdır. Buna, diskten veri bekleyen (kesintiye uğratılamaz uykuda, D durumunda) süreçler de dahildir.

Yorumlamanın anahtarı çekirdek sayısıdır:

nproc

• 4 çekirdekli bir sunucuda 3,12 yük: Kapasitenin yaklaşık %78'i kullanılıyor. Rahat.
• 1 çekirdekli bir sunucuda 3,12 yük: Her an ortalama iki süreç sırada bekliyor. Sıkışık.

Üç sayının eğilimi de bilgi verir: 3.12, 2.45, 1.80 yükün arttığını, 1.80, 2.45, 3.12 ise azaldığını gösterir.

top ve htop: Ne bakmalı?

top ekranının üst kısmındaki CPU satırı:

%Cpu(s): 35.2 us,  4.1 sy,  0.0 ni, 52.3 id,  7.9 wa,  0.0 hi,  0.5 si,  0.0 st

• us (user): Uygulamaların (PHP, MySQL, Node) harcadığı işlemci süresi. Yüksekse, işlemciyi yoğun kullanan bir uygulama var.
• sy (system): Çekirdeğin harcadığı süre. Sürekli yüksekse çok sayıda sistem çağrısı ya da ağ trafiği olabilir.
• id (idle): Boşta geçen süre.
• wa (iowait): İşlemcinin disk ya da ağ giriş-çıkışını beklerken boşta geçirdiği süre. Bu değer yüksekse darboğaz işlemci değil, disktir.
• st (steal): Sanal sunucularda, fiziksel makinenin işlemci süresini başka sanal makinelere verdiği süre. Sürekli %5–10'un üzerindeyse sorun sizde değil, sağlayıcınızın aşırı yüklenmiş donanımındadır.

htop, top'un renkli ve daha okunaklı hâlidir. F6 ile sıralama ölçütünü değiştirebilir, F5 ile süreçleri ağaç görünümünde izleyebilir, F4 ile ada göre filtreleyebilirsiniz.

Bellek: "RAM dolu" çoğu zaman yanlış alarmdır

free -h

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.2Gi       180Mi        95Mi       2.4Gi       2.3Gi
Swap:          2.0Gi        12Mi       2.0Gi

İlk bakışta free sütununda yalnızca 180 MB boş görünür ve panik başlar. Ama Linux boştaki belleği israf saymaz; disk okumalarını hızlandırmak için önbellek (buff/cache) olarak kullanır. Bir uygulama belleğe ihtiyaç duyduğunda bu önbellek anında boşaltılır.

Bakmanız gereken sütun available'dır. Bu örnekte 2,3 GB kullanılabilir bellek var; sunucu son derece rahat.

Gerçek bir bellek sıkıntısının işaretleri şunlardır:

• available değerinin sürekli çok düşük olması
• Swap kullanımının sürekli artması ve vmstat çıktısındaki si ile so sütunlarında sürekli hareket görülmesi
• Sistem günlüğünde OOM killer kayıtları:

journalctl -k | grep -i "out of memory"
dmesg -T | grep -i "killed process"

OOM killer, bellek tamamen tükendiğinde çekirdeğin bir süreci zorla sonlandırmasıdır. Genellikle en çok bellek kullanan süreç, yani çoğu zaman MySQL ya da PHP gider. "MySQL kendiliğinden kapanıyor" şikâyetinin klasik sebebidir.

Disk: iostat ve iotop

wa değeri yüksekse, sıra diske bakmaktadır:

iostat -xz 2       # sysstat paketi gerekir

Bakılacak sütunlar:

• %util: Diskin ne kadar süre meşgul olduğu. Sürekli %90'ın üzerindeyse disk doymuştur. (Hızlı SSD ve NVMe disklerde bu değer tek başına yanıltıcı olabilir; gecikmeye de bakın.)
• r_await / w_await: Okuma ve yazma isteklerinin ortalama bekleme süresi (milisaniye). SSD'de birkaç milisaniyenin üstü dikkat çeker.

Diski hangi sürecin kullandığını görmek için:

iotop -oPa

Darboğaz teşhisi: Kısa yol

Yüksek us, düşük wa          → İşlemci: Uygulama kodu, ağır sorgular
Yüksek wa                    → Disk: Yedekleme, büyük sorgular, swap
Düşük available + swap hareketi → Bellek yetmiyor
Yüksek st                    → Sanal sunucu sağlayıcısı kaynaklı
Yük yüksek ama CPU boşta     → Süreçler disk ya da ağ bekliyor (D durumu)

Geçmişe bakmak

Sorun gece 3'te yaşandıysa, sabah top açmak işe yaramaz. sysstat paketi kurulup etkinleştirildiğinde, kaynak kullanımını düzenli aralıklarla kaydeder:

sar -u -f /var/log/sa/sa01     # 1'inci günün işlemci kullanımı (RHEL)
sar -r                         # bellek
sar -d                         # disk

Debian ve Ubuntu'da kayıtlar /var/log/sysstat/ altında tutulur.

Daha uzun vadeli ve görsel bir izleme için Netdata, Prometheus ile Grafana ya da hosting panelinizin kendi grafikleri kullanılabilir.

Sunucuyu büyütmeden önce darboğazın gerçekten nerede olduğunu bulun. Çoğu zaman sorun daha fazla donanımla değil, tek bir yavaş sorgu, yanlış ayarlanmış bir PHP havuzu ya da gece yarısı çalışan bir yedekleme betiğiyle çözülür.