Linux Performans İzleme: top, vmstat, iostat, sar Rehberi

Bir sunucu yavaşladığında ekranda "sistem yavaş" diye bir uyarı çıkmaz; CPU kuyruğu şişer, RAM takasa düşer ya da disk kuyruğu tıkanır. Sorunu tahmin ederek değil, doğru araçla ölçerek bulursunuz. Bu yazıda Linux performans izlemede kullanılan top, vmstat, iostat ve sar araçlarıyla bir darboğazı adım adım nasıl izole edeceğinizi, hangi değerin normal hangi değerin alarm sayıldığını somut örneklerle anlatıyorum.

top ve htop ile ilk bakış nasıl yapılır?

Bir performans sorununu incelerken ilk adım genelde top olur. Yük ortalaması (load average), çalışan süreç sayısı ve bellek dağılımı tek ekranda görünür.

top -o %CPU

Üstteki load average: 4.21, 3.85, 2.10 satırı son 1, 5 ve 15 dakikalık ortalama yükü gösterir. Tek çekirdekli bir sistemde 1.0'ı aşan değer kuyruklanma anlamına gelir; 8 çekirdekli bir makinede 4-5 arası hâlâ normal sayılır, çünkü yorum çekirdek sayısına göre değişir. nproc komutu çekirdek sayısını verir; load average'ı yorumlamadan önce bu sayıya bakmak doğru referansı sağlar.

htop aynı bilgiyi renkli çubuklarla, çekirdek başına ayrı gösterir ve F6 tuşu sıralama kriterini değiştirir. Kurulu değilse:

sudo apt install htop   # Debian/Ubuntu
sudo dnf install htop   # Fedora/RHEL

htop içinde F5 tuşu ağaç görünümüne geçer; bir servisin hangi alt süreçleri fork ettiğini bu görünümde izlemek kolaydır. Bir PHP-FPM ya da Node süreci beklenenden çok worker açtıysa bu, ilk bakışta fark edilir. F4 ile isme göre filtre uygulanır ve tek bir uygulamanın tüm alt süreçleri izole edilir; kalabalık bir sunucuda bu, doğru süreci bulma süresini kısaltır.

top çalışırken 1 tuşuna basmak çekirdek başına ayrı CPU satırı açar; bir işin tek çekirdeğe mi yoksa tüm çekirdeklere mi yayıldığını bu satırlardan görürsünüz. Tek çekirdek %100'de takılıp diğerleri boşta duruyorsa, uygulama çok iş parçacıklı çalışmıyor demektir. Bu durumda gereken donanım eklemek değil, uygulamayı paralel çalışacak biçimde yapılandırmaktır.

CPU sütununda %100'ü aşan değerler görülebilir; top bu sayıyı çekirdek sayısına göre normalize etmez, tek bir süreç 4 çekirdeği paralel kullanıyorsa değer %400'e kadar çıkar. Bu hatalı bir okuma değildir; sürecin kaç iş parçacığı çalıştırdığının göstergesidir. top çıktısındaki tüm alanların anlamını top kılavuz sayfasında bulabilirsiniz.

Bellek gerçekten tükeniyor mu, yoksa cache mi doluyor?

free -h çıktısında "used" değeri yüksek görünebilir; bu tek başına sorun işareti değildir, çünkü Linux boş RAM'i disk cache olarak kullanır.

free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       3.2Gi       1.1Gi       320Mi        11Gi        11Gi

Asıl bakılması gereken sütun "available" sütunudur; bu, uygulamaların gerçekten kullanabileceği bellek miktarını gösterir. buff/cache değerinin yüksek olması sorun değildir, çekirdek gerektiğinde bu belleği anında geri verir. Eski free çıktılarında bu sütun yoktu; bu yüzden bazı eski rehberler hâlâ "used" değerine bakıp yanlış alarm veriyor. Güncel bir free -h çıktısı kullanmak bu hatayı önler.

Gerçek sorun, swap sütununun dolmaya başlamasıdır. vmstat 2 komutu çalıştırılıp si/so (swap in/out) sütunları izlenir:

vmstat 2 5

si ve so değerleri sürekli sıfırdan farklıysa sistem aktif olarak takas yapıyor demektir; bu, fiziksel RAM'in yetersiz kaldığının en net göstergesidir. Tek seferlik bir sıçrama normal sayılır, sürekli hareket ciddi bir uyarıdır. vmstat çıktısındaki r sütunu da önemlidir. Bu sütun, çalışmaya hazır ama CPU bekleyen süreç sayısını gösterir; sayı çekirdek sayısını sürekli aşıyorsa CPU darboğazı var demektir.

Bir uygulamanın gerçekte ne kadar bellek tükettiğini görmek için ps ile RSS (Resident Set Size) değerine bakılır:

ps aux --sort=-%mem | head -10

Bu komut, sistemdeki en çok bellek tüketen 10 süreci listeler. Sızıntı şüphesi olan bir uygulamayı zaman içinde tekrar tekrar çalıştırıp RSS değerinin sürekli büyüyüp büyümediğini kontrol etmek, bellek sızıntısını doğrulamanın en pratik yoludur.

Disk darboğazını nasıl ayırt edersiniz?

Disk G/Ç sorunlarını yakalamak için iostat kullanılır; bu araç sysstat paketiyle birlikte gelir:

sudo apt install sysstat
iostat -xz 2

Çıktıdaki %util sütunu diskin ne kadar meşgul olduğunu, await sütunu ise bir G/Ç isteğinin ortalama ne kadar beklediğini milisaniye cinsinden gösterir. %util sürekli %90'ın üzerindeyse ve await 20 ms'yi geçiyorsa disk darboğaz oluşturuyor demektir. Özellikle dönen HDD'lerde bu değerler NVMe SSD'lere göre çok daha kolay tırmanır. NVMe bir diskte 5 ms'lik bir await bile şüpheli sayılabilirken, eski bir HDD'de 15-20 ms normal kabul edilir; referans değeri disk tipine göre değişir.

Hangi sürecin diski zorladığını bulmak için iotop aracı kullanılır:

sudo apt install iotop
sudo iotop -oPa

-o parametresi yalnızca aktif G/Ç yapan süreçleri, -a parametresi ise kümülatif toplamı gösterir. Bir log rotasyonu, bir yedekleme işi ya da kontrolsüz bir veritabanı sorgusu genelde burada yakalanır. iotop root yetkisi ister, çünkü çekirdeğin G/Ç muhasebe verisine erişir. Bazı konteyner ortamlarında bu erişim kısıtlı olabilir; o durumda pidstat -d alternatif bir yol sağlar.

Disk doluluğu ayrı bir kontrol gerektirir; df -h ile periyodik kontrol basit ama kritik bir alışkanlıktır. /var/log sürekli büyüyen bir dizindir; log rotasyonu yanlış yapılandırılmışsa disk aniden dolabilir ve bu da tüm sistemi durma noktasına getirebilir.

Hangi dizinin diski doldurduğunu bulmak için du komutu kullanılır:

du -sh /var/log/* | sort -rh | head -10

Bu komut /var/log altındaki alt dizinleri boyuta göre büyükten küçüğe sıralar; şişen bir dizin bu şekilde saniyeler içinde bulunur. Docker konteynerleri kullanan sistemlerde docker system df benzer bir özet sunar; kullanılmayan imajlar ve durdurulmuş konteynerler zamanla gigabaytlarca yer kaplayabilir.

sar ile geçmişe dönük analiz nasıl yapılır?

top ve iostat anlık durumu gösterir; sorun gece 3'te yaşandıysa geçmişe bakmak gerekir. sysstat paketi kurulduğunda sar, geçmiş verileri /var/log/sysstat altında otomatik olarak toplar.

sar -u -f /var/log/sysstat/sa15

Bu komut, ayın 15'ine ait CPU kullanım geçmişini 10 dakikalık aralıklarla listeler. sar -r bellek istatistiklerini, sar -d disk istatistiklerini, sar -n DEV ise ağ arabirimi istatistiklerini gösterir. Toplama sıklığı /etc/cron.d/sysstat dosyasından ayarlanır; varsayılan genelde 10 dakikadır, kritik sunucularda bunu 5 dakikaya indirmek olayları daha net yakalar.

Bir kesinti sonrası inceleme yaparken önce sar -u, sonra sar -r, sonra sar -d sırasıyla bakmak sistematik bir yöntemdir. Bu sıra önce hangi kaynağın anormal davrandığını bulmayı, ardından o kaynağa odaklanmayı sağlar. Rastgele araç değiştirmek yerine bu sırayı takip etmek zaman kazandırır.

Gereksiz servisleri kapatmak performansı nasıl etkiler?

Boşta duran her servis bellek ayırır ve zaman zaman CPU tüketir. Sistemde açılışta çalışan servisler şu komutla listelenir:

systemctl list-unit-files --type=service --state=enabled

İhtiyaç duyulmayan bir servisi (örneğin kullanılmayan bir yazdırma servisi ya da eski bir Bluetooth arka plan servisi) kapatmak için şu komut kullanılır:

sudo systemctl disable --now cups.service

Bir servisi kapatmadan önce ne işe yaradığından emin olmak gerekir; systemctl status <servis> komutu bu konuda hızlı bir fikir verir. Sunucularda genelde grafik arayüz bağımlılıkları (CUPS, Bluetooth, Avahi) hiç gerekmez ve güvenle kapatılabilir. Masaüstü sistemlerde ise bu servisler günlük kullanım için gereklidir; sunucu tavsiyelerini olduğu gibi masaüstüne uygulamak yanlış sonuç verir.

Süreç önceliklerini nice ve renice ile ayarlamak da işe yarar. CPU'yu çok kullanan ama acil olmayan bir arka plan işi (örneğin bir yedekleme betiği) düşük öncelikle çalıştırılabilir:

nice -n 15 ./yedekleme.sh
renice -n 10 -p 4821

Değer -20 ile 19 arasında değişir; düşük değer yüksek öncelik anlamına gelir. Sıradan kullanıcılar yalnızca kendi süreçlerini düşük öncelikli yapabilir, önceliği yükseltmek ise root yetkisi ister.

Kernel parametrelerinde ince ayar ne zaman gerekir?

Temel izleme ve servis temizliği yeterli gelmiyorsa sysctl ile çekirdek parametrelerine bakılır. vm.swappiness değeri, çekirdeğin ne kadar istekli takas yapacağını belirler; varsayılan genelde 60'tır.

cat /proc/sys/vm/swappiness
sudo sysctl vm.swappiness=10

Bol RAM'i olan bir veritabanı sunucusunda bu değeri düşürmek, çekirdeğin gereksiz yere takas yapmasını engeller. Kalıcı hâle getirmek için /etc/sysctl.conf dosyasına vm.swappiness=10 satırı eklenir ve ardından sudo sysctl -p çalıştırılır.

Ağ yoğun sunucularda net.core.somaxconn ve dosya tanıtıcı limiti (ulimit -n) de sık karşılaşılan darboğazlardır. Yüksek bağlantılı bir web sunucusu varsayılan 1024 dosya tanıtıcı limitine kolayca takılır:

ulimit -n
sudo sysctl fs.file-max=100000

Bu tür ayarlar tek tek, tek değişken değiştirilip sonuç ölçülerek yapılır. Aynı anda birden fazla parametre değiştirilirse hangisinin işe yaradığı anlaşılamaz. Değişiklik öncesi ve sonrası vmstat/sar çıktısını kaydedip karşılaştırmak, kararları varsayıma değil veriye dayandırır.

Performans izlemeyi düzenli bir alışkanlığa çevirmenin en pratik yolu, sar verilerini haftalık gözden geçirmektir. Kaynak kullanımı yavaş yavaş tırmanan bir eğilim fark edildiğinde, disk dolmadan ya da bellek tükenmeden önce müdahale edilebilir; bu, gece yarısı gelen bir kesinti uyarısından çok daha ucuza gelir. Çekirdek parametrelerine dokunmadan önce ilgili sysctl ayarlarının tam listesini ve varsayılan değerlerini resmi çekirdek dokümantasyonundan doğrulamak, kritik bir üretim sistemine güvenli müdahale için doğru bir referans sağlar.

Sonuçları nasıl kayıt altına almalısınız?

Ölçüm yapıp sonucu not almamak, aynı sorunun üç ay sonra sıfırdan araştırılması anlamına gelir. Kritik sunucularda basit bir alışkanlık işe yarar; her değişiklikten önce ve sonra vmstat 1 5 ve iostat -xz 1 5 çıktısı bir dosyaya kaydedilir.

{ date; vmstat 1 5; iostat -xz 1 5; } >> /var/log/perf-notlari.log

Bu küçük alışkanlık, "geçen ay bu ayarı değiştirmiştik, işe yaramış mıydı?" sorusuna dakikalar içinde cevap verir. Grafana ve Prometheus gibi araçlar bu işi otomatikleştirir ve uzun vadeli trend grafiği çizer; ama küçük bir sunucu filosunda sar ve düz metin loglar bile yeterince güçlü bir başlangıç noktasıdır. Önemli olan, ölçmeden ayar değiştirmemek ve her değişikliği bir öncekiyle karşılaştırabilmektir.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.