Monitoring and Tuning Your Server

Memory Monitoring Specifics

This section is a brief review of the most important memory monitoring techniques. Many performance monitoring tools measure memory use system-wide and according to each process. These tools include Task Manager as well as the System Monitor, which is usually referred to as PerfMon (Perfmon.msc, supplanting the older Perfmon.exe). These are Windows 2000 Server administrative tools built into Windows 2000 Server. In addition, there are various tools included on the Microsoft® Windows® 2000 Server Resource Kit companion CD or in Windows 2000 itself, the latter of which include Process Monitor (Pmon.exe), Process Viewer (Pviewer.exe), Process Explode (Pview.exe), and Performance Data Log Service, which is usually referred to as PerfLog, (Pdlcnfig.exe and Pdlsvc.exe). PerfLog and PerfMon can measure memory use over time. PerfMon, in particular, can read and log data from software performance counters that are built into IIS 5.0 and the Windows 2000 operating system. For more information about PerfMon, see The System Monitor in this section.

Monitor Available Memory Compare the total physical memory that is available to Windows 2000 with the available memory remaining when you are running all server services. To gather more reliable data, log this value over time, making certain to include periods of peak activity. The system attempts to keep the amount of available bytes at 4 MB or more, but it is prudent to keep at least 5 percent of memory (rather than a specific number of MB) available for peak use.
To track available memory, log the Computername\ Memory\ Available Bytes counter. (“Computername” indicates the name of the computer you are monitoring, if it isn’t the same one on which PerfMon is running. This indicator is not explicitly shown in the names of most of the counters listed in this section, but is generally applicable.)
Monitor Paging Continuous high rates of disk paging indicate a memory shortage.
- Number of Hard Page Faults If a process requests a page in memory and the system cannot find it at the requested location, this constitutes a page fault. (If the page is elsewhere in memory the fault is called a soft page fault. If the page must be retrieved from disk, the fault is called a hard page fault.) The system also counts a page fault on a file access if the requested page is not found in the File System Cache and must be retrieved from storage. The page fault counters do not distinguish between hard and soft faults, so you must combine counter information to deduce the number of hard faults.
  To track paging, log the following counters: Memory\ Page Faults/sec, Memory\ Cache Faults/sec, and Memory\ Page Reads/sec. The first two of these track working sets and the File System Cache. The Page Reads counter helps you track hard page faults: a high rate of page faults coupled with a high rate of page reads (these also show up in the Disk counters) indicates a high rate of hard faults.
Monitor the File System Cache The File System Cache is the working set of the file system. This cache is a reserved area in physical memory where the file system stores its recently used and frequently used data. By default, the system reserves about 50 percent of physical memory for the File System Cache, but the system trims the cache if it is running out of memory. A server running IIS 5.0 functions like a specialized file server, and a large and effective File System Cache is vital to its efficient operation. For more information, see Monitoring the File System Cache in this section.
Monitor the Size of the Paging Files The paging files on disk back up committed physical memory. The larger the paging file, the more memory the system can commit. Windows 2000 itself creates a paging file on the system drive; you can create a paging file on each logical disk, and you can change the sizes of the existing files. In fact, striping a paging file across separate physical drives (use drives that do not contain your site’s content) improves paging file performance. Remember, in any case, that the paging file on the system drive should be at least twice the size of physical memory, so that if a crash occurs the system can write the entire contents of RAM to disk. This socalled “core dump” (a term that originated when memory was built of discrete magnetic cores, long before chips were invented) can help you recover data and determine the cause of the crash. To monitor the paging files, log the Computername\ Process\ Page File Bytes: Total counter.
Monitor the Size of the Paged and Nonpaged Memory Pools The system’s memory pools hold objects created and used by applications and the operating system. The contents of the memory pools are accessible only in privileged mode. That is, only the kernel of the operating system can directly use the memory pools; user processes cannot. On servers running IIS 5.0, threads that service connections are stored in the nonpaged pool, along with other objects used by the service, such as file handles.
To monitor the pool space for all processes on the server, log the Computername\ Memory\ Pool Paged Bytes and Computername\ Memory\ Pool Nonpaged Bytes counters. To monitor the pool space used directly by IIS 5.0, log the Computername\ Process\ Pool Paged Bytes: Inetinfo and Computername\ Process\ Pool Nonpaged Bytes: Inetinfo counters.