Uncover Memory-Related Bottlenecks

[Nick]

Uncover Memory-Related Bottlenecks

Memory is often the source of performance problems, and you should always rule out memory problems before examining other areas of the system. Here’s an overview of counters that you’ll want to track to uncover memory, caching, and virtual memory (paging) bottlenecks.


Memory is often the source of performance problems, and you should always rule out memory problems before examining other areas of the system. Systems use both physical and virtual memory. To rule out memory problems with a system, you should configure application performance, memory usage, and data throughput settings, and then monitor the server’s memory usage to check for problems.

Application performance and memory usage settings determine how system resources are allocated. In most cases you want to give the operating system and background applications the lion’s share of resources. This is especially true for Active Directory, file, print, and network and communications servers. On the other hand, for application, database, and streaming media servers, you’ll want to give the programs the server is running the most resources.


Here’s an overview of counters that you’ll want to track to uncover memory, caching, and virtual memory (paging) bottlenecks.

Issue: Physical and virtual memory usage
Counters to Track: Memory\Available Kbytes; Memory\Committed Bytes
Details: Memory\Available Kbytes is the amount of physical memory available to processes running on the server. Memory\Committed Bytes is the amount of committed virtual memory. If the server has very little available memory, you might need to add memory to the system. In general, you want the available memory to be no less than 5 percent of the total physical memory on the server. If the server has a high ratio of committed bytes to total physical memory on the system, you might need to add memory as well. In general, you want the committed bytes value to be no more than 75 percent of the total physical memory.



Issue: Memory page faults
Counters to Track: Memory\Page Faults/sec; Memory\Pages Input/sec; Memory\Page Reads/sec
Details: A page fault occurs when a process requests a page in memory and the system can’t find it at the requested location. If the requested page is elsewhere in memory, the fault is called a soft page fault. If the requested page must be retrieved from disk, the fault is called a hard page fault. Most processors can handle large numbers of soft faults. Hard faults, however, can cause significant delays. Page Faults/sec is the overall rate at which the processor handles all types of page faults. Pages Input/sec is the total number of pages read from disk to resolve hard page faults. Page Reads/sec is the total disk reads needed to resolve hard page faults. Pages Input/sec will be greater than or equal to Page Reads/sec and can give you a good idea of your hard page fault rate. A high number of hard page faults may indicate that you need to increase the amount of memory or reduce the cache size on the server.



Issue: Memory paging
Counters to Track: Memory\Pool Paged Bytes; Memory\Pool Nonpaged Bytes
Details: These counters track the number of bytes in the paged and nonpaged pool. The paged pool is an area of system memory for objects that can be written to disk when they aren’t used. The nonpaged pool is an area of system memory for objects that can’t be written to disk. If the size of the paged pool is large relative to the total amount of physical memory on the system, you might need to add memory to the system. If the size of the nonpaged pool is large relative to the total amount of virtual memory allocated to the server, you might want to increase the virtual memory size.

From the Microsoft Press book Microsoft Windows Server 2008 Administrator’s Pocket Consultant by William R. Stanek.

credit: technet.microsoft.com