Growth Estimates for Active Directory Users and Organizational Units
A series of tests has been performed to arrive at average object sizes for objects that are typically stored in Active Directory. These tests begin with the size of the default Ntds.dit file immediately following the promotion of a domain controller.
.gif "important-icon")
Important
Ntds.dit grows by increments and uses fractional pages in the Btrees to avoid page splits. Therefore, if you add objects, the database size seems larger than the actual data.
The database file size is not updated until the file has been closed. Because Active Directory always keeps its database open and the database file never shrinks while online, Windows 2000 always reports the larger file size when the domain controller is restarted. However, the free space that remains on the drive is reported correctly, so through subtraction you can reconstruct the actual file size.
To find the approximate size of data plus indices, set the registry to log disk space that is freed by defragmentation (see the procedure "To activate logging of disk space that is freed by defragmentation" earlier in this chapter) and use the Ntdsutil command-line tool to compact (defragment) the database offline. (For more information about using Ntdsutil to perform offline defragmentation, see "Active Directory Diagnostics, Troubleshooting, and Recovery" and "Active Directory Diagnostic Utility (Ntdsutil.exe)" in this book.)
Table 2.3 shows the sizes for users, organizational units, and attributes. You can use these numbers to perform additional calculations.
Table 2.3 Disk Space That Is Required for Storing Active Directory Objects
Object |
Estimated size in database |
|---|---|
User |
3.7 KB |
Organizational unit |
1.1 KB |
Attribute (10 bytes) |
100 bytes |
Directory Database Sizing Tests
In general, two kinds of directory database sizing tests were performed. In the first series of tests, the database was loaded with large numbers of identical objects to show how the database grows when objects are loaded and how much space is consumed for the object types in each test. In the second series of tests, a blueprint for a company with user objects, group objects, and file shares was created. Then objects were added in successive increments of 100,000 to show how large the database can become for small, medium, and large companies.
In most of the tests, the object load operation consisted of several steps. The empty database size was recorded, and the first set of objects was loaded. The database then was defragmented offline and the fragmented and the defragmented versions of the database measured. The fragmented version of the file was used when the next set of objects was loaded.
The objective of the single-object load tests was to determine how the size of the database increases with respect to an increase in attribute value size. Because the database engine consumes space only for attributes for which values are set, the number of object attributes that have values makes a significant difference in the size of an object. In tests that were conducted only for user and organizational unit objects, only mandatory attributes were set. Mandatory attributes must contain at least one value in order for the directory service to create the object. Subsequent tests show how adding attributes to an object affects object size.
Because user objects play a significant role in directory deployment, you have to know how big the user objects are to determine how big the database will grow when you add users. Up to 500,000 users were loaded in the database in increments of 100,000 users. The results of the test are shown in Table 2.4.
Table 2.4 User Object Growth Test Results
Fragmented database Defragmented database |
|---|
Number of users |
KB per database |
Growth (in KB) |
Bytes per user |
KB per database |
Growth (in KB) |
Bytes per user |
|---|---|---|---|---|---|---|
0 |
10,256 |
-- |
-- |
10,256 |
-- |
-- |
100,000 |
516,064 |
505,808 |
5,179 |
364,560 |
354,304 |
3,628 |
200,000 |
899,088 |
383,024 |
4,551 |
720,912 |
356,352 |
3,639 |
300,000 |
1,294,352 |
395,264 |
4,383 |
1,079,312 |
358,400 |
3,649 |
400,000 |
1,675,280 |
380,928 |
4,262 |
1,435,664 |
356,352 |
3,649 |
500,000 |
2,060,328 |
385,048 |
4,199 |
1,792,016 |
356,352 |
3,649 |
The database file growth pattern shown in Table 2.4 is linear. In fact, the growth between two load operations is always almost identical — approximately 385,000 KB in the fragmented version of the file and approximately 356,000 KB in the defragmented version of the file. The only exception to this linear growth pattern is the load operation in the first step when the first 100,000 users are loaded. Here the increase in file size is much greater (about 516,000 KB).
This test illustrates how online defragmentation affects database size. Between the time the first set of objects (100,000 users) was added on the first day and the time the size of the file was checked on the next day, online defragmentation had occurred and rearranged the objects in the database. The online defragmentation made space available for new objects, but it did not shrink the database file size. Therefore, the size of the fragmented file is much greater than the size of the file when the next set of 100,000 user objects is loaded and the space in the database file can be used. The increase in file size for the fragmented version of the file is not much different from the increase in file size for the defragmented version of the file.
Loading 500,000 users (with values for only the mandatory attributes set) into Active Directory requires about 1.8 GB. To compute the size of one user object, subtract the size of an empty store and then divide the store size by the number of users. In this case, one user object is 3,649 bytes in size. User objects in Active Directory are larger than most other objects because they contain many mandatory attributes.
Organizational Units
Because information in Active Directory is organized in a hierarchy of organizational units, a series of tests was conducted to measure the effect of adding organizational unit objects on the database size. Table 2.5 shows the results of these tests.
Table 2.5 Organizational Unit Object Growth Test Results
Fragmented database Defragmented database |
|---|
Number of users |
KB per database |
Growth (in KB) |
Bytes per user |
KB per database |
Growth (in KB) |
Bytes per user |
|---|---|---|---|---|---|---|
0 |
10,256 |
-- |
-- |
10,256 |
-- |
-- |
2,000 |
12,304 |
2,048 |
1,049 |
10,256 |
0 |
-- |
4,000 |
16,440 |
4,136 |
1,583 |
12,304 |
2,048 |
524 |
6,000 |
18,448 |
2,008 |
1,398 |
14,352 |
2,048 |
699 |
8,000 |
20,496 |
2,048 |
1,311 |
18,448 |
4,096 |
1,049 |
10,000 |
24,592 |
4,096 |
1,468 |
20,496 |
2,048 |
1,049 |
12,000 |
26,640 |
2,048 |
1,398 |
22,544 |
2,048 |
1,049 |
14,000 |
28,688 |
2,048 |
1,348 |
24,592 |
2,048 |
1,049 |
16,000 |
32,784 |
4,096 |
1,442 |
26,640 |
2,048 |
1,049 |
The results in Table 2.5 show that the growth pattern for organizational units also is linear. The size of one organizational unit is 1,049 bytes.
Adding Attributes
The next series of tests enlarged the user objects with extension attributes 1 through 10. The attributes are defined in the schema as string-valued attributes. Each string was filled with 10 characters.
The test began with a store that contained 100,000 user objects with only their mandatory attribute set. The server was demoted to a non-domain controller, promoted back to a domain controller, and then loaded with 100,000 user objects again, this time with one extension attribute. The process was repeated with two attributes, then three attributes, and so forth. The results are shown in Table 2.6.
Table 2.6 Test Results for Extension Attributes with a User Object
Fragmented database Defragmented database |
|---|
Number of extension attributes |
KB per database |
Bytes per user |
Database/ defrag. |
Bytes per user |
Bytes per attribute |
|---|---|---|---|---|---|
0 |
522,256 |
5,242 |
364,560 |
3,627 |
-- |
1 |
413,712 |
4,130 |
364,560 |
3,627 |
0 |
2 |
413,712 |
4,130 |
364,560 |
3,627 |
0 |
3 |
485,392 |
4,864 |
382,992 |
3,816 |
63 |
4 |
663,568 |
6,689 |
405,520 |
4,046 |
105 |
5 |
698,384 |
7,045 |
405,520 |
4,046 |
84 |
6 |
706,576 |
7,129 |
407,568 |
4,067 |
73 |
7 |
704,528 |
7,108 |
444,432 |
4,445 |
117 |
8 |
702,480 |
7,087 |
444,432 |
4,445 |
102 |
9 |
497,680 |
4,990 |
444,432 |
4,445 |
91 |
10 |
497,680 |
4,990 |
444,432 |
4,445 |
82 |
11 |
497,680 |
4,990 |
444,432 |
4,445 |
74 |
In the fragmented version of the database, the size of the database increases by significantly larger increments at some steps than at others. This variation occurs when the database engine allocates space for new pages. Such large increases do not occur for the defragmented version of the database.
The growth of the defragmented database again is very linear. One additional attribute with a string size of 10 characters adds approximately 100 bytes to an object's size.
For more information about Active Directory growth management and capacity planning, see "Designing the Active Directory Structure" in the Deployment Planning Guide , and see the Microsoft Windows 2000 Server link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .