T The Triage ManualTechnical Guides for IT Emergencies
P2 · Windows Server

Windows Server High CPU / Memory / Disk — Performance Degradation Diagnosis

A Windows Server becomes sluggish, applications time out, or users report slowness. Systematic diagnosis using Resource Monitor, PerfMon counters, and process-level tools identifies whether the bottleneck is CPU saturation, memory pressure, kernel pool exhaustion, or I/O queue depth.

Indicators

Likely causes

Diagnostic steps

  1. Open Resource Monitor (resmon.exe) — review CPU, Memory, Disk and Network tabs to identify the top consuming process and resource
    Provides a real-time multi-resource overview to quickly identify which subsystem is saturated and which process is responsible.
  2. Open PerfMon and add counters: \Processor(_Total)\% Processor Time, \Memory\Available MBytes, \PhysicalDisk(_Total)\Avg. Disk sec/Transfer, \PhysicalDisk(_Total)\Avg. Disk Queue Length
    Quantifies key resource metrics over time to distinguish sustained saturation from transient spikes.
  3. Identify top memory consumers: Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object Name, Id, @{N='MB';E={[math]::Round($_.WorkingSet64/1MB,1)}} | Select-Object -First 15
    Surfaces the top 15 memory-consuming processes on Windows for targeted investigation.
  4. Check kernel pool leaks (Event ID 2019/2020): run poolmon.exe (from Windows SDK) — sort by NonP column; identify the tag consuming most non-paged pool and cross-reference against driver list
    Pinpoints kernel-mode pool leaks to a specific driver tag when user-mode process analysis does not fully account for memory consumption.
  5. Check disk health: Get-PhysicalDisk | Select FriendlyName, HealthStatus, OperationalStatus; run CrystalDiskInfo for S.M.A.R.T data on physical hardware
    Identifies degraded or failing disks that could be contributing to elevated I/O latency.
  6. Capture a 30-minute PerfMon data collector set baseline and export to BLG file for trend analysis; use Windows Admin Center Performance History if available
    Creates a historical record for trend analysis and comparison against established baselines.
  7. Linux — check overall RAM and swap: free -h && vmstat 2 10 (observe si/so columns for swap-in/swap-out activity over 10 intervals); check OOM events: dmesg | grep -i 'oom\|out of memory\|killed process'
    Quantifies paging activity on Linux and confirms whether the kernel OOM killer has already terminated processes, establishing severity.
  8. Linux — list top memory consumers: ps aux --sort=-%mem | head -20; use sar -r 2 30 for historical memory utilisation if sysstat is installed.
    Surfaces the specific processes responsible for RAM exhaustion on Linux so remediation can be targeted.
  9. Check virtual memory / page file configuration. Windows: System Properties > Advanced > Performance Settings > Advanced > Virtual Memory — note current size and whether system-managed. Linux: swapon --show && cat /proc/sys/vm/swappiness
    Confirms whether the page file or swap is adequately sized and whether swappiness tuning is contributing to aggressive paging under moderate memory pressure.
  10. Use RAMMap (Sysinternals) on Windows to get a detailed physical memory breakdown by type (Active, Standby, Modified, Free) and identify large non-process consumers such as driver-locked pages or mapped files.
    Reveals memory consumers invisible to Task Manager or poolmon, particularly large standby lists or mapped-file caches consuming physical RAM.

Resolution path

Prevention

Tools

windows-serverperformancecpumemorydisk-ioperfmonpool-leakresmonbottleneckpagingswapfreezinglagmemory-leaklinuxout-of-memoryoomcapacityincident-responsetriage