Memory—or the lack of
it—is probably the most common bottleneck in any system, causing a
slowdown that is evident to users. It’s the first issue you should look
at when server issues appear. With the introduction of 64-bit computing,
you have the luxury of servers supporting literally terabytes of RAM.
If your application requires that much RAM that users must access, you
can probably find room for performance enhancements. However, 64-bit
computing can help applications that have high memory requirements scale
better than running the applications on a 32-bit platform.
What Causes Memory Pressure?
Normally, Web
applications that consume memory by design or due to poor code
implementation lead to bottlenecks. You can identify many memory
bottlenecks during testing or during a pilot of your application.
Following proper development processes and stress testing at the early
stages can help minimize the pressure.
With the ever-growing
list of features and situations an application must handle, you
should—first and foremost—not push more data or information to the
client. In a distributed environment, typical Web applications can try
to select and cache 10,000 records. Imagine hundreds of people hitting
your Web site at the same time. If your information has been cached on
the server, the lack of available memory available on the server can
affect your application performance.
Memory Counters to Monitor
Table 1
lists common memory counters that help identify which processes and how
many of the server resources are being used when your IIS 7.0 server is
experiencing high memory conditions.
Table 1. Memory Counters to Measure
| Counter Name | Description |
|---|
| Memory\Available Mbytes | The
amount of physical memory, in megabytes, immediately available for
allocation to a process or for system use. It is equal to the sum of
memory assigned to the standby (cached), free, and zero page lists. For a
full explanation of the memory manager, refer to MSDN and/or the System
Performance and Troubleshooting Guide chapter in the Microsoft Windows Server 2003 Resource Kit (Microsoft Press, 2005). |
| Memory\Cache Faults/sec | The
rate at which faults occur when a page sought in the file system cache
is not found and must be retrieved from elsewhere in memory (a soft
fault) or from disk (a hard fault). The file system cache is an area of
physical memory that stores recently used pages of data for
applications. Cache activity is a reliable indicator of most application
I/O operations. This counter shows the number of faults, without regard
for the number of pages faulted in each operation. |
| Memory\Demand Zero Faults/sec | The
rate at which a zeroed page is required to satisfy the fault. Zeroed
pages, pages emptied of previously stored data and filled with zeros,
are a security feature of Windows that prevent processes from seeing
data stored by earlier processes that used the memory space. Windows
maintains a list of zeroed pages to accelerate this process. This
counter shows the number of faults, without regard to the number of
pages retrieved to satisfy the fault. This counter displays the
difference between the values observed in the last two samples, divided
by the duration of the sample interval. |
| Memory\Pages/sec | The
rate at which pages are read from or written to disk to resolve hard
page faults. This counter is a primary indicator of the kinds of faults
that cause system-wide delays. It is the sum of Memory\\Pages Input/sec
and Memory\\Pages Output/sec. It is counted in numbers of pages, so it
can be compared to other counts of pages, such as Memory\\Page
Faults/sec, without conversion. It includes pages retrieved to satisfy
faults in the file system cache (usually requested by applications) and
non-cached mapped memory files. |
| Memory\Transition Faults/sec | The
rate at which page faults are resolved by recovering pages that were
being used by another process sharing the page, or were on the modified
page list or the standby list, or were being written to disk at the time
of the page fault. The pages were recovered without additional disk
activity. Transition faults are counted in numbers of faults; because
only one page is faulted in each operation, it is also equal to the
number of pages faulted. |
| Process(inetinfo)\% Processor Time | The
percentage of elapsed time that all process threads used the processor
to execution instructions. An instruction is the basic unit of execution
in a computer, a thread is the object that executes instructions, and a
process is the object created when a program is run. Code executed to
handle some hardware interrupts and trap conditions are included in this
count. |
| Process(w3wp)\% Processor Time | |
| Process(w3wp)\Handle Count | The
total number of handles currently open by this process. This number is
equal to the sum of the handles currently open by each thread in this
process. |
| Process(w3wp)\ID Process | The
unique identifier of this process. ID Process numbers are reused, so
they only identify a process for the lifetime of that process. |
| Process(w3wp)\Private Bytes | The current size, in bytes, of memory that this process has allocated that cannot be shared with other processes. |
| Process(w3wp)\Thread Count | The
number of threads currently active in this process. An instruction is
the basic unit of execution in a processor, and a thread is the object
that executes instructions. Every running process has at least one
thread. |
| Process(w3wp)\Virtual Bytes | The
current size, in bytes, of the virtual address space the process is
using. Use of virtual address space does not necessarily imply
corresponding use of either disk or main memory pages. Virtual space is
finite, and the process can limit its ability to load libraries. |
| Process(w3wp)\Working Set | The
current size, in bytes, of the Working Set of this process. The Working
Set is the set of memory pages touched recently by the threads in the
process. If free memory in 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 a threshold, pages are trimmed from Working
Sets. If they are needed, they will then be soft-faulted back into the
Working Set before leaving main memory. |
Impact of Constraints
When
a server is low on RAM, it uses the paging file, causing the worker
process to have to retrieve data from disk, slowing down performance.
This can be an expensive operation, because the application has
introduced another potential bottleneck, Disk I/O (Input/Output). An
application that is forced to use a portion of the information swapped
to the paging file has added latency and causes the server to use more
resources.
Generally,
with 32-bit operating systems, the recommended approach is to set the
paging file size to be 1.5 times the amount of RAM. In a 64-bit
environment, you can set the operating system to automatically handle
the paging file size.
Countermeasures
One
countermeasure against memory pressure is to verify that your Web server
paging file is configured properly and optimized on a separate set of
disks. Spreading a paging file across separate physical disks enables
you to improve paging file performance by using drives that do not
contain your site’s content or log files. Although these steps are
basic, they can go a long way toward helping your application’s
performance. They can also save your company money by getting the most
out of your servers.
Understanding how many
resources a typical transaction uses is important. This number can be
valuable when you calculate what your production environment and
monitoring thresholds will be. If your database holds a lot of detail
data, you can calculate how the data might grow over a period of months
or years and how this might impact your application. It might perform
well at first, but you might find that as the amount detail data grows,
your application will be slower, and server performance will suffer.
