Welcome to the Microsoft Premier Field Engineering (PFE) Windows performance analysis guide. This is a web of interconnected documents intended to assist Microsoft Premier Field Engineers (PFE), Microsoft Support Professionals, and IT Professionals with prescriptive guidance on how to diagnose Windows performance issues in production environments and provide steps toward resolution.

This document assumes the reader is familiar with how to use Microsoft Windows Performance Monitor (perfmon) to gather and view live performance counters. 

The PFE PerfGuide Table of Contents can be used to see all of the articles associated with this guide.

You have arrived here because you suspect a performance problem with your Microsoft Windows computer or server.

Initial Indicators of Windows Performance Problems

Start with the four primary resources of a computer: Memory, Processor, Disk, and Network, then branch out from there. The following is the performance counters (Microsoft Performance Monitor) that indicate a potential issue with each respective resource. Microsoft Windows Performance Monitor performance counters are used to initially identify performance problems, then various other tools are used to as next steps towards resolution.

Memory

Microsoft Windows uses many kinds of memory. Windows memory can be categorized into physical RAM, committed memory, application virtual memory, and kernel virtual memory.

Physical RAM

The easiest and best initial indicator of a lack of physical RAM condition is the “\Memory\Available MBytes” performance counter. Available MBytes is the amount of physical memory, in Megabytes, immediately available for allocation to a process or for system use. It is equal to the sum of memory assigned to the standby (cached), free and zero page lists.

If “\Memory\Available MBytes” is less than 100MBs or less than 5% of total physical RAM, then the computer may be running critically low on physical RAM. If you suspect this condition, then go here.

Committed Memory

Committed Bytes is the amount of committed virtual memory, in bytes. Committed memory is the physical memory which has space reserved on the disk paging file(s). In other words, it is memory that is “in use” by processes. The Commit Limit is the sum of all of the physical resources in which the operating system can use to store data – it is the sum of RAM and all of the page files. Once all of RAM and all of the page files are full and unable to expand, then the system has reached its commit limit. The “\Memory\% Committed Bytes In Use” performance counter is the percentage of the Commit Charge measured by “\Memory\Committed Bytes” compared to the commit limit measured by “\Memory\Commit Limit”.

If “\Memory\Committed Bytes In Use” is greater than 75%, then the computer may be running low on physical resources (RAM and/or page file). If you suspect this problem, then follow this link for next steps: 



    PerfGuide: Out of System Committed Memory

Application Virtual Memory

Each process in Windows has its own, private virtual address space. Ideally, virtual memory should be unimaginably large, but the fact remains that it is a finite resource. If an application (user mode) runs out of virtual memory, then it will likely crash with an out of memory exception.

1. Identify the Maximum Virtual Address Space for Applications: Use the following command (usable on Windows XP/2003 and greater) to determine the maximum size of application virtual memory:
   
   wmic PATH Win32_OperatingSystem GET MaxProcessMemorySize
   
   
   
   Sample output of this command for a Windows 7 x64 computer is:
   
   MaxProcessMemorySize
   
   8589934464
   
   
   
   The output is in kilobytes, therefore this Windows 7 x64 computer has 8TBs of virtual memory per process. If an application (user mode) runs out of virtual memory (meaning if it gets close to the MaxProcessMemorySize), then it will likely crash with an out of memory exception which can typically be found in the Application Event log, unless the application is designed for this condition.
2. Is Virtual Memory Low: If “\Process(*)\Virtual Memory” exceeds 80% of the MaxProcessMemorySize, then the application is likely running out of virtual memory and might crash soon if unable to find contiguous memory for its next memory allocation. If you suspect this problem, then follow this link for next steps:
   
   
   
   PerfGuide: Out of Process Virtual Memory 

Kernel Virtual Memory

The kernel also resides in virtual memory. If it runs out of virtual memory, then the operating system can hang. The kernel has three important resources that resources in virtual memory: System Page Table Entries (PTEs), pool paged, and pool non-paged memory pools.

System Page Table Entries

System Page Table Entries provide the mapping between virtual and physical memory. If the system is out of PTEs, then it is unable to allocate memory to processes.

If “\Memory\Free System Page Table Entries” is less than 10,000, then the operating system will likely suffer long performance delays. If you suspect this problem, then follow this link for next steps:

[Link to future blog post]

While the future blog post is under construction, here is other documents on troubleshooting low PTE problems:

• Symptoms: Lack of Free System Page Table Entries (PTEs) and system-wide delays (I/O request failures)
• Symptoms: Lack of Free System Page Table Entries (PTEs) and Error Message: ERROR_NO_SYSTEM_RESOURCES (1450)
• Symptoms: Lack of Free System Page Table Entries (PTEs) and no system-wide delays
• Symptoms: Lack of Free System Page Table Entries (PTEs), system-wide delays (I/O request failures), and low on Paged Pool Memory and/or Non-paged Pool Memory on 32-bit Windows

Pool Paged and Pool Non-Paged Memory Pools

Pool Paged and Pool Non-Paged pools serve as the memory resources that the operating system and device drivers use to store their data structures. When they are unable to allocate memory, then the operating system will likely suffer long performance delays.

1. Identify the Maximum Pool Sizes: Performance counters do not provide the maximum sizes of the memory pools, therefore use Process Monitor and the Microsoft Debugging Tools for Windows to identify them. The following document shows how to install the Microsoft Debugging Tools for Windows and how to use Process Monitor to show the maximum pool sizes:
   
   Pushing the Limits of Windows: Paged and Nonpaged Pool by Mark Russinovich
2. Is Virtual Memory Pools Low: If “\Memory\Pool Paged Bytes” or “\Memory\Pool NonPaged Bytes” are close to or exceed 80% of their respective maximum sizes, then the operating system will likely suffer long performance delays. If you suspect this problem, then follow the link for next steps:
   
   [Link to future blog post]
   
   
   
   While the future blog post is under construction, here is a document on troubleshooting low pool memory problems:
   • Symptoms: Lack of Free System Page Table Entries (PTEs), system-wide delays (I/O request failures), and low on Paged Pool Memory and/or Non-paged Pool Memory on 32-bit Windows
   • Pushing the Limits of Windows: Paged and Nonpaged Pool by Mark Russinovich

Processor

If “\Processor(_Total)\% Processor Time” is greater than 80% on average, then the computer may be busy with the processor resource. If your computer meets this criteria or you suspect it, then follow this link:

PerfGuide: User Mode Versus Privileged Mode Processor Usage

Disk

If “\LogicalDisk(*)\Avg Disk Sec/Read” or “\LogicalDisk(*)\Avg Disk Sec/Write” is greater than 15ms (0.015 seconds), then the computer may have a disk performance issue. If your computer meets this criteria or you suspect it, then follow this link:

Understanding Disk Metrics.

Network

If “\Network Interface(*)\Output Queue Length” is greater than 2 on average, then the network adapter is not able to put network packets on the network fast enough. This could be due to network latency, chattiness, packet loss, etc. If your computer meets this criteria or you suspect it, then follow this link:

[Link to future blog post]

More Information

Vital Signs Workshop: Microsoft Services offers an instructor led workshop called, "Vital Signs", which goes in depth into Windows architectured focused on Windows performance analysis. If you are interested, then contact your Microsoft Technical Account Manager (TAM). If you do not have a Microsoft Premier Support contract, then consider the great benefits of having one by going to our Microsoft Services Premier Support web site at: http://www.microsoft.com/microsoftservices/en/us/support_premier.aspx

Special Thanks and Contributors

Shane Creamer for originally creating the Vital Signs workshop and inspiring us all with making performance analysis a science.