Scott Lowe drills down on the memory-related metrics you can see in the Microsoft Windows Resource Monitor tool.
In three TechRepublic columns, I discussed how the Microsoft Windows Resource Monitor provides administrators with a way to gather real-time metrics that can be used for troubleshooting and to identify potential resource bottlenecks. I covered how to use Resource Monitor to monitor storage performance, CPU performance, and network performance. In this final installment of my series about Resource Monitor, I focus on monitoring memory.For the purposes of this post, we'll use the screenshot in Figure A to analyze the various metrics that are available with regard to RAM in Resource Monitor. This is a view from a production server running Windows Server 2008 R2 and Exchange Server 2010 with all Exchange roles installed. This machine has heavy RAM needs, and this server is running as a virtual machine under VMware vSphere 4.1. Figure A
Resource Monitor - Memory tab (Click the image to enlarge.)
Let's see what metrics are available with regard to memory on this Windows server.
The Memory tab's Processes section displays key metrics related to how the system's processes use memory. Here's information about the metrics:
- Image. Process executable file name. This is the name of the process that is actively using the disk.
- PID. Process ID. This is the ID number associated with the process; it is useful if you want to use other utilities to manage processes, or if you want to easily match up processes with Task Manager.
- Hard Faults/sec. A hard fault doesn't necessarily indicate a critical error condition, though it may indicate that the server is in need of more RAM. A hard fault occurs every time the system uses the swap file on the disk. This is important because disk storage is much, much slower than RAM, so each time the system uses disk-based virtual RAM, there is a significant performance penalty. If you see hard faults on a regular basis (especially if the numbers are large), you should consider adding more RAM to the server. Hard faults are sometimes referred to as Page Faults.
- Commit (KB). This is the total amount of physical and virtual memory (page file) that is committed to this specific process.
- Working Set (KB). This is the amount of physical memory that is committed to this particular process. This number should be the total of the next two metrics, which are its components.
- Shareable (KB). This is the total amount of physical memory that is committed to this particular process but that can also be shared with another process.
- Private (KB). This is the total amount of physical memory that is committed to this particular process but cannot be shared with another process.
Below the Processes section, you'll see a section called Physical Memory that contains this information:
- In Use. The amount of memory that is in use right now.
- Available. Of the total physical memory in the system, this is how much is still available for allocation.
- Hardware Reserved. This identifies the amount of memory that various hardware devices have set aside for their dedicated use. Almost any device in the server can add to this metric. This Exchange Server clocks in at 1MB.
- Modified. As information is written into memory pages, it stays there while other processing goes on behind the scenes. As information is updated on these memory pages, those pages are marked as having been modified. After a period of time, in order to ensure that the system makes the best use of available memory resources, modified pages that have not been accessed in a while might be moved to the standby category.
- Standby. This memory contains cached data and code that is not actively in use but that may be called into action at some point. Windows manages this class of RAM by prioritizing each page that comes in. As other processes need RAM, low priority pages from this pool are reallocated to other needs.
- Free. This value is how much RAM is currently available above and beyond what is in use. You might think that having such a small amount of RAM marked as free in this 16 GB system might identify a major problem, but that's the case. With many of Microsoft's newer products, it's better to use as much RAM as possible than to leave it idle. Products such as Exchange use RAM to its fullest extent and cache portions of the product for faster access.
One common mistake it to use the "In Use" and "Available" metrics as the sole indicators for overall system health and to get concerned when particular processes appear to be eating too much RAM. This is why you need to understand how the application is supposed to behave.
For example, Exchange 2010 often uses as much memory as you can throw at it; this is by design. The thinking is that Exchange will use RAM to cache as much information as possible in order to improve overall performance. So it's important to look at other metrics, such as Hard Faults, to determine if there is a really a RAM-related performance issue on an Exchange 2010 machine. If a service shouldn't be using a lot of RAM and it is, you need to do more troubleshooting; this is the point at which you might fire up Performance Monitor to gather more specific details.
Throughout this four-part series on Resource Monitor, I hope you learned new ways to monitor your Windows Server systems using a free, easy to use tool that Microsoft built to help administrators solve performance-related issues.