Do you have enough memory?
Posted: April 21st, 2008 | Author: TnT Admin | Filed under: Analyze | Tags: Bottleneck, Memory | No Comments »Memory\Pages/sec
This counter indicates the number of paging operations to disk, and it is a primary counter to indicate possible insufficient RAM to meet your server’s needs. A recommended benchmark to watch is when the number of pages per second exceeds 50 per paging disk on your system. This is as indicated as hard page faults. (Source: Mitch Tulloch, Windows Networking)Memory\Page Faults/sec and Memory\Transition Faults/sec
Memory\Page Faults/sec measures the total amount of hard and soft page faults occuring on the system. A good gauge will be 50 page faults per second. Hard page fault is page fault occuring outside physical memory (e.g. Memory\Pages/sec) while soft page fault is page faults occuring in physical memory (e.g. Memory\Transition Faults/sec).
Memory\Transition Faults/sec measures how often recently trimmed page on the standby list are re-referenced. If this counter slowly starts to rise over time then it could also indicating you’re reaching a point where you no longer have enough RAM for your server to function well. (Source: Microsoft Technet)
Memory\Available Bytes
If this counter is greater than 10% of the actual RAM in your machine then you have more than enough RAM. Mitch recommends 2% of the actual RAM to be the threshold but it will be advisable to set it at 4% instead (allowing enough memory to perform OS task). If it is below the threshold, you may want to find out which process is taking up the most memory with the next counter.
(Source: Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos
Process(instance)\Working Set and Memory\Cache Bytes
This counter measures the size of the working set for each process, which indicates the number of allocated pages the process can address without generating a page fault. This will assist to determine which process is consuming the larger amounts of RAM if a downward trend is developed.
On the other hand, Memory\Cache Bytes measures the working set for the system i.e. the number of allocated pages kernel threads can address without generating a page fault.
Let’s look at identifying memory issues again. I’ve found this great resource for memory bottleneck identification at Windows IT Library.
Process(instance)\Working Set and Process(instance)\Page Faults/sec
Pull up the Process(instance)\Working Set and Process(instance)\Page Faults/sec, for example, bring up Process(java.exe)\Working Set and Process(java.exe)\Page Faults/sec. This combination will determine how much memory is used by the process and how many Page Faults (if any) are generated when the Working Set grows over time. You can also monitor the Available Bytes counter to monitor if this counter becomes lower overtime due as the Process(instance)\Working Set grow.
Windows IT Library also recommended a cool tip of plotting the process Working Set against the total Working Set, to be specified _TOTAL instance of all processes in the OS. In this way, you can make comparison of the amount of working set memory the application (eg. java.exe) is hogging relative to all working set memory for all applications and processes. This is also applicable to Process(instance)\Page Faults/sec where you can plot it against the _TOTAL instance of all processes’ page faults.
Note:
A process’s working set is the amount of physical memory that Windows NT Server has given it.
Memory\Committed Bytes and Memory\Commit Limit
This counter measures the amount of committed virtual memory in bytes as opposed to reserved. The commitment can be to physical RAM or pagefile space. This memory is unavailable for other purposes and Windows IT Library recommends it to remain low.
On the other hand, Memory\Commit Limit shows the amount of virtual memory, in bytes, that can be committed without having to extend the paging file(s). Committed memory is physical memory which has space reserved on the disk paging files and if the paging file(s) are expanded, this limit increases accordingly.
Note:
There can be one or more paging files on each physical drive.
The benefit of both counters is straight-forward, they allow you to verify the amount of virtual memory committed which represents the actual usage of memory by all processes running in the OS. The Memory\Commit Limit lets you determine if the page file was expanded over time due to any increased memory needs overtime.
Memory\Pool Non-paged Bytes
This is the amount of memory that is being used by the OS to perform system-critical activities that will not be paged out to virtual memory, that is to say, it remains in physical memory all the time. Windows IT Library recommends this counter to remain stable. An increase in this counter may call for an audit of the tasks (eg. switching, interrupts) performed by the OS.
Leave a Reply