3.1.7 Active Directory monitoring examples

(1) When the domain controller load is constantly high

High load on a domain controller is often due to frequent disk access by the Active Directory database. In this case, the issue can be resolved by revising the memory cache or buffer allocation.

Monitoring the Active Directory database cache

With Active Directory databases, records can be accessed without incurring file operations on disk by setting an appropriate cache size. This cache usage can be monitored to adjust the cache, and increase database access performance. The following table describes the fields monitored for database cache usage.

Table 3‒9: Fields monitored for database cache usage

Field	Description
Cache % Hit	The percentage of database file page requests performed without incurring file operations, by using the database cache.
Cache Page Fault Stalls/sec	The number of page faults per second for which service could not be received, because there was no page allocated from the database cache.
Cache Page Faults/sec	The number of database file page requests per second required because the database cache manager allocated a new page from the database cache.
Cache Size	The amount of system memory used to maintain information frequently used by the database cache manager from database files.
Table Open Cache % Hit	The percentage of database tables opened using cached schema information.
Table Open Cache Hits/sec	The number of database tables opened per second using cached schema information.
Table Open Cache Misses/sec	The number of database tables opened per second without using cached schema information.
Table Opens/sec	The number of database tables opened per second.

Monitoring examples

When the following conditions are satisfied, performance might degrade due to insufficient cache capacity:

• Cache % Hit and Table Open Cache % Hit fall below the baseline.

• Cache Page Fault Stalls/sec rises above the baseline.

Countermeasure example

Increase the amount of memory allocated to the Active Directory database cache.

Monitoring the status of database log writes

The wait time for writing logs can be reduced by monitoring the buffer usage status for database logs, and adjusting the capacity of the log buffer accordingly. Unlike the information from Active Directory database cache monitoring, this is information about log buffer performance.

Table 3‒10: Fields for monitoring the status of database log writes

Field	Description
Log Record Stalls/sec	The number of log records per second that could not be added per second due to lack of log buffer space.
Log Threads Waiting	The number of threads standing by for writing log buffer data to log files, while waiting for database update to complete.
Log Writes/sec	The number of times per second that log buffer data is written to log files.

Monitoring examples

When the following condition is satisfied, performance might degrade due to insufficient log buffer space:

• Log Record Stalls/sec rises above the baseline.

Countermeasure example

Increase the amount of memory allocated to the log buffer.

To Page Top

(2) When logins are concentrated on a specific domain

Check the following fields to determine the number of sessions currently being used due to Active Directory.

Monitoring example

When the following condition is satisfied, logins are likely concentrated on a specific domain:

• LDAP Client Sessions rises above the baseline.

Countermeasure example

• Even out the number of users allocated to each domain controller.

• Distribute the number of users, such as by increasing the number of domain controllers.

To Page Top

(3) When intrasite network load is high

Intrasite network load might be high because Active Directory is performing large-scale replication within the site. The following table lists the fields for monitoring intrasite replication.

Monitoring example

When the following conditions are satisfied, intrasite network load might be high due to replication traffic within the site:

• DRA In Not Compress/sec and DRA Out Not Compress/sec rise above the baseline.

Countermeasure example

Distribute the load, such as by increasing the number of domain controllers.

To Page Top

(4) When network load between sites is high

The network load between sites might be high because Active Directory is performing large amount of replication between sites. Unlike intrasite replication, communication for replication between sites involves compression. The replication operation itself does not change. The following fields are for monitoring replication traffic between sites.

Monitoring example

When the following conditions are satisfied, network load might be high between sites due to replication traffic between sites.

• DRA In After Compress/sec, DRA In Before Compress/sec, DRA Out After Compress/sec, and DRA Out Before Compress/sec rise above the baseline.

Countermeasure example

• Schedule replication between sites when CPU usage is low.

• Consider integrating the sites, to reduce communication between the sites.

Tip

Replication is functionality for distributing the load of a database management system. If multiple copies of the database are distributed across the network, the load on lines and machines is reduced. Replication functionality can be used with Active Directory to provide advanced directory services while distributing load across machines.

Replication is an important part of directory services using Active Directory. By monitoring replication traffic, the current load can be better understood to determine any necessary steps to be taken.

Active Directory operates on the assumption that the network connection within a site is fast and reliable. Accordingly, data is not compressed when intrasite replication is performed, which avoids the overhead of compression processing.

However, when replication is performed between the domain controllers of sites, costs can be incurred due to the distances involved in normal communication between sites. This is why data is compressed when replication is performed between sites.

To Page Top