Windows Performance (Monitoring, Tunning)

Performance Monitoring, meaning of metrics

• Memory > Commit -- Amount of virtual memory reserved by the operating system for the process.
• Memory > Working Set -- Amount of physical memory currently in use by the process.
• Memory > Shareable -- Amount of physical memory in use by the process that can be shared with other processes.
• Memory > Private -- Amount of physical memory in use by the process that cannot be used by other processes.

So Working Set = Shareable + Private

• Memory > Free --Consider Free memory as available memory that is un-used / wasted.
• Memory > Standby -- Consider Standby memory as available memory that the OS for the moment uses for caching. When a process needs more RAM it will be instantly available.

Keep in mind that it's good to have plenty of available (Free+Standby) memory for caching because it speeds up disk access.

• Memory > Hard Faults happen when data that a process needs is pulled from the on disk Page File and not from memory. That's slooooow. 99% of the time the data where on the page file because there was no memory available for them (in 1% they were pushed to the page file for other reasons -- e.g. because they were left unused for too long).

• Disk > Response Time (ms). In general, anything less than 10 ms is considered good performance. If you occasionally go beyond 10 ms, you should be okay, but if the system is consistently waiting more than 20 ms for response from the storage, then you may have a problem that needs attention, and it's likely that users will notice performance degradation. At 50 ms and greater, the problem is serious.
• Disk > Active Time (%). This shows the percentage of time that the disk is not idle and is actively serving requests. If a disk is constantly running at very, very high levels (say, more than 80%), it may point to a storage-related bottleneck.
• Disk > Disk Queue Length. Average disk queue length. In other words how many requests have stacked up waiting for the disk drive to be able to service them. A high number can indicate that there are not enough disk spindles to service the needs of the application or that the existing storage is too slow to keep up with requests. However, how you define a "high number" in this context requires that you know how the underlying volume is created. If you're running on a single disk system and your queue length remains consistently greater than 2, you should add more resources. If it goes beyond 5, you have serious problems that need to be addressed. If you know how many disks make up your underlying volume, multiply the number of disks by 2 to get a very rough, ballpark queue depth maximum value. So, if you're running on a 10 disk system and the queue depth is 18, you should be fine. (For additional complicating factors, the RAID level and stripe size you choose can affect this value as well)

Do we need more RAM?

Check Hard Faults, and used Physical Memory.

If you notice an excessive number of Hard Faults related to a particular process on a regular basis, chances are your system needs more physical memory. To more closely watch processes that are encountering a large number of Hard Faults, you can use the Filtering system built in to Resource Monitor. Select the check box adjacent to that process, and it will move to the top of the list. You'll then see those Hard Faults appear in orange in the graph.