
Sunucu performans izleme, bir Linux sunucunun neden yavaşladığını tahmin yürütmek yerine ölçerek anlamanın yoludur. Bir web sitesi geç açıldığında ya da bir uygulama zaman zaman takıldığında sorunun kaynağı işlemci, bellek, disk veya ağ olabilir; her birinin çözümü farklıdır. Yanlış teşhis, gereksiz yere daha büyük bir pakete geçmeye ya da asıl sorunun gözden kaçmasına yol açar. Bu rehberde Ubuntu 22.04/24.04 ve AlmaLinux 9 üzerinde uptime, htop, free, vmstat, iostat, pidstat ve sar gibi temel araçlarla darboğazı nasıl bulacağınızı, çıktılardaki hangi değerlerin gerçekten önemli olduğunu ve sanal sunuculara özgü göstergeleri adım adım anlatıyoruz.
İlk Bakış: uptime ve Load Average
Sunucuya bağlandığınızda ilk çalıştıracağınız komut genellikle uptime'dır:
uptime
14:22:05 up 12 days, 3:41, 1 user, load average: 3.12, 2.85, 1.40
nproc
4
Load average değerleri sırasıyla son 1, 5 ve 15 dakikanın ortalamasıdır. Linux'ta bu sayı, çalışmak için işlemci bekleyen süreçlerle birlikte kesintisiz olarak disk veya başka bir giriş-çıkış işlemi bekleyen süreçleri de içerir. Bu yüzden yüksek load average her zaman işlemci yetersizliği anlamına gelmez; disk darboğazı da load değerini yükseltir.
Değerlendirmeyi çekirdek sayısıyla birlikte yapın. nproc çıktısı 4 olan bir sunucuda 3 civarındaki load, çekirdeklerin büyük ölçüde dolu olduğunu ama henüz kuyruk oluşmadığını gösterir. Load sürekli olarak çekirdek sayısının üzerindeyse süreçler sıra bekliyor demektir. Üç değerin karşılaştırılması da eğilimi gösterir: Yukarıdaki örnekte 1 dakikalık değer 15 dakikalık değerden yüksek olduğu için yük artış eğilimindedir.
top ve htop ile Anlık Durum
top her Linux sistemde hazır gelir. Daha okunaklı ve etkileşimli bir arayüz için htop kurmanızı öneririz:
# Ubuntu
sudo apt install htop
# AlmaLinux 9 (EPEL deposu gerekir)
sudo dnf install -y epel-release
sudo dnf install -y htop
htop ekranının üst kısmında her çekirdeğin kullanımı, bellek ve swap çubukları ile load average görünür. Sık kullanılan tuşlar şunlardır: F6 sıralama ölçütünü seçer (CPU veya bellek), F5 süreçleri ağaç görünümünde gösterir, F4 ada göre filtreler, F9 seçili sürece sinyal gönderir.
top çıktısındaki %Cpu(s) satırı, işlemci zamanının nereye gittiğini özetler:
| Alan | Anlamı | Yüksekse ne düşünmeli? |
|---|---|---|
| us | Kullanıcı süreçleri (uygulamalar) | Uygulama işlemciyi yoğun kullanıyor |
| sy | Çekirdek (sistem çağrıları) | Çok sayıda bağlantı, ağ veya dosya işlemi |
| wa | Giriş-çıkış beklemesi | Disk darboğazı olası |
| id | Boşta | Düşükse işlemci dolu |
| st | Steal: sanal makinenin beklediği süre | Fiziksel sunucudaki işlemci paylaşımı yetersiz |
Bellek: free ve OOM Kayıtları
free -h
total used free shared buff/cache available
Mem: 7.7Gi 2.9Gi 0.6Gi 45Mi 4.2Gi 4.5Gi
Swap: 2.0Gi 0B 2.0Gi
Yeni kullanıcıların en sık yanılgısı free sütununa bakıp belleğin bittiğini düşünmektir. Linux boş belleği disk önbelleği (buff/cache) olarak kullanır ve uygulamalar ihtiyaç duyduğunda bu alanı geri verir. Asıl bakmanız gereken sütun available'dır; uygulamaların swap'a düşmeden kullanabileceği yaklaşık bellek miktarını gösterir.
Bellek gerçekten tükendiğinde çekirdeğin OOM (Out of Memory) mekanizması bir süreci sonlandırır. Veritabanınız veya uygulamanız ara sıra kendiliğinden kapanıyorsa şu kayıtlara bakın:
sudo journalctl -k | grep -iE 'out of memory|oom-kill'
sudo dmesg -T | grep -i oom
Bu kayıtları sık görüyorsanız ya uygulamanın bellek ayarlarını düşürmeniz ya da bellek miktarını artırmanız gerekir. Geçici bir tampon olarak swap alanı eklemek için Linux'ta swap alanı oluşturma rehberimize, doğru bellek miktarını belirlemek için VDS için kaç GB RAM gerekir yazımıza bakabilirsiniz.
vmstat ile Sistemin Nabzını Ölçmek
vmstat, işlemci, bellek, swap ve disk etkinliğini tek satırda özetler. Aşağıdaki komut her saniye bir satır olmak üzere beş ölçüm alır:
vmstat 1 5
İlk satır sistemin açılışından bu yana ortalamayı gösterir; anlık durumu değerlendirirken sonraki satırlara bakın. En önemli sütunlar şunlardır:
- r: İşlemci bekleyen süreç sayısı. Sürekli olarak çekirdek sayısının üzerindeyse işlemci yetersizdir.
- b: Giriş-çıkış nedeniyle bloklanmış süreç sayısı. Sürekli sıfırdan büyükse disk yavaş kalıyor olabilir.
- si / so: Swap'tan okunan ve swap'a yazılan bellek. Bu değerlerin sürekli sıfırdan büyük olması, belleğin yetmediğinin en net işaretidir.
- bi / bo: Diskten okunan ve diske yazılan blok miktarı.
- us, sy, id, wa, st: top'taki işlemci dağılımının aynısı.
iostat ile Disk Performansını Ölçmek
iostat, sysstat paketinin bir parçasıdır ve disk başına ayrıntılı istatistik verir:
# Ubuntu
sudo apt install sysstat
# AlmaLinux 9
sudo dnf install -y sysstat
# Genişletilmiş çıktı, boşta olan diskleri gizle, 1 saniye aralıkla 3 ölçüm
iostat -xz 1 3
Dikkat etmeniz gereken başlıca sütunlar:
| Sütun | Anlamı | Yorum |
|---|---|---|
| r/s, w/s | Saniyedeki okuma ve yazma işlemi | Diskin aldığı IOPS yükü |
| rkB/s, wkB/s | Saniyedeki okuma ve yazma miktarı | Aktarım hızı |
| r_await, w_await | Bir isteğin ortalama tamamlanma süresi (ms) | Gecikme; sürekli yüksekse disk zorlanıyor |
| aqu-sz | Ortalama kuyruk uzunluğu | Bekleyen isteklerin birikip birikmediği |
| %util | Diskin meşgul olduğu zaman oranı | NVMe'de tek başına yanıltıcı olabilir |
NVMe SSD'ler aynı anda çok sayıda isteği paralel işleyebildiği için %util değerinin 100'e yaklaşması diskin sınırına ulaştığı anlamına gelmeyebilir. NVMe disklerde await değerleri ve kuyruk uzunluğu daha güvenilir göstergelerdir. Disk teknolojilerinin performans farklarını NVMe SSD ile SATA SSD farkı yazımızda ele aldık.
Sorunlu Süreci Bulmak: pidstat ve iotop
Darboğazın türünü bulduktan sonra sıradaki soru, bu yükü hangi sürecin oluşturduğudur. pidstat da sysstat paketiyle gelir:
# Süreç bazında CPU kullanımı
pidstat 1 5
# Süreç bazında disk okuma/yazma
pidstat -d 1 5
# Süreç bazında bellek
pidstat -r 1 5
Disk etkinliğini canlı izlemek için iotop da kullanışlıdır. Yalnızca o anda disk kullanan süreçleri gösterip birikimli değerleri görmek için:
sudo iotop -oPa
Disk alanı ile ilgili sorunlar da performansı doğrudan etkiler. Dolmuş bir disk, veritabanlarının yazamamasına ve servislerin çökmesine yol açar:
df -h
df -i
sudo du -xh / --max-depth=1 2>/dev/null | sort -h
journalctl --disk-usage
df -i komutu inode kullanımını gösterir; çok sayıda küçük dosya üreten uygulamalarda disk boş görünse bile inode'lar tükenebilir.
Ağ Bağlantılarını İzlemek
Ağ tarafında ilk bakılacak araç ss'tir:
# Bağlantı özetleri
ss -s
# Dinlenen portlar ve ilgili süreçler
sudo ss -tulpn
# Kurulu TCP bağlantı sayısı
ss -tn state established | wc -l
# Arayüz bazında trafik ve hata sayaçları
ip -s link
Anlık bant genişliği kullanımını görmek için nload veya iftop gibi araçlar kurulabilir (AlmaLinux'ta EPEL deposundan). Sunucunun kendisi sağlıklı görünürken kullanıcılar yavaşlıktan şikâyet ediyorsa sorun ağ yolunda olabilir; gecikmeyi ve paket kaybını ping ve traceroute aracımızla farklı noktalardan test edebilirsiniz.
Geçmişe Dönük İzleme: sar
Anlık araçlar ancak sorun yaşanırken bağlıysanız işe yarar. Gece yaşanan bir yavaşlamayı sonradan incelemek için sar ile düzenli veri toplamak gerekir. sysstat paketindeki toplayıcıyı etkinleştirin:
# Ubuntu: önce toplamayı etkinleştirin
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat
# AlmaLinux 9
sudo systemctl enable --now sysstat
Birkaç saat sonra geçmiş verileri sorgulayabilirsiniz:
sar -u # işlemci
sar -r # bellek
sar -d # disk
sar -n DEV # ağ arayüzleri
sar -q # load average ve kuyruk
Veri dosyaları Ubuntu'da /var/log/sysstat/, AlmaLinux'ta /var/log/sa/ altında tutulur. Belirli bir günün verisi -f parametresiyle okunur. Daha kapsamlı ihtiyaçlarda Netdata, Prometheus ve Grafana gibi araçlarla grafik tabanlı izleme ve alarm kurmak da mümkündür.
Sanal Sunucularda Steal Time ve Özet Tablo
VDS ve VPS gibi sanal sunucularda st (steal) değeri, sanal işlemcinizin çalışmaya hazır olduğu halde fiziksel işlemciyi bekleyerek geçirdiği süreyi gösterir. Kendi uygulamanız hafif çalışırken bile steal değerinin sürekli yüksek olması, fiziksel sunucudaki kaynak paylaşımının yetersiz kaldığına işaret eder ve sizin tarafınızda yapılacak bir optimizasyonla çözülmez. Bu durumda sağlayıcınızla iletişime geçmek ya da kaynakları ayrılmış bir pakete geçmek gerekir. İşlemci gücünün gerçekten yetmediği durumlarda doğru çekirdek sayısını seçmek için VDS'te vCPU ve çekirdek seçimi yazımız yol gösterecektir.
Özet: Belirtiye göre hangi araç?
| Belirti | İlk bakılacak araç | Gösterge |
|---|---|---|
| Her şey yavaş, load yüksek | top / htop, vmstat | us ve sy yüksekse CPU, wa yüksekse disk |
| Uygulama kendiliğinden kapanıyor | journalctl -k, free -h | OOM kayıtları, düşük available |
| Veritabanı sorguları ara ara takılıyor | iostat -xz, pidstat -d | Yüksek await, uzun kuyruk |
| Yük yokken bile performans dalgalı | top, vmstat | Yüksek st (steal) değeri |
| Siteye erişim yavaş, sunucu rahat | ss, ping/traceroute | Bağlantı sayısı, paket kaybı |
Sık Sorulan Sorular
Load average kaç olursa sorun vardır?
Mutlak bir sınır yoktur; değeri çekirdek sayısıyla karşılaştırmak gerekir. Load sürekli olarak çekirdek sayısının üzerindeyse süreçler kuyrukta bekliyordur. Ancak yüksek load'ın nedeni disk beklemesi de olabileceği için vmstat ve iostat ile birlikte değerlendirin.
free komutunda boş bellek çok az görünüyor, sorun mu var?
Genellikle hayır. Linux kullanılmayan belleği disk önbelleği olarak değerlendirir. available sütunu yeterli miktardaysa ve swap etkinliği (vmstat'taki si/so) yoksa bellek tarafında sorun yoktur.
htop ile top arasındaki fark nedir?
İkisi de aynı bilgiyi gösterir. htop renkli, çekirdek bazlı ve fareyle kullanılabilir bir arayüz sunar, süreçleri ağaç görünümünde göstermeyi ve filtrelemeyi kolaylaştırır. top ise her sistemde kurulum gerektirmeden hazırdır.
İzleme araçları sunucuyu yavaşlatır mı?
Bu yazıdaki araçların kaynak tüketimi çok düşüktür. sar'ın düzenli veri toplaması da hafif bir işlemdir. Yalnızca çok kısa aralıklarla ve uzun süre çalıştırılan ayrıntılı izleme araçları ölçülebilir bir yük oluşturabilir.
Ne zaman daha büyük bir sunucuya geçmeliyim?
Optimizasyonlardan sonra bile load sürekli çekirdek sayısının üzerindeyse, swap etkinliği devam ediyorsa veya disk gecikmesi iş yükünüzü etkiliyorsa kaynak artırmanın zamanı gelmiştir. Ölçüm verisi, hangi kaynağı artırmanız gerektiğini de gösterir.
Düzenli sunucu performans izleme, sorunları kullanıcılarınız fark etmeden yakalamanızı ve kaynakları doğru boyutlandırmanızı sağlar. Ölçümleriniz daha fazla güce ihtiyaç olduğunu gösteriyorsa NVMe SSD diskli VDS satın al seçeneklerimizi, yüksek tek çekirdek performansı için Ryzen 9 9950X işlemcili sunucularımızı ya da kaynakları tamamen size ayrılmış Ankara lokasyonlu dedicated sunucu paketlerimizi inceleyebilirsiniz.
Hizmet Sözleşmemiz
Web Koruma
İade Politikamız
