Bir sanal sunucu kiraladıktan sonra işin yarısı bitiyor; geri kalanı, o kaynakların nasıl harcandığını anlamaktan geçiyor. İşlemci ve bellek tüketimini düzenli takip etmeyen bir yönetici, sitenin neden yavaşladığını ya da gece yarısı neden swap'a düştüğünü çoğu zaman çok geç fark eder. Aşağıda Linux tabanlı bir VDS üzerinde bu iki kaynağı hem anlık hem de geçmişe dönük olarak nasıl gözlemleyeceğinizi adım adım ele alıyorum.

Neden Düzenli İzleme Şart

Paylaşımlı barındırmanın aksine sanal sunucuda kaynaklar size tahsis edilir, ama sınırsız değildir. vCPU çekirdeği sürekli %90 bandında geziyorsa ya da kullanılabilir RAM birkaç yüz megabayta inip swap devreye giriyorsa, kullanıcı tarafında bunun karşılığı artan yanıt süresi ve zaman zaman 502/504 hatalarıdır. Düzenli ölçüm yapmak, bir sanal sunucu paketinin mevcut yüke yetip yetmediğini somut sayılarla görmenizi sağlar; tahmin yürütmek yerine veriye bakarsınız.

Anlık Bakış: top ve htop

İlk reflex genellikle top komutudur. Çıktının üst kısmındaki load average üç değer verir: son 1, 5 ve 15 dakikalık ortalama yük. Pratik bir kural olarak bu değerin vCPU sayısını aşmaması beklenir; 4 çekirdekli bir VDS'de 4.00 civarı tam doluluk demektir. %Cpu(s) satırındaki us (kullanıcı), sy (kernel), wa (I/O bekleme) ve st (steal) alanları da kritik ipuçları taşır.

  • wa yüksekse: İşlemci boşta ama disk I/O'su darboğaz oluşturuyordur.
  • st (steal) yüksekse: Hipervizör katmanı vCPU zamanınızı başka misafirlere ayırıyor olabilir; aşırı yoğun bir fiziksel host işareti.
  • sy sürekli yüksekse: Çok fazla sistem çağrısı ya da bağlam değişimi vardır.

Daha okunaklı bir arayüz için htop tercih edilir. Renkli çekirdek çubukları, ağaç görünümü (F5) ve doğrudan arayüz üzerinden sinyal gönderme (F9) işi kolaylaştırır. Kurulum çoğu dağıtımda tek satırdır:

# Debian / Ubuntu
apt update && apt install -y htop

# AlmaLinux / Rocky / CentOS
dnf install -y htop

htop

Belleği Doğru Okumak: free -h

RAM konusunda en sık yapılan hata, free çıktısındaki used sütununa bakıp paniklemektir. Linux, boşta duran belleği disk önbelleği (buff/cache) olarak değerlendirir ve uygulama ihtiyaç duyduğunda anında geri verir. Asıl bakılması gereken sütun available'dır.

free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8Gi       2.1Gi       0.4Gi       0.2Gi       5.3Gi       5.2Gi
Swap:          2.0Gi       0.0Gi       2.0Gi

Bu örnekte 7.8 GiB belleğin görünürde 2.1 GiB'i kullanılıyor gibi dursa da, gerçekte 5.2 GiB hâlâ uygulamalara açık. Swap'ın 0 olması da iyiye işaret; swap sürekli doluyorsa fiziksel bellek yetersiz kalıyor demektir.

Geçmişe Dönük Veri: vmstat ve sar

Anlık komutlar sorun yaşandığı anda işe yarar, ama gece 03:00'te yaşanan bir tıkanıklığı sabah araştırmak için tarihsel kayıt gerekir. vmstat belirli aralıklarla örnek alır:

# 2 saniye aralıkla 10 örnek
vmstat 2 10

Burada r (çalışmayı bekleyen süreç sayısı), si/so (swap giriş/çıkış) ve wa sütunları yine yol göstericidir. Sürekli sıfırdan büyük si/so değerleri, belleğin yetmediğinin net göstergesidir.

Daha kapsamlı geçmiş için sysstat paketinin parçası olan sar kullanılır. Kurulduğunda dakikalık örnekleri otomatik kaydeder:

apt install -y sysstat
systemctl enable --now sysstat

# CPU geçmişi
sar -u
# Bellek geçmişi
sar -r
# Belirli bir günün kaydı
sar -u -f /var/log/sysstat/sa15

İzleme Araçlarının Karşılaştırması

AraçTipGüçlü YönüNe Zaman
topAnlıkHer sistemde hazırHızlı kontrol
htopAnlıkGörsel, etkileşimliSüreç avlama
free -hAnlıkNet bellek özetiRAM kontrolü
vmstatÖrneklemeswap/I/O görünürlüğüKısa süreli izleme
sarTarihselGeçmişe dönük kayıtOlay sonrası analiz

Süreç Bazında Suçluyu Bulmak

Toplam yük yüksekken işi hangi sürecin yaptığını görmek için ps sıralaması işe yarar:

# CPU'ya göre ilk 10
ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu | head -n 11

# Belleğe göre ilk 10
ps -eo pid,comm,%mem,rss --sort=-%mem | head -n 11

cgroup v2 kullanan modern dağıtımlarda systemd-cgtop de servis bazında tüketimi gösterir; özellikle birden çok hizmetin aynı sunucuda koştuğu kurulumlarda kaynak hangi unit'e ait, anında ayırt edersiniz.

Bogahost Önerisi: İzlemeyi tek seferlik bir iş gibi görmeyin. sysstat'ı kurup haftalık sar -u ve sar -r çıktılarına göz atın; yük yaklaşık olarak çekirdek sayısının üçte ikisini kalıcı biçimde aşmaya başladığında, sorun büyümeden bir üst pakete geçmeyi planlayın.

Sürekli İzleme İçin Hafif Çözümler

Komut satırı manuel kontrol için yeterli, ama grafiksel ve uyarı verebilen bir yapı çoğu durumda daha sürdürülebilirdir. Tek sunucu için Netdata dakikalar içinde kurulur ve tarayıcıdan saniyelik çözünürlükte CPU/RAM grafikleri sunar:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)
# Varsayılan olarak http://SUNUCU_IP:19999
  • Netdata: Kur-çalıştır, tek sunucu için ideal, eşik bazlı alarm üretir.
  • Prometheus + node_exporter + Grafana: Birden çok sunucuyu merkezi izlemek isteyenler için esnek ama kurulum yükü daha fazla.
  • Glances: Terminalde tek ekranda CPU, RAM, disk ve ağı birlikte gösteren pratik bir ara çözüm.

Yüksek tek çekirdek başına performansının kritik olduğu iş yüklerinde, ölçüm sonuçlarınız sürekli işlemci darboğazına işaret ediyorsa, yüksek frekanslı bir Ryzen tabanlı VDS sanal sunucu seçeneği aynı çekirdek sayısında belirgin nefes alanı açabilir.

Özetle

İşin özü, anlık araçları (top, htop, free) sorun anında, örnekleme ve tarihsel araçları (vmstat, sar) ise kök neden analizinde birlikte kullanmak. Bu alışkanlığı edindiğinizde sunucunuzun davranışı sürpriz olmaktan çıkar; ne zaman ölçeklendireceğinizi tahminle değil, biriktirdiğiniz sayılarla belirlersiniz.

Reklam Alanı

İçerik Altı (728x90)

Etiketler:
VDS linux Sunucu Performansı CPU izleme RAM izleme htop vmstat sar
İlgili İçerikler

Yorumlar (0)

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Yorum Yap

Maksimum 2000 karakter

İlgili Yazılar