pidstat ile Süreç Bazlı CPU, Bellek ve Disk Kullanımını Gerçek Zamanlı İzleme

Üretim ortamında bir Java uygulaması neden bu kadar yavaş çalışıyor diye saatlerce top ile baktım, hiçbir şey bulamadım. Sonunda pidstat açtım ve sorun dakikalar içinde ortaya çıktı: uygulama her 30 saniyede bir kısa ama yoğun disk yazma operasyonu yapıyordu, bunu top hiç göstermemişti. İşte o günden beri pidstat benim için vazgeçilmez bir araç oldu.

pidstat, sysstat paketinin içinde gelen ve süreç bazlı kaynak kullanımını gerçek zamanlı olarak izlemenizi sağlayan bir komut satırı aracıdır. top ve htop size sistem genelinde bir görünüm sunarken, pidstat tek bir süreci ya da belirli bir gruba ait süreçleri mikroskop altına almanızı sağlar. CPU, bellek, disk I/O ve bağlam değiştirme istatistiklerini ayrı ayrı inceleyebilirsiniz. Bu özelliği onu performans sorunlarının kök nedenini bulmak için mükemmel bir araç yapıyor.

Kurulum ve Temel Kullanım

Çoğu dağıtımda pidstat, sysstat paketiyle birlikte gelir. Sistemde kurulu değilse:

# Debian/Ubuntu
sudo apt install sysstat

# RHEL/CentOS/AlmaLinux
sudo dnf install sysstat

# Arch Linux
sudo pacman -S sysstat

Kurulumdan sonra en basit kullanım şekli şudur:

pidstat 2

Bu komut, 2 saniyede bir tüm aktif süreçlerin CPU kullanımını gösterir. Çıktıyı durdurmak için Ctrl+C kullanabilirsiniz. Belirli sayıda ölçüm almak için ikinci bir sayı ekleyebilirsiniz:

pidstat 2 10

Bu komut 2 saniyede bir, toplam 10 kez ölçüm alır ve durur. Otomasyon ve raporlama senaryolarında çok işe yarar.

Temel Parametreler

pidstat‘ın gücü, farklı parametrelerle farklı kaynak türlerini izleyebilmesinden gelir.

-u: CPU kullanım istatistikleri (varsayılan mod) -r: Bellek kullanım istatistikleri -d: Disk I/O istatistikleri -w: Bağlam değiştirme (context switch) istatistikleri -p: Belirli bir PID’i izle (-p ALL ile tüm süreçler) -C: Süreç adına göre filtrele (regex destekler) -t: Thread bazlı istatistikler göster -l: Komutun tam yolunu ve argümanlarını göster -h: Tek satır başlıklı çıktı (script’ler için kullanışlı) -T: Hem süreç hem thread istatistiklerini göster (TASK, CHILD, veya ALL) -G: Komut adına göre filtrele (tam eşleşme değil, içerik arar)

CPU İzleme: Hangi Süreç Ne Kadar Yer Yiyor

CPU kullanımı izlemenin en temel senaryosu, hangi sürecin sistemin işlemcisini tükettiğini bulmaktır.

pidstat -u 1 5

Çıktıda şu sütunları görürsünüz:

• UID: Süreci çalıştıran kullanıcının ID’si
• PID: Süreç ID’si
• %usr: Kullanıcı modunda harcanan CPU yüzdesi
• %system: Kernel modunda harcanan CPU yüzdesi
• %guest: Sanal CPU’da harcanan süre (sanallaştırma ortamlarında anlamlı)
• %CPU: Toplam CPU kullanımı
• CPU: Süreci çalıştıran çekirdek numarası
• Command: Komut adı

Burada dikkat edilmesi gereken nokta: %CPU değeri, çok çekirdekli sistemlerde 100’ü aşabilir. 4 çekirdekli sistemde maksimum değer 400’dür. Bu, top‘tan farklı bir davranıştır; top varsayılan olarak toplam kapasiteye böler.

Gerçek bir senaryo: Bir müşterimizin Nginx sunucusunda belirli saatlerde CPU spike’ları yaşanıyordu. Şöyle bir komut çalıştırdım:

pidstat -u -C "nginx" 2 30

Bu komut, adında “nginx” geçen tüm süreçlerin CPU kullanımını 2 saniyede bir, 30 ölçüm boyunca takip etti. Worker process’lerden birinin düzenli aralıklarla yüzde 90’a çıktığını ve hemen düştüğünü gördüm. Upstream bağlantılar zaman aşımına uğruyordu ve yeniden deneme mekanizması CPU spike’larına neden oluyordu.

Bellek İzleme: RSS, VSZ ve Bellek Sızıntıları

Bellek sorunları, özellikle uzun süre çalışan süreçlerde sinsi bir şekilde birikir. pidstat -r size bunu net olarak gösterir.

pidstat -r -p 1234 3

Bellek modunda göreceğiniz sütunlar:

• minflt/s: Saniyedeki küçük sayfa hatası sayısı (fiziksel bellek gerektirmeyen)
• majflt/s: Saniyedeki büyük sayfa hatası sayısı (diskten okuma gerektiren, kritik!)
• VSZ: Sanal bellek boyutu (KB)
• RSS: Fiziksel belleğe yüklenmiş gerçek boyut (KB)
• %MEM: Toplam RAM’in yüzde kaçının kullanıldığı
• Command: Komut adı

majflt/s değeri yüksekse bu çok ciddi bir uyarı işaretidir. Süreç sürekli diskten veri okuyorsa, bu ya bellek yetersizliğinden ya da uygulama seviyesindeki bir sorundan kaynaklanıyor demektir.

Bellek sızıntısını yakalamak için şöyle bir yaklaşım kullanabilirsiniz:

pidstat -r -p $(pgrep -f "java -jar myapp") 60

Bu komutu çalıştırın ve RSS değerinin saatler içinde sürekli artıp artmadığını gözlemleyin. Gerçek bir bellek sızıntısında RSS değeri hiç düşmez, yalnızca artar. VSZ’nin artması tek başına alarm gerektirmez; ama RSS’in sürekli yükselmesi kesinlikle müdahale gerektirir.

# Birden fazla süreci aynı anda izlemek
pidstat -r -p 1234,5678,9012 5

Disk I/O İzleme: Gizli Darboğazları Bulmak

Bu benim en çok kullandığım mod. Disk I/O sorunları genellikle en zor teşhis edilen performans sorunlarıdır çünkü kısa sürelidir ve sistem geneli araçlar bunları yakalamakta zorlanır.

pidstat -d 2

I/O modundaki sütunlar:

• kB_rd/s: Saniyede okunan kilobayt
• kB_wr/s: Saniyede yazılan kilobayt
• kB_ccwr/s: İptal edilen yazma işlemleri (uygulama yazmadan önce bellek temizlendiyse)
• iodelay: I/O için bekleme süresinde geçirilen saat döngüsü sayısı

Gerçek dünya senaryosu: Bir PostgreSQL sunucusunda anlık yavaşlamalar yaşanıyordu. iostat genel disk kullanımını gösteriyordu ama hangi sürecin sorun yarattığı belirsizdi.

pidstat -d -p ALL 1 | grep -v "^$" | grep -v "Average"

Bu çıktıda PostgreSQL’in checkpointer süreci her 5 dakikada bir devasa bir yazma operasyonu yapıyordu. checkpoint_completion_target ve checkpoint_timeout parametrelerini düzenleyince sorun çözüldü. pidstat olmadan bunu bulmak çok daha uzun sürerdi.

Özellikle MySQL veya PostgreSQL gibi veritabanı sunucularında şu komutu çok kullanırım:

pidstat -d -C "postgres|mysql|mysqld" 5

Thread Bazlı İzleme: Çok Kanallı Uygulamaların Analizi

Java, .NET veya Go gibi çok thread kullanan uygulamalarda sorunun hangi thread’den kaynaklandığını bulmak kritik önem taşır.

pidstat -t -p 4567 2

-t parametresi ile thread bazlı istatistiklere erişirsiniz. Çıktıda TGID (Thread Group ID, yani asıl PID) ve TID (Thread ID) ayrı satırlarda gösterilir. TID değerinin TGID’den farklı olduğu satırlar bireysel thread’leri temsil eder.

Bir Spring Boot uygulamasında şöyle bir durum yaşadım: Uygulama genel olarak normal görünüyordu ama belirli API endpoint’leri çok yavaş yanıt veriyordu. Thread bazlı izleme şunu ortaya koydu:

pidstat -t -u -p $(pgrep -f "spring-boot") 1

Belirli bir thread grubu (Tomcat worker thread’leri) sürekli yüksek CPU tüketiyordu. Thread dump analizi ile birleştirince bir N+1 query sorunu olduğunu ve her istek için yüzlerce veritabanı sorgusu yapıldığını gördük.

Bağlam Değiştirme İzleme

Yüksek bağlam değiştirme sayısı, uygulamanın sürekli scheduler ile savaştığını gösterir ve ciddi performans sorunlarına yol açabilir.

pidstat -w -p 8080 2

Bu komutun çıktısındaki sütunlar:

• cswch/s: Saniyedeki gönüllü bağlam değiştirme sayısı (süreç I/O beklerken)
• nvcswch/s: Saniyedeki gönüllüsüz bağlam değiştirme sayısı (scheduler tarafından zorla alındığında)

nvcswch/s değerinin yüksek olması, sürece yeterli CPU verilmediğine veya sürecin çok fazla CPU almaya çalışıp sürekli kesintiye uğradığına işaret eder. Yüksek cswch/s ise I/O yoğun uygulamalarda normaldir; süreç işini bitirip beklediği için CPU’yu bırakıyor demektir.

Birden Fazla Metriği Aynı Anda İzlemek

Gerçek performans analizi yapılırken tek bir metriğe bakmak yanıltıcı olabilir. pidstat birden fazla parametreyi aynı anda destekler:

pidstat -u -r -d -w -p 3456 5

Bu komut, PID 3456 için CPU, bellek, disk I/O ve bağlam değiştirme istatistiklerini aynı anda 5 saniyelik aralıklarla gösterir. Kapsamlı bir performans profili çıkarmak için ideal.

Tüm süreçler için kapsamlı izleme:

pidstat -u -r -d 3 -p ALL 2>/dev/null | tee /tmp/pidstat_report_$(date +%Y%m%d_%H%M%S).txt

Bu komut çıktıyı hem ekrana yansıtır hem de zaman damgalı bir dosyaya kaydeder. Bir sorun yaşandığında elinizde geçmişe dönük veri bulunur.

Script ile Otomatik İzleme ve Alarm

pidstat‘ı bir bash script içinde kullanarak belirli eşik değerlerinde alarm üretebilirsiniz. Küçük ama etkili bir örnek:

#!/bin/bash
# Yüksek CPU kullanan süreçleri tespit et ve logla

THRESHOLD=80
LOG_FILE="/var/log/high_cpu_processes.log"
DURATION=60
INTERVAL=5

echo "$(date): CPU izleme başladı (Eşik: %${THRESHOLD})" >> "$LOG_FILE"

pidstat -u "$INTERVAL" $((DURATION / INTERVAL)) | 
awk -v threshold="$THRESHOLD" '
  /^[0-9]/ {
    if ($8 > threshold) {
      print strftime("%Y-%m-%d %H:%M:%S"), "UYARI:", $9, "PID:", $4, "CPU:", $8"%"
    }
  }
' >> "$LOG_FILE"

echo "$(date): İzleme tamamlandı" >> "$LOG_FILE"

Bu script’i cron ile çalıştırabilirsiniz. Özellikle gece yoğun batch işlemleri olan sistemlerde sabah işe geldiğinizde ne olup bittiğini anlamak için altın değerinde.

Canlı Sorun Giderme Senaryosu: Yüksek Load Average

Sistem load’u yüksek ama top ile bakınca belirgin bir suçlu göremiyorsunuz. Bu klasik bir durum. Şöyle bir yaklaşım işe yarar:

# Önce D state (disk bekleme) süreçlerine bakın
pidstat -d 1 10 | sort -k4 -rn | head -20

# Ardından yüksek bağlam değiştirme yapan süreçleri bulun
pidstat -w 1 5 | sort -k6 -rn | head -10

# Son olarak majör sayfa hatası üreten süreçleri kontrol edin
pidstat -r 1 5 | awk '$4 > 0 {print}' | sort -k4 -rn

Bu üç komut ardışık olarak çalıştırıldığında yüksek load’un kaynağını neredeyse her zaman tespit edebilirsiniz. CPU’ya değil, I/O veya bellek baskısına işaret eden sorunlar bu şekilde gün yüzüne çıkar.

pidstat ile sar Entegrasyonu

sysstat paketinin bir parçası olan pidstat, sar komutuyla entegre çalışabilir. sar tarihsel veri tutarken pidstat anlık ve kısa süreli analizler için idealdir. İkisini birlikte kullanmak, hem anlık hem de trend bazlı bir görünüm sağlar.

# sysstat servisini etkinleştirirseniz, pidstat çıktısını binary formatında saklayabilirsiniz
# Daha sonra bu veriyi okumak için:
sar -P ALL -f /var/log/sysstat/sa$(date +%d)

Ancak pidstat‘ın asıl gücü süreç bazlı veri toplamasıdır; sar sistem geneli trende odaklanır. Birbirini tamamlayan araçlardır, birinin yerine diğerini geçirmeye çalışmamalısınız.

Yaygın Hatalar ve İpuçları

Deneyimsiz kullanıcıların pidstat kullanırken yaptığı birkaç yaygın hata:

İlk satırı yanlış yorumlamak: pidstat‘ın ilk çıktı satırı, sistem başladığından bu yana olan ortalamayı gösterir. Gerçek zamanlı değerleri görmek için ikinci satırdan itibaren okuyun.

%CPU değerini yanlış anlamak: Daha önce belirttiğim gibi, çok çekirdekli sistemlerde 100’ü aşabilir. Bu bir hata değil, tasarım tercihidir. htop ve top‘un varsayılan davranışından farklıdır.

Kısa aralık kullanmak: pidstat 1 çok kısa aralıklarla ölçüm yapar ve pidstat‘ın kendisi de CPU kullanmaya başlar. Uzun süreli izlemede 5 veya 10 saniyelik aralıklar daha sağlıklı sonuç verir.

PID yokluğunda hata almak: Script içinde kullanırken, izlediğiniz süreç ölürse pidstat hata verir. || true ekleyerek veya pgrep ile sürecin varlığını kontrol ederek bu durumu yönetin.

Sonuç

pidstat, sistem yöneticisinin ve DevOps mühendisinin araç kutusunda mutlaka bulunması gereken bir araçtır. Özellikle top ve htop gibi araçların yüzeysel kaldığı durumlarda, yani belirli bir sürecin davranışını derinlemesine anlamak gerektiğinde, pidstat‘ın sunduğu ayrıntı düzeyi paha biçilmezdir.

CPU izlemenin ötesinde, disk I/O ve bellek analizindeki yetenekleri onu gerçek anlamda kapsamlı bir performans tanılama aracına dönüştürür. Üretim ortamında yaşanan yavaşlamaların büyük çoğunluğunun kök nedeni ya disk I/O darboğazı, ya bellek baskısı ya da verimsiz bir uygulamanın CPU’yu gereksiz yere tüketmesidir. pidstat bu üç kategorinin tamamını karşılar.

Bir dahaki sefere “bu sunucu neden yavaş” sorusuyla karşılaştığınızda, pidstat‘ı açın ve birkaç dakika izleyin. Büyük olasılıkla sorunun kaynağını bulmak için başka bir araca ihtiyaç duymayacaksınız.