Abstract
This chapter examines Windows NT's memory and processing subsystems and the features and techniques NT uses to maximize the performance of each. In addition, the chapter looks at a variety of methods for monitoring memory and processor utilization levels, including physical memory, the NT paging file, and the system processors.
TWO OF THE COMPONENTS that greatly affect the performance of any computer operating system are the amount of physical memory (RAM) present and the speed of the system’s processor(s). In fact, with Windows NT, memory is so vitally important that a deficiency easily impedes the performance of virtually every component of NT, including the application, hard drive(s), and network subsystems. Processor bottlenecks can be equally devastating because every process in the system is dependent upon the processor to carry out its threads of execution in a timely manner. When the processor becomes overloaded, the performance of the operating system and user applications are dragged to their knees as they wait for processor time.
Arming yourself with some of the techniques that allow you to identify situations where memory is a bottleneck ensures this situation doesn’t occur. However, this isn’t always easy; because memory shortages can show up as a symptom with many subsystems, it is often difficult to detect the true source of a performance bottleneck. In many cases, the symptoms may point to some other system component (such as the hard drive or system cache) rather than memory. Using the techniques in this chapter will enable you to properly identify whether memory is the problem and empower you to solve the problem quickly and efficiently, reducing the amount of time spent chasing performance “ghosts.”
THE WINDOWS NT MEMORY MODEL
As part of its 32-bit design, Windows NT has processing, memory, and application management features that make it an extremely powerful and robust operating system.
Also as part of its design, NT contains two separate and distinct components that together comprise the core services of the NT operating system: the Windows NT Kernel and Executive. The Windows NT Kernel (also referred to as the Microkernel, the type of operating system architecture used by NT) is the set of core, essential services that perform a number of low-level operating system functions such as the scheduling of thread execution. The Kernel works in conjunction with the Hardware Abstraction Layer (HAL), which gains its name from the fact that it provides a middle layer (i.e., it abstracts) between Windows NT’s core operating system services and the actual hardware in use on the system (e.g., Intel versus Alpha-based, uniprocessor versus multiprocessor, etc.).
There are three key components responsible for the processing and memory management features provided by Windows NT of the Windows NT operating system:
Virtual Memory Manager (part of the Windows NT Executive): At the heart of Windows NT’s memory management scheme is the Virtual Memory Manager. The Virtual Memory Manager maps virtual addresses in the process’s address space to physical pages in the computer’s memory. It hides the physical organization of memory from the process’s threads to ensure that threads can access their own memory but not the memory of other processes.
Process Manager (part of the Windows NT Executive): The Process Manager is the operating system component that creates and deletes processes (applications or modular parts of programs) and manages process and thread objects. It also provides a standard set of services for creating and using threads and processes in a particular subsystem environment.
Thread Dispatcher (part of the Windows NT Kernel): Among the duties of the NT Kernel is the scheduling of execution for the threads of running processes on the system. Threads can also be executed in a uniform way across all available processors, which is part of NT’s Symmetric Multiprocessing (SMP) architecture.
The Windows NT Architecture (for Windows NT version 4.0) is shown in Figure 5-1.
We touch upon each of these components and the roles they play in Windows NT system operation and performance throughout the rest of this chapter.
Virtual memory: Just like the real thing
As a 32-bit operating system, Windows NT is able to provide access to memory in a way that 16-bit operating systems simply cannot. NT uses a flat (linear) 4GB virtual memory model and address space that is available to all applications on the system. This 4GB-per-process availability is divided as follows: 2GB are visible to each process while it executes in Kernel Mode (where NT’s low-level services execute, which runs in processor Ring 0), with the other 2GB being visible to the process while it executes in User Mode (the mode where user applications execute, which runs in the processor Ring 3).
However, unless you’ve got a really big budget for memory purchases, it’s unlikely that you’ll ever have a system with anywhere close to 4GB of memory. So, how does Windows NT provide this kind of memory to applications? The answer is virtual memory. One of the advantages of NT’s 32-bit flat memory model is that it provides a logical view of system memory that is independent of the actual physical RAM installed on the machine.
NOTE: NT’s 32-bit flat memory model is one of the reasons it is a portable operating system, because this memory architecture is compatible with the memory addressing of many processors, including Intel, DEC Alpha, MIPS, and PowerPC.
This logical view of memory is referred to as virtual memory because it isn’t always composed of real, physical memory chips. However, Windows NT is capable of producing more memory for system functions and applications that are physically present in the machine through the Windows NT paging file, a topic we delve further into later. The nice thing about virtual memory is that applications treat it exactly as if it were real memory; it’s up to the operating system to actually go out and do the legwork of identifying exactly where a particular referenced piece of memory is located. This creates enormous flexibility for both the operating system and user applications, and provides the ability for a Windows NT computer to extend beyond its physical memory (RAM) constraints.
With virtual memory, programs use virtual addresses rather than physical memory addresses to reference data in memory. Whenever an application attempts to access memory using a virtual address, the operating system invisibly goes out and performs a translation of the virtual memory address supplied to a real physical location, either in physical RAM or in virtual memory located on a system disk drive. The application is none the wiser and never knows what went on behind the scenes to resolve the memory reference.
In Windows NT, the system component responsible for managing the relationship between virtual memory and the physical organization of memory (on physical devices such as RAM and hard drives) is called the Virtual Memory Manager. The VMM is a component of the Windows NT Executive layer of services, which run in privileged or Kernel Mode. The VMM is Windows NT’s memory management arm and makes it possible for applications to abstract physical memory addresses and use logical ones. To accomplish this, the VMM maintains data structures (such as lookup tables) that allow it to translate virtual memory addresses to physical ones.
The VMM maintains separate address translation tables for each process running on the system. These tables contain entries that determine how virtual addresses are translated to physical addresses, which essentially means the pages in RAM that the process may access (i.e., are within the process’s address space). Although there are a few special cases where two or more processes will reference the same page of physical memory, generally speaking, each process on the system runs within a private address space. That is to say, the memory address space for each process is private to that process, meaning that each process’s physical memory is generally protected from that of other processes. This memory protection feature is one reason for Windows NT’s superior stability.
Paging Dr. Memory
Memory in Windows NT is divided into two separate types: nonpaged and paged pool memory. Nonpaged memory has the requirement that it must reside in actual physical memory (i.e., RAM) and cannot be written to or read from peripheral devices on the system (including hard drives, network adapters, and CD-ROM drives). Paged memory, on the other hand, is memory that the system can use to hold memory pages from peripheral devices such as hard disks, network adapters, and the like.
As you may have noticed, both of these terms incorporate the word page. A page is the basic unit of memory on a Windows NT system and varies depending on the hardware platform in use. For example, Intel-based systems all use a page size of 4096 bytes (4K), while RISC processors such as the Alpha and MIPS processors use a page size of 8192 bytes (8K). This is important to remember whenever a discussion of memory pages arises in relation to Windows NT, because ten pages of data on one system is not necessarily the same amount of information on another system.
NOTE: Variable page sizes are used to optimize memory performance for a specific processor architecture. This variance in page sizes is also the reason why most (but not all) Performance Monitor counters refer to bytes rather than pages — bytes are absolute while pages are a relative reference.
PAGE FRAMES
Paged pool memory is further organized into structural divisions called page frames. When a memory page (either program code or data) is requested from a peripheral device, the Windows NT Virtual Memory Manager finds an available page frame in memory for the requested page. Once located, the memory manager then retrieves the page and processing continues. If there are no free page frames, the memory manager has to find one that it can reuse. When doing so, the memory manager will always try to use a page frame that is “stale”; that is, one that hasn’t been used for a while. When the memory manager finds a page frame to reuse, it discards the page it contains (so long as the page hasn’t been modified since it was put into RAM). If the page has been changed, it is first written back to the peripheral device before the new page is written into the frame to replace it.
PAGE FAULTS
While processing memory, if a request is made for a memory page that isn’t currently within the set of pages visible to the process in RAM (known as the working set of the process), an event known as a page fault occurs. Page faults are resolved by the memory manager by locating the request page either elsewhere in RAM (known as a soft page fault) or from a peripheral device (e.g., virtual memory in the paging file located on a hard drive; this is known as a hard page fault).
Despite their harsh-sounding name, page faults are a fairly common event on any Windows NT computer. A page fault might occur because the requested page is currently in the working set of some other process, or it might have been removed from this process’s working set by the memory manager in an attempt to free up memory for other processes on the system. Memory pages removed from a process’s working set for the latter reason are referenced in a list of page frames called the standby list, which can be used to quickly locate and restore the page to the process’s working set.
Although page faults are inevitable in Windows NT, excessive page faults (especially hard page faults, which must retrieve data from the hard drive) will slow performance. For soft page faults, the Virtual Memory Manager typically gives a temporary boost to the working set of the offending process in an effort to reduce the number of page faults. Excessive hard page faults, however, aren’t quite so easy to fix. This situation typically occurs when the system is low on memory and the Windows NT memory manager is working furiously and continuously to balance the distribution of an insufficient amount of physical RAM between a number of different processes that are demanding it (a situation that involves a great deal of paging file activity, as memory pages are swapped back and forth from real physical RAM to disk). As a result, given the same total working set on the system, the only real solution to excessive hard page faults is adding more RAM.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
