Memory Monitoring

Processes section

To start Resource Monitor

• Click Start, click in the Start Search box, type resmon.exe, and then press ENTER.

To pause or resume monitoring

• To pause data collection and review the current data, click Monitor, and then click Stop Monitoring. When you are ready to begin collecting data again, click Monitor, and then click Start Monitoring.

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.

Physical Memory

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.

Source: Click here