Linux izleme komutları: CPU, bellek, I/O ve ağ

Sunucu yanıt veriyor ama yavaş. SSH gecikmeli açılıyor, top komutunu çalıştırıyorsunuz ve load average'ın 14 olduğunu görüyorsunuz, ama CPU neredeyse boşta. Burada çoğu kişi CPU'yu yoğun kullanan süreci arar ve bulamaz, çünkü sorun başka bir yerdedir. Bu metin, ne aradığını bilen ve her çıktı sütununun tam olarak neyi ölçtüğünü anlamak isteyenler için kısa bir referanstır.

load average neyi sayar ve neyi saymaz

uptime çıktısındaki ilk sayı, son 1, 5 ve 15 dakikada çalışma kuyruğunda veya kesintisiz bekleme durumunda (D state) olan süreçlerin ortalama sayısıdır. Anahtar kelime "kesintisiz"dir. Diskten okuma yaparken bloklanan bir süreç de bu sayıya dahil edilir, bir saniye bile CPU almamış olsa dahi.

Yani 4 çekirdekli bir sunucuda load 14 olması illa CPU'nun doygun olduğu anlamına gelmez. Önce çekirdek sayısına bakın:

nproc
grep -c ^processor /proc/cpuinfo

Eğer load çekirdek sayısından fazlaysa, şimdi kuyruğun nereden geldiğini anlamanız gerekir. Bu ayrım, işin tamamıdır.

top çıktısında gerçekten önemli olan sütunlar

top içinde 1 tuşuna basarak her çekirdeği ayrı gösterin; eğer bir çekirdek %100 ve diğerleri boştaysa, sorun tek iş parçacıklı (single-thread) bir sorundur, genel kapasite eksikliği değil. c tuşu komutun tam yolunu gösterir ve H tuşu thread'leri açar.

Üç sütuna bakın: %wa (iowait), %si (softirq) ve %st (steal). Eğer %wa %20'nin üzerindeyse, CPU kurban, suçlu değil. Eğer %st sıfırın üzerinde ve kararlıysa, ana makinedeki hypervisor size payınızı vermiyor ve makine içindeki hiçbir ayar bunu çözmez; burada sağlayıcıyla konuşmanız gerekir. Bulut sunucu üzerinde bu sayı genellikle sıfırdır ve değilse hızlıca takip edin.

RES sütunu sürecin gerçek fiziksel belleğidir ve VIRT neredeyse anlamsızdır; Java ve Go süreçleri hiçbir şey tüketmeden yüzlerce megabayt VIRT gösterir. top çıktısındaki en yanıltıcı sütun budur.

Bellek: free neden neredeyse her zaman az

free -h çıktısına bakın. Doğru ölçüt available sütunudur, free değil. Linux sayfa önbelleğini bellekte tutar ve onu boş olarak ilan etmez, çünkü belleği boş tutmak israftır. free değeri 200 megabayt ve available değeri 6 gigabayt olan bir sunucunun bellek sorunu yoktur.

free -h
cat /proc/meminfo | grep -E 'MemAvailable|Dirty|Writeback'

Dirty ve Writeback değerlerini ciddiye alın. Eğer Dirty sürekli olarak birkaç yüz megabaytın üzerinde kalıyorsa, çekirdek veriyi diske yeterince hızlı ulaştıramıyor demektir. Sonuç, D durumunda çok sayıda süreç ve CPU boşken yüksek load'dur. Burada sorun I/O'dur ve iostat'a yönelmeniz gerekir.

OOM killer'ı nereden anlarız

dmesg -T | grep -i -E 'oom|killed process'
journalctl -k --since "1 hour ago" | grep -i oom

Out of memory: Killed process 2841 (mysqld) gibi bir satır, çekirdeğin süreci öldürdüğü anlamına gelir. Eğer MySQL sebepsiz yeniden başlıyorsa ve kendi logunda bir şey yoksa, büyük olasılıkla sebep budur. Restart=always ile systemd servisleri hemen ayağa kalkar ve siz sadece kısa bir kesinti görürsünüz.

I/O: yüksek load'ların çoğunun doğduğu yer

Doğru araç sysstat paketinden gelen iostat'tır, top değil:

iostat -xz 2 5

-x bayrağı genişletilmiş istatistikleri ve -z etkin olmayan diskleri çıkarmayı sağlar. Üç sütun belirleyicidir:

• %util: Aygıtın meşgul olduğu zamanın yüzdesi. Mekanik diskte %90'ın üzeri doyma anlamına gelir. NVMe'de bu sayı 100'e zor ulaşır çünkü birden fazla paralel kuyruğu vardır ve %util artık eski anlamını taşımaz.
• await: Her istek için ortalama milisaniye cinsinden bekleme, kuyruk süresi dahil. SSD'de 1ms altı normaldir; 20ms üzeri sorununuz var demektir.
• aqu-sz: Ortalama kuyruk uzunluğu. Büyük sayı ve büyük await, aygıtın darboğaz olduğu anlamına gelir, uygulamanın değil.

Bu I/O'yu hangi sürecin oluşturduğunu görmek için iotop -oPa çalıştırın. -o bayrağı sadece aktif süreçleri, -P thread yerine süreci, -a kümülatif değeri gösterir.

Burada hata yapılır: çoğu kişi yüksek %util değerini "disk bozuk" olarak yorumlar ve donanım değiştirmeye gider, oysa indekssiz bir sorgu veya --single-transaction olmadan çalışan bir mysqldump yedeği tüm diski yiyordur. İşareti, sorunun gecenin belirli saatlerinde tekrarlanmasıdır. Önce zaman desenine bakın, sonra donanımı suçlayın.

Ağ: ss, netstat'ın yerini aldı

netstat yeni dağıtımlarda ya kurulu değildir ya da yavaştır. ss kullanın:

ss -s
ss -tulpn
ss -tan state established | awk '{print $4}' | cut -d: -f2 | sort | uniq -c | sort -rn | head

İlk komut soket özetini verir. Eğer timewait on binlere ulaşmışsa, bağlantılar hızlı açılıp kapanıyordur ve net.ipv4.tcp_tw_reuse=1 ayarını düşünmelisiniz. Eğer SYN-RECV çoksa, SYN flood hedefi olabilirsiniz.

Üçüncü komut en yoğun hedef portları sayar. Binlerce ESTABLISHED bağlantısı olan bir port genellikle üst sınırı olmayan bir bağlantı havuzu veya bağlantıları kapatmayan bir betik anlamına gelir. Gerçek bant genişliğini görmek için iftop -nNP veya nload çalıştırın; vnstat -l de arayüzün kümülatif kullanımı için çalışır.

Anlık durumu kaydetmek için kısa bir betik

Sunucu yavaşladığında, siz o anda çevrimiçi değilsiniz. Her 30 saniyede durumu bir dosyaya yazan basit bir döngü koyun:

while true; do
  echo "=== $(date -Is) ===" >> /var/log/snapshot.log
  uptime >> /var/log/snapshot.log
  free -m | head -2 >> /var/log/snapshot.log
  iostat -x 1 2 | tail -20 >> /var/log/snapshot.log
  sleep 30
done

Maliyeti, kendisinin biraz I/O üretmesidir ve küçük disklerde dosya büyümesine dikkat etmelisiniz. Ama sorun iki gün sonra geri geldiğinde, bu dosya tek tanığınızdır. Betik yerine hazır araç kullanmayı tercih ediyorsanız, Sunucu yüksek load nedenini teşhis etme rehberi adım adım yolu kapsar.

Hangi iş için hangi aracı alalım

sysstat'ı etkinleştirirseniz, sar dünün durumunu da gösterebilir. Bu, geçmişi görmenin tek yoludur, çünkü top sadece şu anı görür. Etkinleştirmesi tek satırdır:

sed -i 's/^ENABLED=.*/ENABLED="true"/' /etc/default/sysstat
systemctl enable --now sysstat

vmstat hakkında bir uyarı: r sütunu çalışma kuyruğundaki süreç sayısıdır ve b bloklanmış süreç sayısıdır. Eğer r büyükse, CPU darboğazdır. Eğer b büyükse, disk. Bu tek ayrım, teşhisin yarısını çözer.

Ağır iş yapan sunucular için ve I/O'yu baştan doğru kurmak istiyorsanız, NVMe diskli özel sunucu await farkını onlarca milisaniyeden bir milisaniyenin altına indirir ve o ağır sorgu artık tüm makineyi devirmez. Eğer Linux hosting üzerindeyseniz ve root erişiminiz olmadığı için araçları kuramıyorsanız, destekten sysstat ve iotop kurmasını isteyin; bu ikisi olmadan sorun giderme neredeyse tahminden ibarettir.

Sonraki adım belli: şimdi sunucuda iostat -xz 2 5 çalıştırın ve await değerini not edin. Eğer 20ms üzerindeyse, başka herhangi bir şeyden önce iotop -oPa'ya yönelin. Bugün kaydettiğiniz temel sayı, yarın sunucu yavaşladığında tek karşılaştırma referansınızdır.

Sık sorulan sorular

load average kaç normaldir?

Doğru ölçüt sayının kendisi değil, load'un çekirdek sayısına oranıdır. 4 çekirdekli bir sunucuda load 4'ün altı kuyruğun yönetilebilir olduğu, 8'in üzeri bir şeyin doyduğu anlamına gelir. Ama %wa yüksekse, yüksek load diskten geliyordur ve CPU eklemek hiçbir yardım sağlamaz.

free neden neredeyse her zaman az bellek gösterir?

Çünkü Linux boş belleği sayfa önbelleği için harcar ve onu free sütununda saymaz. available sütunu kullanılabilir belleğin doğru tahminini verir. Eğer available toplam belleğin %10'unun altındaysa ve swap da doluyorsa, o zaman gerçek bir sorununuz var demektir.

iostat'ta %util ve await arasındaki fark nedir?

%util diskin zamanın yüzde kaçında meşgul olduğunu söyler ve await her isteğin ortalama kaç milisaniye sürdüğünü, kuyrukta bekleme süresi dahil, söyler. Birden fazla paralel kuyruğu olan NVMe'de %util düşük kalabilirken await yükselmiştir; yani await daha güvenilir bir ölçüttür.

Ağ trafiğine hangi sürecin neden olduğunu nasıl anlarım?

ss -tunp her soketin sahibi süreci gösterir ve iftop -nNP her bağlantının bant genişliğini canlı olarak görüntüler. Her arayüzün kümülatif kullanımı için vnstat -l yeterlidir. Eğer bir portta binlerce ESTABLISHED bağlantı varsa, önce onu inceleyin.