There are many factors that can impact Active Directory’s
performance. The key is just finding out what’s causing things to go so slowly.
In this article, I’ll explain how you can use the Performance Monitor to gain a
better understanding of the factors that are affecting the Active Directory’s
performance.

Before I begin

In this article, I will be making extensive use of the
Windows Performance Monitor. Before I jump right in and start talking about
which counters you should be monitoring, I want to go over a few performance
monitoring best practices. The best practices that I am going to go over don’t
always apply to every performance monitoring session, but they do apply to this
article.

The Uncertainty Principle in physics states that it is
impossible to measure something without affecting it to some degree. Nowhere is
this more true than with Performance Monitoring. When following the techniques
in this article, you will be monitoring systems that are already having
performance problems. The monitoring process is only going to make those
performance problems worse because resources such as memory, CPU time, disk
space, and disk time are used by the Performance Monitor.

That being the case, you should start out by taking some
steps to lighten the existing load on the servers that you will be monitoring.
The easiest way to reduce the system’s workload is to disable the screen saver
and any services that are not absolutely necessary. Be sure to make note of
what you have disabled though. It’s possible that the Performance monitor may
not reveal any performance problems. If that happens, then one possible cause
is that something that you disabled was causing the performance problem.

Another step that I recommend taking in preparation for the
monitoring process is to increase the amount of virtual memory that is
available to the servers that you will be monitoring. The minimum amount of
virtual memory that any of the servers should have is one and a half times the
amount of physical memory in the machine. Therefore, if the server has a
gigabyte of RAM, then you will want to make sure that the machine’s virtual
memory is set to a minimum size of 1.5 GB.

The last thing that I want to talk about in regards to the
monitoring process is that you need to conduct the performance monitoring
session in a way that minimizes the amount of monitoring related overhead
placed on the server that’s being monitored. Unless your network is short on
bandwidth, or there is a WAN link between you and the server that you are monitoring,
I recommend monitoring the machine remotely. This means that you actually run
Performance Monitor on a workstation, but tell it to monitor one of your
servers. The advantage of doing this is that it will conserve both memory and
processing power on the server that you are monitoring because you are not
running the Performance Monitor user interface directly on that machine.

I was hesitant the first time that someone gave me this
advice, so I decided to do some benchmark testing of my own, and there really
is a noticeable difference when Performance Monitor is run remotely. You should
not however run Performance Monitor remotely if you have issues with low
bandwidth, or if you are trying to measure network traffic or network
throughput.

If you find that you need to run Performance Monitor
locally, then one way that you can minimize its impact is to log data to a hard
disk that is not going to be affected by the monitoring process. For example,
if the server that you are monitoring acts as both a domain controller and a
file server, then you know that which ever drive contains the Active Directory
database (C:\NTDS by default) is going to be heavily used. Therefore, if D: is
only storing user files, then that might be a good place to log the collected
data.

Regardless of whether you are monitoring the server remotely
or locally, I recommend adjusting the update interval so that you are sampling
the counter data at no more than once every three seconds. Performance Monitor
usually samples counters once a second by default, but decreasing the sampling
rate will greatly decrease Performance Monitor’s impact on the system and give
you a more realistic reading.

One last tip that I have for you is that you should refrain
from monitoring more than three or four counters at a time. The fewer counters
you are monitoring simultaneously, the more accurate the results are going to
be.

The Directory Service

Now that I have given you some best practices that you can
use to get greater accuracy on your measurements, it’s time to get down to
business by talking about some Performance Monitor counters that are associated
with the Directory Service. Directory Service related counters are located
within the NTDS performance object. There are dozens of Directory Service related
counters available, but there are only about ten counters that you really need
to pay attention to.

  • DRA Inbound Bytes Total / Sec – This
    counter shows the number of bytes received
    through inbound Active Directory related replication. If this number is
    consistently equal to zero, it means that replication is not occurring.
    Low numbers may indicate that there is a network bottleneck or that the
    server’s NIC is too busy with other traffic to receive the requests in a
    timely manner.
  • DRA Inbound Object Updates Remaining
    in Packet –
    This counter displays the number of Active Directory
    objects that have been received through replication, but that have not yet
    been applied. This number may start high, but should diminish very
    quickly. If this value takes a while to diminish, it is a clue that the
    server’s hardware might not be fast enough to keep up with the demand.
  • DRA Outbound Bytes Total / Sec – This
    counter displays the total number of bytes (compressed and uncompressed)
    that are being transmitted each second as a result of the replication
    process. A lack of activity often indicates insufficient hardware.
  • DRA Pending Replication
    Synchronization –
    This number indicates the number of objects which
    must be synchronized. Like the DRA Inbound Object Updated Remaining in
    Packet counter, this value may start high, but should quickly dissipate.
    If this counter’s value remains high, it usually means that the hardware
    is having trouble keeping pace with the demands being made of it.
  • DS Threads in Use – This counter indicates
    the number of threads that are currently servicing client API calls. You
    can use this value to determine whether or not the domain controller could
    benefit from additional processors.
  • Kerberos Authentications – The
    value from this counter indicates the number of times each second that
    clients use a ticket to authenticate to the domain controller. A lack of
    activity sometimes indicates that network problems are preventing requests
    from reaching the domain controller.
  • LDAP Bind Time – This counter indicates
    the number of milliseconds that the last successful LDAP bind took to
    complete. This value should remain consistently low. Longer bind times can
    be an indication of network problems or of hardware that needs to be
    upgraded.
  • LDAP Client Sessions – This number
    indicates the number of LDAP sessions that are connected to the domain
    controller at the moment. The appropriate value depends on your network,
    but if this value remains at zero, it means that you probably have some
    network problems that are preventing client sessions from connecting with
    the server.
  • LDAP Searches / Sec – The LDAP
    Searches / Sec counter indicates the number of LDAP queries made by
    clients each second. I recommend viewing this counter along with the LDAP
    Successful Binds / Sec counter, which shows the number of successful LDAP
    binds each second. The biggest thing that you are looking for in these two
    counters is activity. A lack of activity would almost always indicate that
    network problems are disrupting the client’s ability to interact with the
    domain controller.

The database

As I’m sure you know, the Active Directory is a database
that physically resides on your domain controllers. As such, it makes sense to
examine some database related Active Directory counters when trying to
troubleshoot Active Directory performance problems. The counters that I will be
discussing in this section are accessible through the Database performance
object.

General performance monitoring

Now that I have gone over some of the more important
Performance Monitor counters that are directly related to troubleshooting
Active Directory performance, I want to take a few moments and discuss some
counters that you can use for general performance troubleshooting. If you find
out that your DNS server is not performing adequately, then you might want to
upgrade it. First you should use the
Performance Monitor to figure out where the real problems are. The techniques
that I am about to show you can help you to find performance related problems
on your DNS servers, domain controllers, or on any other type of server.

Memory

When you are performing general performance monitoring, in
search of system bottlenecks, you should always start by checking the
Performance Monitor counters related to memory. The reason for this is that if
the system is low on memory, it can produce symptoms that make the system
appear that the CPU or the hard disk is actually casing the problem. If you
were to test the CPU or hard disk first, and encountered such symptoms, then
you might assume that you had found the problem and never realize that memory
was the real culprit.

When testing the system’s memory, you will want to use the
counters found within the Memory performance object to look for signs that the
system has insufficient RAM. There are a number of counters available, but the
ones that I am about to discuss are the most important:

  • PAGES/SEC – The PAGES/SEC counter
    indicates the number of times each second when the system must access
    virtual memory. Anything over 20 is considered to be a problem. If you
    experience high values, then it means that the system is either short on
    RAM or that the system’s virtual memory is configured incorrectly.
  • Committed Bytes and Available Bytes – The committed bytes and available bytes counters work in opposition to
    each other. The Available bytes counter indicates how much memory is
    available, while the committed bytes counter indicates how much of the
    virtual memory is being used. As the available bytes counter decreases,
    the committed bytes counter increases. If the available bytes counter
    seems to be low, your system may be short on memory. Before investing in
    memory though, try opening and closing any applications that are running
    on the server. If the available bytes don’t increase as applications are
    closed, then it may indicate that the application has a memory leak.
  • Cache Bytes – The Cache Bytes
    counter indicates the amount of memory that is being used by the file
    system cache. If the value is over 4 MB, then it almost always means that
    the server needs additional RAM.

CPU-related counters

If you are testing a server for bottlenecks, then you should
check to make sure that the CPU isn’t the cause of the problem. To do so, check
out the %Processor Time counter in the Processor performance object. The
average value should remain below 80%. If the average value (not the peak
value) is above 80% and you have made sure that the system has sufficient
memory, then it’s time for either a faster processor or an additional
processor.

Disk-related counters

One more important resource to test for bottlenecks is the
server’s hard drive. You must verify that the disk is fast enough to keep pace
with the server’s I/O demands. To do so, there are two counters that I
recommend watching. Both of these counters are located in the Physical Disk
performance object.

The first counter is the Current Disk Queue Length. This
counter tells you how many I/O operations need to be performed, but are waiting
on the hard disk to become available. There is a lot of contradictory
information regarding what this value should be, but generally speaking, if the
average value is 2, then you need to keep an eye on your hard disk. If the
average value is 3 or more, then the disk is too slow.

The other counter that I recommend watching is the % Disk
Time counter. This counter shows you what percentage of time the hard disk is
in use. If the % Disk Time counter has an average value of 90% or higher, and
the system has adequate RAM, then the hard disk is too slow for the system.