Active directory garbage collection causing CPU overload

Question

Active directory garbage collection causing CPU overload

Rossia Luca 0

Garbage collection spikes CPU usage to 100%

Domain controllers hit this every 12 hours

Task scans tombstones of deleted objects

Logging parameters add extra overhead

What’s the recommended way to safely adjust the garbage collection interval and fine‑tune logging settings so domain controllers don’t choke on these scheduled scans ?

0 comments

2 answers

Your answer

Answer 1

Hello,

What you are seeing is the scheduled Active Directory garbage collection process that runs every 12 hours by default. During this cycle, domain controllers scan tombstoned objects and log extensive detail, which can spike CPU usage if the environment has a large number of deleted objects or if logging is verbose.

The interval is controlled by the GarbageCollPeriod registry value under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. By default, this is set to 12 hours (720 minutes). You can safely adjust it to a longer interval, for example 24 hours (1440 minutes), to reduce the frequency of these CPU spikes. To do this, create or modify the GarbageCollPeriod value as a REG_DWORD in minutes. After changing it, restart the Active Directory Domain Services service or reboot the domain controller for the setting to take effect. Microsoft recommends not setting it too high, because tombstoned objects must still be cleaned up regularly to maintain database health.

On the logging side, excessive diagnostic output can add overhead. The parameters are under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Each subkey corresponds to a logging category, with values from 0 (none) to 5 (verbose). If you have categories like “Garbage Collection” or “Internal Processing” set to 3 or higher, lowering them back to 1 or 2 will reduce CPU impact during the scans. Always keep logging at a level that balances troubleshooting needs with performance.

After adjusting both the garbage collection interval and the diagnostic logging levels, monitor the domain controllers with Performance Monitor counters such as NTDS\DS Garbage Collection Time and Processor\% Processor Time to confirm that the spikes are reduced. Also check the Directory Services event log for Event ID 1646, which marks the completion of garbage collection, to ensure the process still runs successfully at the new interval.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

Answer 2

For Active Directory database garbage collection on domain controllers, the supported way to adjust the schedule is to change the garbageCollPeriod attribute in the enterprise-wide Directory Service configuration object.

Default interval: 12 hours
Minimum: 1 hour
Maximum: 168 hours
Where to change it: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=CONTOSO,DC=COM
Supported tools: Adsiedit.msc, Ldp.exe, or ADSI scripts

A safer tuning approach is:

Change only the garbage collection interval first using garbageCollPeriod.
Keep changes modest and validate DC behavior after each adjustment.
Do not rely on logging changes as the primary fix for CPU spikes. The documented issue for DC slowdowns during garbage collection is tied to Active Directory database behavior, including version store exhaustion and inconsistent objects/reference phantoms.
If the DC becomes slow or unresponsive during garbage collection and logs show errors such as 623, 1519, 1479, or error 8573, the documented workaround is to increase the Active Directory version store size.

If version store tuning is required, the documented workaround is to change this registry value:

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Name: EDB max ver pages (increment over the minimum)
Type: REG_DWORD

Important cautions:

Registry changes are risky and can affect LSASS memory usage.
Values below 6400 have no effect; 6400 is the default and minimum.
Increase in roughly 50 MB increments.
Do not set arbitrarily high values, especially on x86 systems, because LSASS can run out of memory for other tasks.
If garbage collection still does not complete successfully at 19200, the documented guidance is to contact Microsoft Support.
Increasing version storage is only a temporary workaround; the issue can recur after a tombstone lifetime interval or when the affected objects are scanned again.

For the underlying cause, the documented problem can be many inconsistent objects or too many reference phantoms. In that case, the recommended path is Microsoft Support assistance to identify and remove those objects.

On defragmentation:

Online defragmentation runs as part of garbage collection and does not reduce the size of Ntds.dit.
Offline defragmentation with Ntdsutil.exe does reduce Ntds.dit size, but it requires taking the domain controller offline.

The provided documentation does not give a supported procedure for “fine-tuning logging settings” to reduce this load. The supported tuning that is documented is adjusting garbageCollPeriod, and for the specific slowdown/hang condition, adjusting version store size as a workaround while investigating inconsistent objects or reference phantoms.

References: