Windows Task Manager ile Kaynak Kullanım Analizi

Yazar:komut.io ekibi Windows Sunucu İzleme ve Performans Yönetimi
0 Yorum

Üretim ortamında bir sunucunun aniden yavaşladığını fark ettiğinizde, ilk refleks genellikle Task Manager’ı açmak olur. Yıllar içinde öğrendim ki bu araç, çoğu kişinin sandığından çok daha derin bilgiler sunuyor. Süreç listesine bakıp CPU çubuğunu izlemekten ibaret değil. Doğru sekmede, doğru metriği, doğru zamanda okuyabilmek; bir performans krizini 10 dakikada çözmek ile saatlerce debug yapmak arasındaki fark olabilir. Bu yazıda Windows Task Manager’ı gerçek bir analiz aracı olarak nasıl kullandığımı, hangi metriklerin ne anlama geldiğini ve pratikte işe yarayan teknikleri aktarmaya çalışacağım.

Task Manager’ı Doğru Açmak

Kulağa basit geliyor ama Ctrl+Shift+Esc kısayolu bilmek önemli. Neden? Çünkü Ctrl+Alt+Delete ekranından Task Manager’a geçmek, yüksek yük altındaki sistemlerde bazen dakikalar sürebilir. Özellikle GUI yanıt vermiyorken doğrudan Ctrl+Shift+Esc çok daha hızlı açılır.

Bir diğer kritik nokta: Task Manager’ı yönetici olarak çalıştırmak. Yönetici olmadan açarsanız bazı sistem süreçlerinin kaynak kullanımını göremez, bazı işlemleri sonlandıramazsınız.

# PowerShell üzerinden Task Manager'ı yönetici yetkileriyle başlatmak
Start-Process taskmgr -Verb RunAs

Uzak sunucularda çalışırken, RDP bağlantısı üzerinden Task Manager açmak yerine bazen komut satırı tercih etmek daha stabil bir deneyim sunar. Özellikle sunucu CPU kullanımı %95 üzerindeyken RDP’nin kendisi bile gecikme yaşıyorsa:

# Uzak sunucuda anlık süreç listesini almak için
query process /server:SUNUCU_ADI

# Ya da PowerShell Remoting ile
Invoke-Command -ComputerName SUNUCU_ADI -ScriptBlock { Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 }

Processes Sekmesi: Görünenin Arkası

İlk sekme olan Processes, en çok vakit geçirilen yer ama genellikle yüzeysel kullanılıyor. Kolon seçimine dikkat etmek gerekiyor. Sağ tıklayıp kolon ekleyebilirsiniz; pek çok kişi bunu bilmiyor.

Eklenmeye değer kolonlar:

  • PID (Process ID): Sürecin benzersiz kimliği. Log dosyalarındaki PID ile eşleştirmek için şart.
  • Status: Running, Suspended, Not Responding gibi durumlar. Askıda kalan bir sürecin “Not Responding” yazmasını beklemek yerine bu kolonu ekleyip filtreleyebilirsiniz.
  • Publisher: Sürecin yayıncısı. İmzasız veya tanımadığınız bir yayıncıdan gelen süreç varsa dikkat.
  • Command line: Hangi argümanlarla başlatıldığını gösterir. Özellikle birden fazla aynı isimli süreç varken hangisinin hangisi olduğunu anlamak için kritik.
# PowerShell ile tüm süreçlerin komut satırı argümanlarını görmek
Get-WmiObject Win32_Process | Select-Object Name, ProcessId, CommandLine | Format-List

Gerçek dünya senaryosu: Bir gün production IIS sunucusunda w3wp.exe süreçlerinden biri sürekli %30 CPU yiyor, diğerleri normal seyrediyordu. Task Manager’da PID’leri not alıp hangi uygulama havuzuna ait olduğunu bulmak için şunu kullandım:

# IIS uygulama havuzu ve PID eşleştirmesi
C:WindowsSystem32inetsrvappcmd.exe list wp

# Alternatif PowerShell yolu
Import-Module WebAdministration
Get-WebConfiguration system.applicationHost/sites/site/application/virtualDirectory | 
  Select-Object -ExpandProperty physicalPath

Bu sayede sorunlu w3wp.exe‘nin hangi uygulama havuzuna ait olduğunu buldum ve o havuzun loglarına yöneldim.

Performance Sekmesi: Sayıların Gerçek Anlamı

Bu sekme çok yanlış yorumlanıyor. Birkaç kritik noktayı netleştirmek istiyorum.

CPU Analizi

CPU grafiğinde tek bir çubuk yerine “Logical processors” görünümüne geçin. Tüm core’ların yükünü tek tek görmek, bazı problemleri hemen gün yüzüne çıkarır. Eğer 16 core’lu bir sunucuda toplam CPU %15 gösteriyor ama tek bir core %100 dolarken diğerleri boştaysa, bu single-threaded bir bottleneck anlamına gelir. Toplam ortalamaya bakarak bunu kaçırırsınız.

Sağ tıklayıp “Change graph to > Logical processors” seçeneğiyle bu görünüme geçebilirsiniz.

# PowerShell ile her core'un anlık kullanımını almak
$cores = Get-WmiObject -Class Win32_PerfFormattedData_PerfOS_Processor | 
  Where-Object { $_.Name -ne "_Total" }
$cores | Select-Object Name, PercentProcessorTime | Sort-Object PercentProcessorTime -Descending

Memory Analizi

RAM bölümünde dikkat edilmesi gereken değerler:

  • In Use: Şu an kullanılan bellek miktarı
  • Available: Hemen kullanılabilir boş bellek
  • Committed: Commit edilmiş toplam sanal bellek
  • Cached: Disk cache olarak ayrılmış alan (bu “kullanımda” sayılır ama gerektiğinde boşalır)
  • Paged pool / Non-paged pool: Kernel tarafında kullanılan bellek

Çok önemli bir nokta: Windows’ta “Available” değeri sıfıra yakınsa ve disk aktivitesi yüksekse, sistem swap kullanıyordur. Bu durumda RAM artırmak ya da memory leak olan süreci bulmak gerekir.

# Memory istatistiklerini detaylı almak
Get-WmiObject -Class Win32_OperatingSystem | 
  Select-Object @{N="Total RAM (GB)"; E={[math]::Round($_.TotalVisibleMemorySize/1MB, 2)}},
                @{N="Free RAM (GB)"; E={[math]::Round($_.FreePhysicalMemory/1MB, 2)}},
                @{N="Used RAM (GB)"; E={[math]::Round(($_.TotalVisibleMemorySize - $_.FreePhysicalMemory)/1MB, 2)}}

Disk I/O Analizi

Performance sekmesindeki Disk bölümü, yavaş performansın diskten mi kaynaklandığını anlamak için kullanılır. Burada dikkat edilmesi gereken iki metrik:

  • Active time (%): Diskin ne kadarının meşgul olduğu. %100’e yakınsa disk bottleneck var demektir.
  • Average response time: Milisaniye cinsinden. SSD için 1ms altı normal, HDD için 5-10ms kabul edilebilir. 20ms üzeri sorun işareti.
# Disk I/O istatistiklerini PowerShell ile izlemek
Get-Counter 'PhysicalDisk(*)% Disk Time' -SampleInterval 2 -MaxSamples 5

# Daha detaylı I/O analizi
Get-Counter @(
  'PhysicalDisk(*)Avg. Disk sec/Read',
  'PhysicalDisk(*)Avg. Disk sec/Write',
  'PhysicalDisk(*)Disk Reads/sec',
  'PhysicalDisk(*)Disk Writes/sec'
) | Select-Object -ExpandProperty CounterSamples | 
  Format-Table Path, CookedValue -AutoSize

Network Analizi

Network bölümü, hangi adaptör üzerinden ne kadar trafik geçtiğini gösterir. Özellikle NIC teaming yapılmış ortamlarda her adaptörü ayrı ayrı izlemek önemli. Ancak Task Manager’ın network bölümü biraz kısıtlı. Hangi sürecin ne kadar network kullandığını görmek için Resource Monitor’a geçmek gerekiyor.

Resource Monitor: Task Manager’ın Güçlü Kardeşi

Task Manager’ın Performance sekmesinin en altındaki “Open Resource Monitor” linki, çok daha detaylı analiz imkanı sunar. Bunu birçok sysadmin es geçiyor.

CPU Sekmesinde Süreç Bazlı Analiz

Resource Monitor’da CPU sekmesinde bir süreci seçtiğinizde, o sürecin ilişkili olduğu tüm diğer süreçleri ve dosya tutamaçlarını görürsünüz. Bu, dependency sorunlarını çözmekte inanılmaz işe yarıyor.

Disk Sekmesinde Hangi Dosya Okunuyor/Yazılıyor

Bu özellik altın değerinde. Disk I/O yüksek olduğunda hangi süreci hangi dosyanın meşgul ettiğini gerçek zamanlı görebilirsiniz. Örneğin bir SQL Server sunucusunda tempdb’nin aşırı yazılıp okunduğunu Resource Monitor sayesinde 2 dakikada tespit ettim. Task Manager’da “Disk %100” görüp saatlerce aramak yerine.

# Resource Monitor'u doğrudan açmak
Start-Process perfmon -ArgumentList "/res"

# Ya da komutla
resmon.exe

Network Sekmesinde Bağlantı Takibi

Hangi sürecin hangi IP adresine bağlandığını görmek için Network sekmesi kullanılabilir. Güvenlik açısından da değerli. Tanımadığınız bir sürecin dış IP’ye bağlandığını burada yakalamanız mümkün.

# Aktif network bağlantılarını süreç bazında görmek
netstat -b -o | Select-String -Pattern "ESTABLISHED" | head -20

# PowerShell ile daha okunabilir format
Get-NetTCPConnection -State Established | 
  Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, 
                @{N="Process"; E={(Get-Process -Id $_.OwningProcess).Name}} |
  Sort-Object RemoteAddress

Gerçek Senaryo: Memory Leak Tespiti

Birkaç ay önce bir müşteri sunucusunda her 3 günde bir yeniden başlatma yapılıyordu. Klasik memory leak semptomu. Task Manager ile nasıl tespit ettim anlayayım.

Önce Processes sekmesinde “Memory” kolonuna göre sıraladım ve süreçlerin başlangıçtan bu yana memory tüketimini izledim. Ama daha sistematik yapmak için şunu kurdum:

# Belirli aralıklarla süreç memory kullanımını loglayan script
$logFile = "C:Logsmemory_monitor.csv"
$processName = "IIS_Sureci"

while ($true) {
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $proc = Get-Process -Name $processName -ErrorAction SilentlyContinue
    
    if ($proc) {
        $memMB = [math]::Round($proc.WorkingSet64 / 1MB, 2)
        "$timestamp,$($proc.Id),$memMB" | Add-Content $logFile
    }
    
    Start-Sleep -Seconds 300  # Her 5 dakikada bir
}

Bu script 24 saat çalıştıktan sonra CSV’yi Excel’de açtım ve belleğin sürekli artıp hiç düşmediğini gördüm. Klasik leak. Sorun uygulama kodunda bir disposal eksikliğiydi, geliştirici ekibi düzeltti.

Details Sekmesi: İleri Düzey Kullanım

Bu sekme Task Manager’ın en teknik bölümü. Burada süreç bazında pek çok parametre görülebilir.

Sağ tıklayıp “Set affinity” ile bir süreci belirli CPU core’larına kısıtlayabilirsiniz. Özellikle test ortamlarında ya da lisanslı yazılımların core bazlı lisanslamalarında işe yarar.

“Set priority” ile süreç önceliğini değiştirebilirsiniz. Ancak dikkatli olun: sistem süreçlerinin önceliğini düşürmek ya da gereksiz bir süreci “Realtime” yapmak sistemi bozabilir.

# PowerShell ile süreç önceliği değiştirmek
$process = Get-Process -Name "uygulama_adi"
$process.PriorityClass = [System.Diagnostics.ProcessPriorityClass]::BelowNormal

# CPU affinity ayarlamak (örnek: sadece core 0 ve 1 kullan)
$process.ProcessorAffinity = 3  # Binary: 0000 0011 = core 0 ve 1

Services Sekmesi ve Süreç İlişkisi

Task Manager’ın Services sekmesi, çalışan Windows servislerini listeler. Önemli bir özellik: bir servise sağ tıklayıp “Go to details” seçeneğiyle o servisin host ettiği svchost.exe sürecine gidebilirsiniz. Bu, svchost.exe süreçlerinden hangisinin sorun çıkardığını bulmak için kritik.

Windows 10 ve Server 2016 sonrasında Microsoft, her servisi ayrı bir svchost.exe altında çalıştırmaya başladı (yeterli RAM varsa). Bu hem debug’ı kolaylaştırdı hem de bir servis crash olduğunda diğerlerini etkilemiyor.

# Hangi svchost hangi servisleri barındırıyor?
Get-WmiObject Win32_Process -Filter "Name='svchost.exe'" | ForEach-Object {
    $pid = $_.ProcessId
    $services = Get-WmiObject Win32_Service -Filter "ProcessId=$pid" | 
      Select-Object -ExpandProperty Name
    [PSCustomObject]@{
        PID = $pid
        Services = ($services -join ", ")
    }
} | Where-Object { $_.Services -ne "" } | Format-Table -AutoSize

Task Manager’ın Sınırları ve Ne Zaman Başka Araca Geçmeli

Task Manager güçlü ama her şeyi yapamaz. Şu durumlarda başka araçlara geçmek gerekiyor:

  • Uzun vadeli performans analizi: Performance Monitor (perfmon) ve veri toplayıcılar kullanılmalı
  • Bellek dump analizi: WinDbg ile process dump incelemesi gerekiyor
  • Detaylı disk I/O profiling: Process Monitor (Sysinternals) çok daha iyi
  • Ağ trafiği analizi: Wireshark ya da Network Monitor
  • Süreç ağacı görselleştirme: Process Explorer (Sysinternals) Task Manager’ın çok üstünde
# Performance Monitor ile veri toplayıcı seti oluşturmak
$dcName = "SunucuPerformansLog"
logman create counter $dcName -f bin -si 15 -o "C:PerfLogs$dcName" `
  -c "Processor(_Total)% Processor Time" `
     "MemoryAvailable MBytes" `
     "PhysicalDisk(_Total)% Disk Time" `
     "Network Interface(*)Bytes Total/sec"

# Başlatmak
logman start $dcName

# Durdurmak
logman stop $dcName

Sonuç

Task Manager’ı yüzeysel kullanmak ile gerçek anlamda okumak arasındaki fark, bazen saatler süren debug süreçlerini dakikalara indirgemek demek. CPU, Memory, Disk ve Network sekmelerini birlikte yorumlamak; Resource Monitor ile desteklemek; Details ve Services sekmelerini de dahil etmek, sizi gerçek bir sistem analisti yapıyor.

Pratik öneri: Sorun olmasa bile haftalık olarak 10 dakika Task Manager’a bakın. Temel çizginizi (baseline) zihinsel olarak öğrenin. Hangi süreçler normalde ne kadar CPU kullanıyor, RAM normalde ne kadar dolu oluyor, disk aktivitesi tipik olarak ne seviyelerde. Baseline bilmeden anomali tespit edemezsiniz.

Ve unutmayın: Task Manager, bir başlangıç noktası. Orada gördükleriniz sizi doğru yöne işaret eder, ama derinlemesine analiz için Sysinternals araçları, perfmon ve PowerShell kombinasyonu şart. Bu araçları birlikte kullanmayı öğrenmek, Windows sysadmin’liğinin temel taşlarından biri.

Bir yanıt yazın

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