Windows Performance Toolkit ile Gelişmiş Performans Analizi

Üretim ortamında beklenmedik bir performans sorunu yaşandığında, klasik araçların yetersiz kaldığı anlar olur. Task Manager’a bakıyorsunuz, CPU %70’te, memory normale yakın, disk I/O makul görünüyor ama sistem yine de yavaş. İşte tam bu noktada Windows Performance Toolkit devreye girer. WPT, Microsoft’un kendi mühendislerinin Windows’u debug etmek için kullandığı araç setidir ve bu kadar güçlü bir şeyin üretim sorunlarında kullanılmaması gerçekten büyük bir kayıp.

Windows Performance Toolkit Nedir ve Neden Önemlidir

WPT, Windows Assessment and Deployment Kit (ADK) içinde gelen bir araç koleksiyonudur. İki temel bileşenden oluşur: Windows Performance Recorder (WPR) ve Windows Performance Analyzer (WPA). WPR, ETW (Event Tracing for Windows) altyapısını kullanarak sistem genelinde son derece düşük overhead ile veri toplar. WPA ise bu verileri görselleştirmek ve analiz etmek için kullanılır.

ETW mekanizması, Windows çekirdeğinin içine gömülü bir izleme altyapısıdır. CPU scheduling, disk I/O, network aktivitesi, memory allocation, lock contention, GC pause’ları… Bunların hepsini nanosaniye hassasiyetinde kayıt edebilirsiniz. Bu, perfmon’un ya da Process Monitor’ün yapabileceğinin çok ötesinde bir kapasitedir.

WPT’yi ADK’dan yükleyebilirsiniz ama sadece WPT bileşenini seçmek yeterli:

# ADK indirme sayfasindan adksetup.exe'yi indirin
# Kurulum sirasinda sadece "Windows Performance Toolkit" secenegini isaretleyin
# Varsayilan kurulum yolu:
C:Program Files (x86)Windows Kits10Windows Performance Toolkit

WPR ile Veri Toplama: Temel Kullanım

WPR’ı komut satırından kullanmak, GUI’ye göre çok daha esnektir ve otomasyon için şarttır. Temel bir kayıt şöyle başlatılır:

# Genel performans profili ile kayit baslat
wpr.exe -start GeneralProfile

# CPU analizi icin
wpr.exe -start CPU

# Disk I/O analizi icin
wpr.exe -start DiskIO

# Birden fazla profil ayni anda kullanilabilir
wpr.exe -start GeneralProfile -start DiskIO -start FileIO

# Kaydi durdur ve ETL dosyasina kaydet
wpr.exe -stop C:Tracesperformans_kaydi.etl

Burada dikkat edilmesi gereken bir nokta var: kayıt süresi uzadıkça ETL dosyası büyür. Üretim ortamında genellikle 2-5 dakikalık kayıtlar sorunları yakalamak için yeterlidir. Çok uzun kayıtlar hem disk doldurar hem de WPA’da analizi zorlaştırır.

Sorunun tam ne zaman olacağını bilmiyorsanız, boottracing ya da circular buffer modunu kullanabilirsiniz:

# 512 MB circular buffer ile kayit - sorun olunca durdurup son N dakikayi elde edersiniz
wpr.exe -start GeneralProfile -filemode memory -recordTempTo C:Traces 

# Boot trace - sistem baslarken yasanan sorunlar icin
wpr.exe -boottrace -addboot GeneralProfile
# Sistem yeniden baslatilir, sorun tetiklenir, sonra:
wpr.exe -boottrace -stopboot C:Tracesboot_trace.etl

Gerçek Dünya Senaryosu 1: Yüksek CPU Analizi

Bir web sunucusunda belirli saatlerde CPU’nun %90’ın üzerine çıktığını, ama nedenin anlaşılamadığını düşünelim. Perfmon’dan gördüğünüz şey CPU kullanımı, ama hangi process, hangi thread, hatta hangi fonksiyon çağrısı bunu yapıyor?

# CPU sampling profili ile kayit al
# Sorunun yasandigi saatte otomatik tetiklemek icin scheduled task kullanilabilir
wpr.exe -start CPU -start DiskIO

# 3 dakika bekle (ya da sorun tetiklenince)
Start-Sleep -Seconds 180

wpr.exe -stop C:Tracesyuksek_cpu_$(Get-Date -Format 'yyyyMMdd_HHmm').etl

Bu ETL dosyasını WPA’da açtığınızda, CPU Usage (Sampled) grafiğine bakın. Buradan process bazında CPU dağılımını görebilirsiniz. Daha da önemlisi, flame graph benzeri bir görünümde call stack’e inebilirsiniz. Örneğin IIS worker process’in %60 CPU kullandığını gördünüz; call stack’e inince bunun regex işlemlerinden kaynaklandığını, hatta hangi regex pattern’inin tetiklendiğini görebilirsiniz.

CPU Usage (Precise) görünümü ise context switch’leri takip eder. Thread’in ne zaman CPU’ya girip çıktığını, ne kadar beklediğini ve neden beklediğini (preemption, page fault, voluntary yield) gösterir. Bu, lock contention sorunlarını bulmak için altın değerindedir.

Gerçek Dünya Senaryosu 2: Disk I/O Gecikmesi

Bir SQL Server’da query’lerin zaman zaman çok yavaşladığını ama disk perfmon counter’larının normal göründüğünü varsayalım. Perfmon size average disk latency verir, ama WPT size her bir I/O isteğinin ne kadar sürdüğünü ayrı ayrı söyler.

# Storage stack analizi icin
wpr.exe -start DiskIO -start StorageIOSubsystem

# SQL Server yuku simule et ya da production yuku bekle
# Sonra trace'i durdur
wpr.exe -stop C:Tracessql_disk_analiz.etl

WPA’da Disk Usage grafiğini açtığınızda:

  • Hangi process’in disk I/O yaptığını
  • Read/Write dağılımını
  • Her I/O’nun service time’ını (queue time dahil)
  • Hangi dosyalara erişildiğini

görebilirsiniz. Bazen sorun SQL Server değildir, aynı LUN üzerindeki başka bir servis I/O’yu boğuyordur. WPT bu tür gizli rekabeti gün yüzüne çıkarır.

Özel Profil Dosyaları: WPRP Formatı

WPR’ın gerçek gücü özel profil dosyaları yazabilmenizde yatar. .wprp uzantılı XML dosyaları ile tam olarak hangi ETW provider’larından veri toplayacağınızı kontrol edebilirsiniz.

<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0">
  <Profiles>
    <EventCollector Id="EventCollector_Custom" Name="Custom Event Collector">
      <BufferSize Value="256"/>
      <Buffers Value="64"/>
    </EventCollector>

    <EventProvider Id="EventProvider_ASPNET" 
                   Name="AFF081FE-0247-4275-9C4E-021F3DC1DA35"
                   Level="5"/>

    <EventProvider Id="EventProvider_IIS" 
                   Name="DE4649C9-15E8-4FEA-9D85-1CDDA520364F"
                   Level="4"/>

    <Profile Id="CustomWebProfile.Verbose.File" 
             Name="CustomWebProfile" 
             Description="IIS ve ASP.NET analizi"
             DetailLevel="Verbose" 
             LoggingMode="File">
      <Collectors>
        <EventCollectorId Value="EventCollector_Custom">
          <EventProviderId Value="EventProvider_ASPNET"/>
          <EventProviderId Value="EventProvider_IIS"/>
        </EventCollectorId>
      </Collectors>
    </Profile>
  </Profiles>
</WindowsPerformanceRecorder>
# Ozel profil ile kayit
wpr.exe -start C:Profilescustom_web.wprp!CustomWebProfile.Verbose.File
wpr.exe -stop C:Tracesweb_trace.etl

Bu şekilde sadece ihtiyacınız olan provider’lardan veri toplayarak hem overhead’i düşürür hem de analizi kolaylaştırırsınız.

xperf: WPT’nin Komut Satırı Motoru

xperf.exe, WPR’ın altında çalışan düşük seviyeli araçtır ve bazı durumlarda doğrudan kullanmak daha fazla kontrol sağlar:

# Kernel ve kullanici modu olaylarini ayri ayri kaydet
xperf -on DiagEasy

# Yalnizca belirli kernel flag'leri ile
xperf -on PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PROFILE

# Kullanici modu provider ekle (ETW GUID ile)
xperf -on PROC_THREAD+LOADER -start UserSession -on "AFF081FE-0247-4275-9C4E-021F3DC1DA35":0x1:5

# Durdur ve birlestir
xperf -d C:Tracesxperf_kaydi.etl

# Merge islemi (kernel + user session ayri dosyalar olusturulduysa)
xperf -merge kernel.etl user.etl merged.etl

xperf ile aynı zamanda ETL dosyalarını metin formatına dönüştürebilirsiniz, bu da script tabanlı analiz için işe yarar:

# CSV formatina donustur
xperf -i C:Traceskayit.etl -o C:Traceskayit_cpu.csv -a cpudisk

# Summary raporu
xperf -i C:Traceskayit.etl -a stats

# Process bazli CPU raporu
xperf -i C:Traceskayit.etl -o C:Tracescpu_rapor.txt -a process

WPA ile Analiz: Kritik Görünümler

WPA’yı açtığınızda onlarca grafikle karşılaşırsınız. Hangi görünümlerin önemli olduğunu bilmek zaman kazandırır.

CPU Usage (Sampled): CPU’yu kim ne kadar kullanıyor, call stack analizi. İlk bakılacak yer.

CPU Usage (Precise): Thread scheduling analizi, bekleme nedenleri, context switch’ler.

Disk I/O: Storage gecikmesi ve throughput analizi.

Memory: Virtual memory, commit, hard fault analizi.

Generic Events: Özel ETW olayları, uygulama seviyesindeki izler.

WPA’da analiz profili kaydedebilirsiniz. Yani hangi panellerin açık olduğunu, hangi kolonların görünür olduğunu, hangi filtrelerin uygulandığını bir .wpaProfile dosyasına kaydedip ekip arkadaşlarınızla paylaşabilirsiniz. Bu, tutarlı analiz süreci için çok değerlidir.

Otomasyon: Sorun Anında Otomatik Trace Alma

Üretim ortamında en kritik ihtiyaç, sorun oluştuğu anda otomatik olarak trace başlatıp durdurmaktır. Bunu performans counter tetiklemesiyle yapabilirsiniz:

# CPU %85 asildiginda trace baslat, 2 dakika kaydet, durdur
$counterPath = 'Processor(_Total)% Processor Time'
$threshold = 85
$tracePath = "C:Tracesauto_$(Get-Date -Format 'yyyyMMdd_HHmm').etl"
$traceActive = $false

Write-Host "Izleme basliyor - CPU esigi: $threshold%"

while ($true) {
    $cpuValue = (Get-Counter $counterPath).CounterSamples[0].CookedValue
    
    if ($cpuValue -gt $threshold -and -not $traceActive) {
        Write-Host "$(Get-Date): CPU $([math]::Round($cpuValue,1))% - Trace baslatiliyor"
        & "C:Program Files (x86)Windows Kits10Windows Performance Toolkitwpr.exe" `
            -start CPU -start DiskIO
        $traceActive = $true
        $traceStartTime = Get-Date
    }
    
    if ($traceActive -and ((Get-Date) - $traceStartTime).TotalSeconds -ge 120) {
        Write-Host "$(Get-Date): Trace durduruluyor - $tracePath"
        & "C:Program Files (x86)Windows Kits10Windows Performance Toolkitwpr.exe" `
            -stop $tracePath
        $traceActive = $false
        Write-Host "Trace kaydedildi: $tracePath"
        break
    }
    
    Start-Sleep -Seconds 5
}

Bu script’i Scheduled Task olarak çalıştırabilir ya da monitoring sisteminizden bir webhook ile tetikleyebilirsiniz. Gerçek dünyada bu tür otomasyonlar, sorunun tam anında alınan veriyi yakalamak için hayat kurtarıcıdır.

Sembol Çözümleme: Call Stack’i Anlamlı Hale Getirmek

WPA’da call stack’e baktığınızda fonksiyon isimleri yerine hex adresler görüyorsanız, sembol konfigürasyonu eksiktir. Semboller olmadan analiz yarım kalır.

# Ortam degiskeni olarak sembol yolu ayarla
# _NT_SYMBOL_PATH degiskeni WPA tarafindan kullanilir

# Microsoft public sembol sunucusu + lokal cache
setx _NT_SYMBOL_PATH "srv*C:Symbols*https://msdl.microsoft.com/download/symbols" /M

# Kendi uygulamanizin PDB dosyalari varsa ekleyin
setx _NT_SYMBOL_PATH "srv*C:Symbols*https://msdl.microsoft.com/download/symbols;C:MyAppSymbols" /M

WPA’yı başlattıktan sonra Trace > Load Symbols menüsünden sembol yüklemeyi tetikleyin. İlk yükleme internet bağlantısı gerektirdiğinden yavaş olabilir; sonraki seferler lokal cache’den hızlı gelir.

Üretim sunucularında internet erişimi genellikle kısıtlıdır. Bu durumda sembol dosyalarını geliştirme makinenizde indirip sunucuya kopyalayabilir ya da trace’i analiz makinenize taşıyabilirsiniz. ETL dosyaları farklı makinelerde de açılabilir, trace’i almak için hedef makineye ihtiyacınız var ama analiz için gerek yok.

.NET Uygulamalarında CLR Olayları

.NET çalışan sistemlerde WPT’nin CLR ETW provider’ı ile çok değerli bilgiler elde edebilirsiniz:

# .NET CLR olaylari dahil kapsamli trace
wpr.exe -start CPU -start DotNet -start DiskIO

# Ya da xperf ile manuel CLR provider ekleme
# Microsoft-Windows-DotNETRuntime provider GUID: e13c0d23-ccbc-4e12-931b-d9cc2eee27e4
xperf -on PROC_THREAD+LOADER+PROFILE -start clrsession ^
      -on "e13c0d23-ccbc-4e12-931b-d9cc2eee27e4":0x98:5

# Durdur
xperf -stop -stop clrsession merged.etl

Bu yapılandırmayla GC pause sürelerini, JIT compilation overhead’ini, exception frequency’sini ve finalization queue doluluk durumunu görebilirsiniz. Bir .NET uygulaması yavaşlıyorsa ve GC pause’larının saniyeler sürdüğünü WPA’da gördüyseniz, artık doğru soruyu sormaya başlıyorsunuz demektir.

Performans Karşılaştırma: Baseline Alma Alışkanlığı

WPT’nin uzun vadede en büyük değeri, baseline almak ve karşılaştırma yapmaktır. Her büyük güncelleme öncesi ve sonrası, her yapılandırma değişikliği öncesi ve sonrası trace alın.

# Baseline trace alma scripti - cron job ya da maintenance window'da calistirilir
$baselineDir = "C:TracesBaselines"
$date = Get-Date -Format 'yyyyMMdd'
$server = $env:COMPUTERNAME
$wpr = "C:Program Files (x86)Windows Kits10Windows Performance Toolkitwpr.exe"

# Onceki aktif trace varsa temizle
& $wpr -cancel 2>$null

# 3 dakika genel profil kaydi
& $wpr -start GeneralProfile -start DiskIO
Write-Host "Baseline trace baslatildi: $server - $date"

Start-Sleep -Seconds 180

$outputFile = "$baselineDir${server}_${date}_baseline.etl"
& $wpr -stop $outputFile
Write-Host "Baseline kaydedildi: $outputFile"

# Dosya boyutunu logla
$size = [math]::Round((Get-Item $outputFile).Length / 1MB, 1)
Write-Host "Dosya boyutu: ${size} MB"

Birkaç ay sonra bir performans şikayeti geldiğinde, eski baseline ile yeni trace’i karşılaştırmak size değişimin ne zaman başladığını ve neyin değiştiğini gösterir. Bu, troubleshooting süresini ciddi oranda kısaltır.

Dikkat Edilmesi Gereken Noktalar

WPT güçlü bir araçtır ama dikkatli kullanılması gerekir:

Disk alanı takibi: ETL dosyaları büyük olabilir. Uzun süreli trace’lerde 10 GB’ı aşması nadir değildir. Trace başlatmadan önce yeterli boş alan olduğundan emin olun ve trace’leri analiz sonrası arşivleyin ya da silin.

Buffer overrun: Çok yoğun sistemlerde ETW buffer’ları dolabilir ve olaylar kaybolabilir. WPR çıktısında “events lost” uyarısı görürseniz buffer boyutunu artırın ya da daha az provider kullanın.

Production’da call stack kayıt overhead’i: CPU sampling genellikle %1-2 overhead yapar, bu kabul edilebilir. Ama her event’te stack walk yapan konfigürasyonlar %5-10’a çıkabilir. Kritik sistemlerde kısa tutun.

Sembol sunucusu bağlantısı: Analiz makinenizin internet erişimi yoksa semboller yüklenemez. Bunu önceden test edin.

Sonuç

Windows Performance Toolkit, sysadmin toolbox’ının en güçlü ama en az kullanılan araçlarından biridir. Task Manager ve perfmon sorunun var olduğunu söyler; WPT ise neden var olduğunu söyler. Bu fark, saatlerce süren troubleshooting ile dakikalar içinde kök neden tespiti arasındaki farkı belirler.

Başlamak için karmaşık senaryoları beklemeyin. Sisteminiz şu an sağlıklı görünüyorken bir baseline trace alın, WPA’da açın ve gezinin. Hangi process’lerin ne yaptığını, disk I/O pattern’lerini, memory kullanımını anlayın. Bu alışkanlık, sorun çıktığında neyin değiştiğini anlamayı çok kolaylaştırır.

WPT öğrenmek bir yatırımdır. İlk birkaç kullanım zaman alır, WPA arayüzü kalabalık görünür, call stack analizi kafa karıştırıcı olabilir. Ama bir kez iş akışınıza oturduktan sonra, daha önce çözülmesi saatler alan sorunları dakikalar içinde kapatmaya başlarsınız. Ve o noktada, nasıl bu araçsız çalıştığınızı merak edersiniz.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir