Tuning Windows 2012 – Active Directory – Part 1

In this new series of articles we’ll discuss improving the performance of Active Directory Servers.  You can improve the performance of Active Directory, by following these tuning steps:


Use an appropriate amount of RAM


Active Directory uses RAM to cache as much of the directory database as possible. This reduces disk access and improves performance. The Active Directory database can grow, but the amount of data that can be cached is limited by the virtual address space and how much physical RAM is on the server.


If you want 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 the 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 when the computer is rebooted, so the initial hit rate is low.


Use a good disk I/O subsystem


Ideally, the server is equipped with sufficient RAM to cache the “hot” parts (that is, the most frequently parts) of the database entirely in memory. However, the on-disk database must 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, an appropriate selection for storage is 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. 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 cache the most frequently used part of the database in memory. Query performance on a recently rebooted server, or after the Active Directory service is restarted, might initially be low until the cache is populated. Active Directory automatically populates the cache as queries search data in the directory.


Considerations for Write-Heavy Scenarios


In a write-heavy scenario, Active Directory does not benefit as much from the cache. To guarantee the transactional durability of data that is written to the directory, Active Directory does not perform disk write caching It commits all write operations to the disk before it returns a successful completion status for an operation, unless there is an explicit request to not do this. Therefore, fast disk I/O is important to the performance of write operations 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 caching 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 attributes is useful when you search for objects that have the attribute name in a 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 then consider indexing some attributes that are used in the corresponding queries to improve the search performance.


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 sign in from a different grandchild domain in the same forest, the authentication request must travel trust path from the grandchild to the root domain and then take the path to the other grandchild domain.


To avoid this, you can create a shortcut trust directly between the two grandchild domains that avoids the long path. However, an administrator must manage trusts. Therefore, you must consider how frequently a given trust will be used before you create it. You can also create an external trust or a forest trust to reduce the trust path when authenticating between domains in different forests.


In our next article, we’ll discuss Active Directory performance counters for Windows 2012 Server.