Monitoring the IIS 6.0 Working Set (IIS 6.0)
If free memory on the computer is above a threshold, pages are left in the working set of a process even if they are not in use. When free memory falls below that threshold, pages are trimmed from working sets. If the trimmed pages are later needed, they are soft-faulted back into the working set before leaving main memory.
When available memory falls below about 4 MB, the system attempts to make more memory available by taking memory away from the working sets of processes. This strategy increases the rate of page faults, because each process must now retrieve data that was once in its working set either from disk or from elsewhere in memory. When the rate of page faults for a particular process rises, however, the system attempts to expand the working set of that process to lower the page fault rate. As the system tries to maintain this balance, the size of the working set of each process fluctuates accordingly.
The Process\Working Set counters measure the number of memory pages that each process uses. If the system has sufficient memory, it can maintain enough space in the working set so that IIS 6.0 rarely must perform disk operations. One indicator of memory sufficiency is how much the size of the process working set fluctuates in response to general memory availability on the server. Significant fluctuation can indicate a lack of available memory.
The systems 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.
Table 6.18 describes the counters that are available for monitoring the IIS 6.0 working set.
| Table 6.18 Counters for Monitoring the IIS 6.0 Working Set | |
| Object\Counter | Value |
Memory\Pool Paged Bytes Memory\Pool Non-paged Bytes | Pool Paged Bytes and Pool Non-paged Bytes monitor the pool space for all processes on the server. |
Process(W3wp1)\Virtual Bytes Process(Inetinfo)\Virtual Bytes | The amount of virtual address space, in bytes, reserved directly by IIS, either by the Inetinfo.exe process (where IIS runs when set to IIS 5.0 isolation mode) or by the W3wp.exe process (where isolated or pooled applications run when IIS is set to worker process isolation mode) instantiated on your server. |
Process(W3wp1)\Working Set Process(Inetinfo)\Working Set | Size, in bytes, of the working set of the W3wp.exe or Inetinfo.exe process. These counters display the last observed value, not an average over time. |
Monitor the W3wp instance if you are running your Web server in worker process isolation mode. If you are running your server in IIS 5.0 isolation mode, monitor either the Inetinfo instance (for in-process applications) or the Dllhost instance (for out-of-process applications).
Important
You can run IIS6.0 in one of two request processing models: worker process isolation mode and IIS 5.0 isolation mode. IIS typically performs better while running in worker process isolation mode, although results depend on a variety of factors, including the design of your applications. Also note that each mode uses different instances of a counter to monitor performance. For more information about the two request processing models, see Running IIS 6.0 as an Application Server.
Be sure that you monitor Process\Working Set counters for all instances of W3wp.exe (the component that hosts the worker process when IIS runs in worker process isolation mode) on your server; otherwise, you might obtain an inaccurate reading of the virtual memory used by IIS.
You can use the Memory\Available Bytes counter (in Table 6.14) as an indicator of memory availability and the Process\Working Set counters (in Table 6.18) as an indicator of the size of the IIS 6.0 working set. These counters display the last value observed, rather than an average, so be sure to examine data collected over time.
Monitoring Disk I/O
IIS 6.0 writes its logs to disk, so there is almost always some activity, even when requests are processed out of the cache 100 percent of the time. Under ordinary circumstances, disk activity other than that generated by logging might indicate a problem in other areas. For example, if your server has insufficient RAM, you see lots of disk activity because many hard page faults are occurring.
Under certain conditions, disk activity is normal. Examples include a large site that serves more content than your server can cache and any site that serves large amounts of static content that is not cacheable. You are also likely to notice lots of disk activity if your server hosts a database or if your users request many different Web pages.
Typically, you use the Physical Disk counters in Table 6.1 to watch for spikes in the number of disk reads when the server is busy. If the server has enough RAM, most connections result in cache requests, unless the server also hosts a database and clients are making dissimilar queries, which precludes caching.
If the server does not host any application or service that is obviously disk-intensive, but you see lots of disk activity anyway, you need to check RAM use immediately to make sure that the server has enough memory.
