When MemHog is executed, it will allocate up to 100MB of memory in 1MB allocations. For every 10MB of memory allocated, the program sleeps for 30 seconds. The reason I have the program suspend execution for 30 seconds for every 10MB allocated is because when making heavy use of the paging file, the system will utilize quite a bit of the processor to grow the pagefile and allocate the memory. This heavy processor utilization will mask the memory utilization curve of the application. And the purpose of this program is to simulate an application that is making heavy use of your system memory. I’d also like to mention that the program uses the memset command to populate each 1MB memory block with a series of asterisks. This is so the memory is actually accessed. If you do not perform this step, then the memory will be merely allocated but not used. The Committed Bytes object counter will then max out momentarily as the virtual memory address space is increased, but no paging activity will take place as no memory is physically used. When you run MemHog, it will display a chart similar to the chart shown in Figure 6.7.

Figure 6.7  An example of a system-wide memory shortage displayed with the Performance Monitor.

This particular chart is based on a log file that I captured while running the MemHog.EXE program. The same basic object counter would also be displayed in realtime for a memory-intensive application, as well. What I want to point out to you is that the behavior of these counters is something to watch. The behavior displayed in the chart shown in Figure 6.7 is an indication of memory-related problems. Specifically, you should note the following behaviors:

•  Pages/sec.—Notice the high peaks for this counter. This indicates a great deal of paging activity, generally because your system does not contain enough physical memory to handle the demands placed on it by the application. If you see such activity on your system, you should look closer to see which application is placing such a load on the system. It may be normal behavior for the application, in which case, you should add more physical memory to increase system performance.

•  Page Faults/sec.—Notice here that the Page Faults/sec. peaks follow the peaks for the Pages/sec. counter. It too is an indication that your system is paging heavily. A consistent value over 5 indicates that your system is paging more than it should. A consistent value of 10 or higher is a desperate cry for help. Adding additional physical memory is the only cure. If you’ll note in my example, these counters only peak to a high value and then drop back to a normal level. But on an active file or application server, the activity should be more linear.

•  Available Bytes—This counter indicates the amount of virtual address space that is available to your system. As applications use memory and page to disk, this value will decrease. When it drops below 10MB, you will most likely see a message warning you that virtual memory is running low and you should close some applications or increase your virtual memory settings. If this counter is consistently low after running an application, then this generally indicates a system memory leak.

•  Committed Bytes—As the Available Bytes counter decreases, the Committed Bytes counter increases. This demonstrates that the process is allocating memory from the virtual address space but not necessarily using it. Still, your virtual address space is a limited resource, and you should watch this counter to check for applications that allocate memory but do not use it. This behavior should be noted, and you should discuss this problem with the manufacturer to fix the problem. Notice in our example that this counter steps up as the paging file activity steps up. This is an indication that the application is making use of the memory it is allocating. High consistent values are an indication that adding additional physical memory will increase system performance. You should also note the counter value when an application ends. If the counter does not return to the original value, the application has a memory leak or a hidden process that is not terminating properly.

•  Cache Faults/sec.—This counter should be compared with the Page Faults/sec. to determine if you really are paging too much in a normal system. If this counter is less than the Page Faults/sec. counter, you are definitely paging too much, and you should add additional physical memory.

•  Usage—This counter indicates your current paging file activity. If this value is consistently larger than your minimum paging file size, you should increase your minimum paging file size. There is a significant amount of system overhead involved in growing the page file, and any page file growth is not contiguous, which means more overhead is involved in accessing pages stored in this section of the page file. Notice here that the paging file usage is incremental in steps of 10MB, and when the application terminates, the Usage counter drops back to the original (or a little less) value. If your Usage counter does not return to the original value after running an application, it has either a memory leak or a hidden process that is not terminating.

•  Usage Peak—This counter indicates the maximum usage of your page file. If this value consistently reaches 90 percent, your virtual address space is too small, and you should increase the size of your paging file. When it hits above 75 percent, you will generally notice a significant system performance degradation.

The preceding example illustrates a general system-wide memory-related problem. But in the real world, you need to find the specific cause of the problem. This too can be achieved with the Performance Monitor. Instead of looking at system-wide object counters, you want to narrow the search to the Process object counters, as displayed in Figure 6.8, to find the process that is using up your system memory.

Figure 6.8  Using Performance Monitor to isolate a memory-intensive application.