Linux Sunucu Performans İzleme: top, htop, free, vmstat ve iostat

Sunucu yavaşladığında nedeni tahmin etmek yerine ölçmenin yolu, her Linux dağıtımında hazır gelen ya da tek paketle kurulan birkaç komutun çıktısını doğru okumaktır. Linux sunucu performans izleme pratikte beş soruya yanıt arar: işlemci yetiyor mu, bellek gerçekten doldu mu, disk istekleri bekliyor mu, disk alanı ya da inode tükendi mi ve sanallaştırma katmanı işlemci zamanınızı kısıyor mu?

Komutların tamamı Ubuntu 24.04 LTS, Debian 12 ve Debian 13’te aynı biçimde çalışır; bir VPS sunucu ile fiziksel sunucu arasında kullanım farkı yoktur. Bu araçlar anlık teşhis içindir; uzun süreli kayıt ve uyarı düzeni sunucu izleme ve uptime takibi yazısında anlatılır.

Linux sunucu performans izleme hangi sırayla yapılır?

En hızlı teşhis genelden özele giden sabit bir sırayla yapılır; her komut bir sonraki adımda nereye bakacağınızı söyler:

1. uptime ve nproc: yük ortalaması çekirdek sayısına göre yüksek mi?
2. top ya da htop: kaynağı hangi süreç tüketiyor, işlemci zamanı nereye gidiyor?
3. free -h: kullanılabilir bellek ve takas (swap) durumu.
4. vmstat 1 5: sırada bekleyen süreçler, takas hareketi, disk beklemesi.
5. iostat -xz 1: hangi diskin ne kadar meşgul olduğu.
6. df -h ve df -i: disk alanı ve inode doluluğu.
7. ss -s ve journalctl -p err -b: bağlantı özeti ve son açılıştan bu yana kaydedilen hatalar.

Bu tur birkaç dakika sürer ve sorunların büyük kısmını tek bir kaynağa indirger. iostat sysstat paketiyle, htop ve iotop ise kendi paketleriyle gelir:

sudo apt update
sudo apt install sysstat htop iotop

Komutların temel kullanımına yabancıysanız önce Linux temel komutlar rehberine göz atın.

Load average ne anlama gelir, kaç olmalı?

Load average, son 1, 5 ve 15 dakikada çalışan ya da çalışmak için sırada bekleyen süreçlerin ortalama sayısıdır ve ancak çekirdek sayısıyla birlikte yorumlanabilir. Linux, disk yanıtı beklerken kesintisiz uykuda (D durumu) olan süreçleri de bu sayıya kattığı için yüksek yük her zaman işlemci yetersizliği demek değildir.

$ uptime
 14:02:11 up 12 days,  3:41,  1 user,  load average: 3.92, 2.10, 1.35
$ nproc
4

Örnekte dört sanal işlemci çekirdekli (vCPU) sunucuda 1 dakikalık yük 3,92’dir: kapasite neredeyse dolu ve yük artış eğiliminde, çünkü 1 dakikalık değer 15 dakikalıktan yüksek. Kaba ölçü olarak yükün sürekli çekirdek sayısını aşması işlerin sırada beklediğini gösterir. Yük yüksekken top işlemciyi büyük ölçüde boşta gösteriyorsa sebep büyük olasılıkla disk beklemesidir; bunu wa değeri ve vmstat çıktısındaki b sütunu doğrular.

top ve htop çıktısında hangi alanlara bakılır?

top çıktısında en çok bilgi veren satır, işlemci zamanının nereye harcandığını gösteren %Cpu(s) satırıdır:

%Cpu(s): 62.0 us,  9.5 sy,  0.0 ni, 12.1 id, 14.8 wa,  0.0 hi,  0.6 si,  1.0 st

top açıkken P işlemciye, M belleğe göre sıralar, 1 her çekirdeği ayrı gösterir. htop aynı bilgiyi renkli çubuklarla verir: F6 sıralama ölçütünü seçer, F5 süreç ağacını açar, F4 ada göre filtreler. Ağaç görünümü, örneğin onlarca PHP-FPM alt sürecinin hangi havuza ait olduğunu bir bakışta gösterir.

Bellek gerçekten yetmiyor mu? free çıktısı ve OOM izleri

Belleğin yetip yetmediğini free -h çıktısındaki available sütunu söyler; free sütununun düşük olması normaldir, çünkü Linux boştaki belleği disk önbelleği (buff/cache) olarak kullanır ve uygulamalar istediğinde geri verir.

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       4.9Gi       312Mi       180Mi       2.6Gi       2.3Gi
Swap:          2.0Gi       1.4Gi       620Mi

Asıl alarm işaretleri, available değerinin toplamın küçük bir kesrine inmesi, takas kullanımının artması ve vmstat çıktısında si/so sütunlarının sürekli sıfırdan büyük olmasıdır. Bellek tamamen tükendiğinde çekirdeğin OOM (Out Of Memory) killer mekanizması en çok bellek tüketen süreçlerden birini sonlandırır; veritabanı “kendiliğinden” durduysa önce buna bakın:

sudo dmesg -T | grep -i -E 'killed process|out of memory'

Çıktıda mysqld, mariadbd ya da php-fpm görüyorsanız ya servislerin bellek ayarları (havuz başına süreç sayısı, veritabanı tampon boyutu) fazla cömerttir ya da sunucunun belleği iş yüküne yetmiyordur. Geçici bir tampon için Linux swap alanı oluşturma, kalıcı çözüm için VPS kaynak yükseltme rehberine bakın.

vmstat ve iostat ile disk darboğazı nasıl ayırt edilir?

vmstat 1 5 beş saniye boyunca saniyede bir özet verir ve işlemci, bellek ve disk baskısını tek tabloda gösterir; ilk satır açılıştan bu yana ortalama olduğu için yok sayılır. Bakılacak sütunlar: r (çalışmayı bekleyen süreç; sürekli çekirdek sayısının üstündeyse işlemci yetmiyor), b (G/Ç beklerken bloklanan süreç), si/so (takastan okunan ve takasa yazılan bellek) ve wa.

Disk şüphesi doğduysa iostat -xz 1 her diski ayrı gösterir; -x ayrıntılı sütunları açar, -z boştaki diskleri gizler. Aşağıdaki çıktı sadeleştirilmiştir, gerçek çıktıda daha çok sütun bulunur:

Device   r/s    w/s   rkB/s   wkB/s  r_await  w_await  aqu-sz  %util
vda     12.0  410.0    96.0  9840.0     0.9     38.5    15.8   99.6

• r_await / w_await: bir isteğin kuyruk dahil ortalama süresi (milisaniye). Yerel NVMe diskte bu değer genellikle birkaç milisaniyeyi geçmez; sürekli onlarca milisaniye sıkışma demektir.
• aqu-sz: ortalama kuyruk uzunluğu; sürekli yüksekse disk yetişemiyor.
• %util: diskin meşgul olduğu zaman oranı. NVMe ve SSD’ler istekleri paralel işlediği için %100 tek başına doygunluk kanıtı değildir; await ile birlikte okuyun.

Diski hangi sürecin yorduğunu sudo iotop -o gösterir; yeni çekirdeklerde IO% sütunu için sudo sysctl kernel.task_delayacct=1 gerekebilir.

Disk alanı, inode ve ağ bağlantıları nasıl kontrol edilir?

Disk alanını df -h, inode sayısını df -i gösterir; disk dolduğunda servisler yazamaz, veritabanı durur ve günlükler kesilir. Alan boşken “No space left on device” hatası alıyorsanız inode’lar tükenmiştir; çok sayıda küçük dosya (oturum, önbellek, e-posta kuyruğu) üreten klasörü arayın. Kavramın ayrıntısı inode nedir yazısında.

df -h
df -i
sudo du -xh --max-depth=1 /var | sort -h | tail -n 10
journalctl --disk-usage

Büyük klasörü bulduktan sonra eski günlükleri elle silmek yerine günlük döndürmeyi (logrotate) düzeltin; systemd günlüğünü sudo journalctl --vacuum-size=500M ile sınırlayabilirsiniz.

Ağ tarafında ss -s bağlantı özetini, sudo ss -tulpn dinleyen portları ve bunları açan süreçleri listeler. Beklemediğiniz bir portta dinleyen süreç güvenlik sorunudur; binlerce ESTAB ya da TIME-WAIT bağlantısı ise trafik artışına ya da bot saldırısına işaret eder. Son açılıştan bu yana kaydedilen hataları journalctl -p err -b ile görün.

Steal time nedir, VPS’te neden önemlidir?

Steal time (st), sanal sunucunuzun çalışmaya hazır olduğu hâlde hipervizör işlemciyi başka bir sanal makineye verdiği için beklediği süredir ve yalnızca sanal ortamlarda görülür. top ve vmstat çıktısında ayrı bir sütun olarak izlenir.

• Ara sıra birkaç yüzde: İşlemcisi paylaşımlı VPS’lerde olağandır.
• Sürekli yüksek ve yükle birlikte artıyor: Uygulamanız yavaşlar ama kendi süreçleriniz işlemciyi doldurmuyor görünür; sorun sizin sunucunuzda değil, fiziksel sunucudaki işlemci paylaşımındadır.

Bu durumda vmstat -t 1 60 ile zaman damgalı bir dakikalık kayıt alın ve LIONFIN müşteri panelindeki Destek bölümünden açacağınız talebe ekleyin; bulgu sağlayıcı tarafında doğrulanabilir. Sorun düzenli tekrarlanıyorsa çekirdekleri size ayrılmış bir VDS sunucu daha öngörülebilir performans sağlar; farkın ayrıntısı VPS VDS farkı yazısında.

Hangi metrik ne anlatır? Hızlı karar tablosu

Komut çıktılarındaki gözlemi olası nedenle eşleştirmek, ilk müdahaleyi doğru kaynağa yöneltir:

Tablo anlık bir fotoğraf verir. Linux sunucu performans izleme alışkanlığını sürekli hâle getirmek için aynı metrikleri bir izleme aracında grafiğe dökün; sorun gece başlayıp sabah kendiliğinden geçtiyse komutları çalıştırdığınızda iz kalmamış olabilir.