Tips for improving Active Directory performance on servers
Striking the right balance of memory and disk performance can help optimize Active Directory performance.
Active Directory is installed and run from network servers, so ensuring good performance of the physical server will have a direct impact on the performance of the domain controller -- and on network availability for users.
The main directory service for Windows networks, Active Directory (AD), provides a single manageable point for network administration and security functions. Domain controllers running Active Directory must authenticate every computer on the network and enforce relevant security policies. For example, when a user logs on to the company network, Active Directory authenticates the logon credentials. Let's consider some of the factors that influence AD server performance.
Active Directory needs memory
Memory space is an important attribute of Active Directory servers, so IT administrators should deploy domain controllers on servers that provide ample amounts of memory. The ultimate goal is to provide enough memory to cache the entire Active Directory database, yet still have enough memory space available to support AD database growth over time. With enough memory, the AD server is far less dependent on disk access, and the system's apparent performance is vastly improved.
For contemporary operating systems such as Windows Server 2008 R2, the AD database for an enterprise-level domain controller can easily exceed 4 to 6 GB. In order to cache this entire data set in memory, a 64-bit server would be absolutely essential to support the necessary volume of addressable memory space (and is a system requirement for the operating system anyway). This means that older domain controllers or systems with limited memory can be upgraded as part of a future technology refresh cycle.
Incorporating the right amount of memory can be tricky, since there are no absolute sizing rules. One rule of thumb is to provide twice as much memory as the AD database on disk. For example, if the NTDS.DIT and SYSVOL sizes add up to 4 GB, a server with 8 GB of memory should be more than enough to cache the entire AD database.
But this usually overkill, because only a small fraction of the AD database is actually used frequently. It may be more efficient to provide less memory and allow the memory to cache the most frequently accessed part of the AD database, then access the remainder from disk as needed. In this case, check to see just how many AD operations are coming from the cache.
One way to do that is to use the Windows Perfmon utility to check the Database Cache % Hit and database cache size (in MB) performance counters under the LSAAS.EXE instance for AD Domain Services. If you're only using AD Lightweight Directory Services, you can find the same database cache % hit and database cache size counters under the Directory instance.
Higher cache hit numbers mean that a higher percentage of AD operations are coming from cache (memory) rather than from disk -- this is desirable. If the cache hit or cache size numbers seem unacceptably low, adding more memory to the server might improve AD caching performance. Just remember to monitor this value over a few hours of normal operation well after the domain controller has booted.
Disk performance and Active Directory
Although it would be ideal to cache the entire Active Directory database in the domain controller's memory, it's still important to weigh the role of the disk subsystem in AD performance. After all, disk access is needed to load the server's memory with the database. If the entire database won't fit in memory, additional disk access will be needed for uncached portions of the database. Disk access is also needed when writing changes to the database. The trick is to make choices that will optimize AD disk access.
Look for disk subsystem performance features such as command queuing, often available in serial attached SCSI disk systems. Also, pay attention to the way AD files are organized. For example, it's usually a good idea to locate the AD folder on a physical volume that is separate from the AD log folder and the operating system volume. This spreads out disk access across different spindles and ensures that AD data files, AD data recovery files and operating system files are not all contending for the same spindle.
In addition, AD completes all of its writes rather than caching its writes. This protects against possible AD database corruption if a cached change is not completed. But this also means disk I/O plays a major role in AD disk access. So, fast, low-latency disks are most beneficial, and RAID controllers should include a battery backup for writes.
You can measure disk performance by watching the average disk queue length performance counter on the disk volumes that contain the AD database and logs. You can also track the average disk-read queue length and the average disk-write queue length performance counters. Long queues mean poor disk performance, so moving the folders to a different or better-performing disk might help AD performance during disk writes.
Active Directory is a critical service for enterprise network authentication, which can be optimized with some simple performance monitoring and basic upgrades or architectural changes to the server and storage access. Adding memory can allow the domain controller to cache more of the AD database and alleviate reading bottlenecks, while careful storage decisions can help to reduce AD writing congestion. The result is faster, problem-free authentication for users.
