You can improve the performance of Active Directory®, especially in large environments, by following these tuning steps:
Increase address space by using 64-bit processors.
64-bit architecture is preferred for running Active Directory. The large address space makes it possible to equip the server with enough RAM to cache all or most of the Active Directory database in memory. It also provides room for expansion to add RAM if the database size grows. For more information, see the article about Active Directory performance on 64-bit processors in "Resources" later in this guide. Note that Windows Server 2008 R2 is supported only on 64-bit processors.
Use an appropriate amount of RAM.
Active Directory uses the server’s RAM to cache as much of the directory database as possible. This reduces disk access and improves performance. The Active Directory cache in Windows Server 2008 R2 is permitted to grow. However, it is still limited by the virtual address space and how much physical RAM is on the server.
To determine whether more RAM is needed for the server, monitor the percentage of Active Directory operations that are being satisfied from the cache by using the Reliability and Performance Monitor. Examine the lsass.exe instance (for Active Directory Domain Services) or Directory instance (for Active Directory Lightweight Directory Services) of the Database\Database Cache % Hit performance counter. A low value indicates that many operations are not being satisfied from the cache. Adding more RAM might improve the cache hit rate and the performance of Active Directory. You should examine the counter after Active Directory has been running for several hours under a typical workload. The cache starts out empty when the Active Directory service is restarted or the machine is rebooted, so the initial hit rate is low.
The use of the Database Cache % Hit counter is the preferred way to assess how much RAM a server needs. Or, a guideline is that when the RAM on a server is twice the physical size of the Active Directory database on disk, it likely gives sufficient room for caching the entire database in memory. However, in many scenarios this is an overestimation because the actual part of the database frequently used is only a fraction of the entire database.
Use a good disk I/O subsystem.
Ideally, the server is equipped with sufficient RAM to be able to cache the “hot” parts of the database entirely in memory. However, the on-disk database must still be accessed to initially populate the memory cache, when it accesses uncached parts of the database, and when it writes updates to the directory. Therefore, appropriate selection of storage is also important to Active Directory performance.
We recommend that the Active Directory database folder be located on a physical volume that is separate from the Active Directory log file folder. In the Active Directory Lightweight Directory Services installation wizard, these are known as data files and data recovery files. Both folders should be on a physical volume that is separate from the operating system volume. The use of drives that support command queuing, especially Serial Attached SCSI or SCSI, might also improve performance.
Considerations for Read-Heavy Scenarios
The typical directory workload consists of more query operations than update operations. Active Directory is optimized for such a workload. To obtain the maximum benefit, the most important performance tuning step is to make sure that the server has sufficient RAM to be able to cache the most frequently used part of the database in memory. Query performance on a freshly rebooted server, or after the Active Directory service has been restarted, might initially be low until the cache is populated. Active Directory automatically populates the cache as queries visit parts of the directory.
Considerations for Write-Heavy Scenarios
Write-heavy scenarios do not benefit as much from the Active Directory cache. To guarantee the transactional durability of data that is written to the directory, Active Directory does not cache disk writes. It commits all writes to the disk before it returns a successful completion status for an operation, unless explicitly requested not to do this. Therefore, fast disk I/O is important to the performance of writes to Active Directory. The following are hardware recommendations that might improve performance for these scenarios:
Hardware RAID controllers.
Low-latency/high-RPM disks.
Battery-backed write caches on the controller.
To determine whether disk I/O is a bottleneck, monitor the Physical Disk\Average Disk Queue Length counter for the volumes on which the Active Directory database and logs are located. A high queue length indicates a large amount of concurrent disk I/O activity. Choosing a storage system to improve write performance on those volumes might improve Active Directory performance.
Using Indexing to Improve Query Performance
Indexing of attributes is useful when you search for objects that have the attribute name in the filter. Indexing can reduce the number of objects that must be visited when you evaluate the filter. However, this reduces the performance of write operations because the index must be updated when the corresponding attribute is modified or added. It also increases the size of your directory database. You can use logging to find the expensive and inefficient queries and consider indexing some attributes that are used in the corresponding queries to improve the search performance. For more information on Active Directory event logging on servers, see "Resources" later in this guide.
Optimizing Trust Paths
Trusts are a way to enable users to authenticate across different forests or domains. If the trust path between the resource and the user is long, then the user might experience high latency because the authentication request must travel through the trust path and return. For example, if a user from the grandchild of a domain tries to log on from a different grandchild in the same forest, the authentication request must travel up the chain from the grandchild to the root and then take the path to the other grandchild. To avoid this, you can create a shortcut trust directly between the two grandchild domains that avoids the long path. However, the administrator must manage trusts. Therefore you must consider how frequently a given trust will be used before you create it. You can create “external trusts” to reduce the trust path when authenticating between inter-forest domains.
Active Directory Performance Counters
You can use several resources to conduct performance diagnosis of a domain controller that is not performing as expected.
You can use the following Reliability and Performance Monitor (Perfmon) counters to track and analyze a domain controller’s performance:
If you notice slow write or read operations, check the following disk I/O counters under the Physical Disk category to see whether many queued disk operations exist:
Avg. Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length
If lsass.exe uses lots of physical memory, check the following Database counters under the Database category to see how much memory is used to cache the database for Active Directory Domain Services. These counters are located under the lsass.exe instance, whereas for Active Directory Lightweight Directory Services they are located under the Directory instance:
Database Cache % Hit
Database Cache Size (MB)
If Isass.exe uses lots of CPU, check Directory Services\ATQ Outstanding Queued Requests to see how many requests are queued at the domain controller. A high level of queuing indicates that requests are arriving at the domain controller faster than they can be processed. This can also lead to a high latency in responding to requests.
You can also use the Data Collector Sets tool that is included with Windows Server 2008 R2 to see the activity inside the domain controller. On a server on which the Active Directory Domain Services or Active Directory Lightweight Directory Services role has been installed, you can find the collector template in Reliability and Performance Monitor under Reliability and Performance > Data Collector Sets > System > Active Directory Diagnostics. To start it, click the Play icon.
The tool collects data for five minutes and stores a report under Reliability and Performance > Reports > System > Active Directory Diagnostics. This report contains information about CPU usage by different processes, Lightweight Directory Access Protocol (LDAP) operations, Directory Services operations, Kerberos Key Distribution Center operations, NT LAN Manager (NTLM) authentications, Local Security Authority/Security Account Manager (LSA/SAM) operations, and averages of all the important performance counters. This report identifies the workload that is being placed on the domain controller, identifies the contribution of different aspects of that workload to the overall CPU usage, and locates the source of that workload such as an application sending a high rate of requests to the domain controller. The CPU section of the report indicates whether lsass.exe is the process that is taking highest CPU percentage. If any other process is taking more CPU on a domain controller, you should investigate it.
Performance Tuning for Remote Desktop Session Host (formerly Terminal Server)
This section discusses the selection of Remote Desktop Session Host (RD Session Host) hardware, tuning the host, and tuning applications. The following white papers describe the most relevant factors that influence the capacity of a given RD Session Host deployment, methodologies to evaluate capacity for specific deployments, and a set of experimental results for different combinations of usage scenarios and hardware configurations:
“RD Session Host Capacity Planning in Windows Server 2008 R2”
“RD Virtualization Host Capacity Planning in Windows Server 2008 R2”
For links to these papers, see “Resources” later in this guide.
Selecting the Proper Hardware for Performance
In an RD Session Host, the choice of hardware is governed by the application set and how the users exercise it. The key factors that affect the number of users and their experience are CPU, memory, disk, and graphics. Earlier in this guide was a discussion on server hardware guidelines. Although these guidelines still apply in this role, this section contains additional guidelines that are specific to RD Session Host Servers, mostly related to the multiuser environment of RD Session Host Servers.
CPU Configuration
CPU configuration is conceptually determined by multiplying the required CPU to support a session by the number of sessions that the system is expected to support, while maintaining a buffer zone to handle temporary spikes. Multiple processors and cores can help reduce abnormal CPU congestion situations, which are usually caused by a few overactive threads that are contained by a similar number of cores. Therefore, the more cores on a system, the lower the cushion margin that must be built into the CPU usage estimate, which results in a larger percentage of active load per CPU. One important factor to remember is that doubling the number of CPUs does not double CPU capacity. For more considerations, see “Choosing and Tuning Server Hardware” earlier in this guide.
Processor Architecture
The 64-bit processor architecture provides a significantly higher kernel virtual address space, which makes it much more suitable for systems that need large amounts of memory. Specifically, the x64 version of the 64-bit architecture is the more workable option for RD Session Host deployments because it provides very small overhead when it runs 32-bit processes. The most significant performance drawback when you migrate to 64-bit architecture is significantly greater memory usage.
Memory Configuration
It is difficult to predict the memory configuration without knowing the applications that users employ. However, the required amount of memory can be estimated by using the following formula:
TotalMem = OSMem + SessionMem * NS
OSMem is how much memory the operating system requires to run (such as system binary images, data structures, and so on), SessionMem is how much memory processes running in one session require, and NS is the target number of active sessions. The amount of required memory for a session is mostly determined by the private memory reference set for applications and system processes that are running inside the session. Shared pages (code or data) have little effect because only one copy is present on the system.
One interesting observation is that, assuming the disk system that is backing the pagefile does not change, the larger the number of concurrent active sessions the system plans to support, the bigger the per-session memory allocation must be. If the amount of memory that is allocated per session is not increased, the number of page faults that active sessions generate increases with the number of sessions and eventually overwhelms the I/O subsystem. By increasing the amount of memory that is allocated per session, the probability of incurring page faults decreases, which helps reduce the overall rate of page faults.
Disk
Storage is one of the aspects most often overlooked when you configure an RD Session Host system, and it can be the most common limitation on systems that are deployed in the field.
The disk activity that is generated on a typical RD Session Host system affects the following three areas:
System files and application binaries
Pagefiles
User profiles and user data
Ideally, these three areas should be backed by distinct storage devices. Using striped RAID configurations or other types of high-performance storage further improves performance. We highly recommend that you use storage adapters with battery-backed caches that allow writeback optimizations. Controllers with writeback caches offer improved support for synchronous disk writes. Because all users have a separate hive, synchronous disk writes are significantly more common on an RD Session Host system. Registry hives are periodically saved to disk by using synchronous write operations. To enable these optimizations, from the Disk Management console, open the Properties dialog box for the destination disk and, on the Policies tab, select the Enable write caching on the disk and Enable advanced performance check boxes.
For more specific storage tunings, see the guidelines in “Performance Tuning for the Storage Subsystem” earlier in this guide.
Network
Network usage includes two main categories:
RD Session Host connections traffic in which usage is determined almost exclusively by the drawing patterns exhibited by the applications that are running inside the sessions and the redirected devices I/O traffic.
For example, applications handling text processing and data input consume bandwidth of approximately 10 to 100 kilobits per second, whereas rich graphics and video playback cause significant increases in bandwidth usage. We do not recommend video playback over RD Session Host connections because desktop remoting is not optimized to support the high frame rate rendering that is associated with video playback. Frequent use of device redirection features such as file, clipboard, printer, or audio redirection also significantly increases network traffic. Generally, a single 1-gigabit adapter is satisfactory for most systems.
Back-end connections such as roaming profiles, application access to file shares, database servers, e-mail servers, and HTTP servers.
The volume and profile of network traffic is specific to each deployment.
|
