Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 9. Performance tuning of Red Hat Directory Server

To improve Directory Server performance, you can tune the number of locks, resource limits, and the transaction log. You can also monitor the local disk and shut down Directory Server if the disk space available on a system becomes insufficient.

9.1. Monitoring the database activity
Copy link

For details about the database monitoring, see Monitoring the database activity

9.2. Improving the performance of views
Copy link

The performance of view-based hierarchies depends on the construction of the hierarchy itself and the number of entries in the directory tree (DIT).

In general, there may be a marginal change in performance (within a few percentage points of equivalent searches on a standard DIT) if you use virtual DIT views. If you do not invoke a view in a search, then there is no performance impact. Test the virtual DIT views against expected search patterns and loads before deployment.

You can index the attributes used in view filters if you intend to use the views as general-purpose navigation tools in the organization. For details, how to create indexes for attributes used in view filters, see Creating indexes to improve the performance of views.

Further, you can configure a virtual list view (VLV) index to be used in evaluation of sub-filters in views.

There is no need to tune any other part of the directory specifically for views.

In large directories, the search results list can be huge. For example, a directory with one million entries with inetorgperson attributes would return all these entries in a search with a filter, such as (objectclass=inetorgperson).

Loading a long ID list from the database significantly reduces search performance. An ID list scan limit sets a limit on the number of IDs Directory Server reads before a key is considered to match the entire primary index. This means that Directory Server treats the search as an unindexed search with a different set of resource limits.

For large indexes, it is actually more efficient to treat any search which matches the index as an unindexed search. The search operation only has to look in one place, the entire directory, to process results rather than searching through an index that is nearly the size of a directory, plus the directory itself.

You can set an index scan limit globally or for specific databases.

By default, the ID list scan limit in Directory Server is 4000. In most scenarios, this value provides good performance for a common range of database sizes and access patterns, and you do not need to change the default value. If the database index is slightly larger than 4000 entries, but still significantly smaller than the overall directory, raising the ID list scan limit improves searches.

On the other hand, lowering the limit can significantly speed up searches that would otherwise hit the 4000 entry limit, but where it is not necessary to scan every entry.

Procedure

  1. Update the ID list scan limit: 

    # dsconf <instance_name> backend config set --idlistscanlimit=8000
    Copy to Clipboard Toggle word wrap

    This command sets the limit to 8000 entries.

  2. Restart the instance: 

    # dsctl <instance_name> restart
    Copy to Clipboard Toggle word wrap

By default, the ID list scan limit in Directory Server is 4000. In most scenarios, this value provides good performance for a common range of database sizes and access patterns, and you do not need to change the default value. If the database index is slightly larger than 4000 entries, but still significantly smaller than the overall directory, raising the ID list scan limit improves searches.

On the other hand, lowering the limit can significantly speed up searches that would otherwise hit the 4000 entry limit, but where it is not necessary to scan every entry.

Procedure

  1. Navigate to Database Global Database Configuration.
  2. Update the ID List Scan Limit field.
  3. Click Save Config.
  4. Click Actions in the top right corner, and select Restart Instance.

In some cases, it is useful to define a limit for certain indexes, or to not use an ID list at all. You can configure individual settings for ID list scan limits for different types of search filters.

For example, in a large database with 10 million entries that contain the object class inetOrgPerson, the (&(objectClass=inetOrgPerson)(uid=user)) filter creates first an ID list containing all 10 million IDs matching objectClass=inetOrgPerson. When the database applies the second part of the filter, it searches the result list for objects matching uid=user. In this case, it is useful to define a limit for certain indexes, or to not use an ID list at all.

This procedure demonstrates how to configure Directory Server to note create an ID list for objectClass=inetOrgPerson conditions in AND clauses.

Procedure

  • Set the nsIndexIDListScanLimit parameter: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x

dn: cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsIndexIDListScanLimit
nsIndexIDListScanLimit: limit=0 type=eq flags=AND values=inetOrgPerson
    Copy to Clipboard Toggle word wrap

    With these settings, Directory Server does not create any ID list for objectClass=inetOrgPerson conditions in AND clauses. In all other situations, Directory Server applies the global ID list scan limit value.

    The nsIndexIDListScanLimit parameter uses the following syntax: 

    nsIndexIDListScanLimit: limit=NNN [type=eq[,sub,...]] [flags=AND[,XXX,...]] [values=val[,val,...]]
    Copy to Clipboard Toggle word wrap

    • limit: Sets the maximum size of the ID list. Valid values are:

      • -1: Unlimited
      • 0: Do not use the index
      • 1 to the maximum of the 32-bit integer (2147483647): Maximum number of IDs

    • type: Optional: Sets flags that alter the scan limit’s behavior. Valid values are:

      • AND: Apply the scan limit only to searches in which the attribute appears in an AND clause.
      • OR: Apply the scan limit only to searches in which the attribute appears in an OR clause.

    • values: Optional: A comma-separated list of values which must match the search filter in order for the limit to be applied. Since the matches are done one at a time, the values will match if any of the values matches.

      Use the values only with one type at a time. The values must correspond to the index type and to the syntax of the attribute to which the index is applied. For example, if you specified the integer-based attribute uidNumber and it is indexed for the eq type, you cannot use type=eq values=abc.

      If the value contains spaces, commas, NULL, or other values which require escaping, use the LDAP filter escape syntax: A backslash (\) followed by the 2 hex digit code of the character. In the following example, the commas in the DN value are escaped with \2C: 

      nsIndexIDListScanLimit: limit=0 type=eq values=uid=user\2Cou=People\2Cdc=example\2Cdc=com
      Copy to Clipboard Toggle word wrap

The number of threads Directory Server uses to handle simultaneous connections affects the performance of the server. For example, if all threads are busy handling time-consuming tasks, such as add operations, new incoming connections are queued until a free thread can process the request.

If the server provides a low number of CPU threads, configuring a higher number of threads can increase the performance. However, on a server with many CPU threads, setting a too high value does not further increase the performance.

By default, Directory Server uses an auto-tuning setting that calculates the number of threads. This number is based on the hardware resources of the server when the instance starts.

Warning

Avoid setting the number of threads manually. Use the auto-tuning setting instead.

With enabled automatic thread tuning, Directory Server uses the following optimized number of threads:

Expand
CPU threads numberDirectory Server threads number

1-16

16

17-512

The Directory Server thread number matches the CPU thread number in the system. For example, if your system has 24 CPU threads, Directory Server uses 24 threads. The maximum number of Directory Server threads is 512.

512 and more

512. Directory Server applies the recommended maximum number of threads.

By default, Directory Server automatically sets the number of threads based on the available hardware. However, in certain cases, you can manually enable this auto-tuning feature by using the command line.

Procedure

  • To enable the auto-tuning feature, set the nsslapd-threadnumber attribute value to -1 by the command: 

    # dsconf <instance_name> config replace nsslapd-threadnumber="-1"

Successfully replaced "nsslapd-threadnumber"
    Copy to Clipboard Toggle word wrap

Verification

  • Verify the number of treads that Directory Server now uses by the command: 

    # dsconf <instance_name> config get nsslapd-threadnumber

nsslapd-threadnumber: 16
    Copy to Clipboard Toggle word wrap
    Note

    The command retrieves the number of threads that Directory Server calculated based on the correct hardware resources.

By default, Directory Server automatically sets the number of threads based on the available hardware. However, in certain cases, you can manually enable this auto-tuning feature by using the web console.

Prerequisites

Procedure

  1. Navigate to Server Tuning & Limits.
  2. In the Number Of Worker Threads field, set the number of threads to -1.
  3. Click Save Settings.

In certain situations, it is necessary to manually set a fixed number of Directory Server threads. For example, if you do not use the auto-tuning setting and change the number of CPU cores in a virtual machine, adjusting the number of Directory Server threads can improve the performance.

You can also use this procedure to re-enable the auto-tuning setting if you set a specific number of threads earlier.

Procedure

  • Set the number of threads Directory Server should use: 

    # dsconf <instance_name> config replace nsslapd-threadnumber="64"

Successfully replaced "nsslapd-threadnumber"
    Copy to Clipboard Toggle word wrap

    Set the nsslapd-threadnumber parameter to -1 to enable the auto-tuning setting.

In certain situations, it is necessary to manually set a fix number of Directory Server threads. For example, if you do not use the auto-tuning setting and change the number of CPU cores in a virtual machine, adjusting the number of Directory Server threads can improve the performance.

Note that you can use the web console to re-enable the auto-tuning setting if you set a specific number of threads earlier.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Server Tuning & Limits.
  2. In the Number Of Worker Threads field, set the number of threads.
  3. Click Save Settings.

9.5. Tuning resource limits
Copy link

Directory Server provides several settings to tune the amount of resources an instance uses. You can change them using the command line or the web console.

This section provides a general procedure how to change resource limit settings. Adjust the settings according to your environment.

Procedure

  1. Update the performance settings: 

    # dsconf <instance_name> config replace <parameter_name>=<value>
    Copy to Clipboard Toggle word wrap

    You can set the following parameters:

    • nsslapd-threadnumber: Sets the number of worker threads.
    • nsslapd-maxdescriptors: Sets the maximum number of file descriptors.
    • nsslapd-timelimit: Sets the search time limit.
    • nsslapd-sizelimit: Sets the search size limit.
    • nsslapd-pagedsizelimit: Sets the paged search size limit.
    • nsslapd-idletimeout: Sets the idle connection timeout.
    • nsslapd-ioblocktimeout: Sets the input/output (I/O) block timeout.
    • nsslapd-ndn-cache-enabled: Enables or disables the normalized DN cache.
    • nsslapd-ndn-cache-max-size: Sets the normalized DN cache size, if nsslapd-ndn-cache-enabled is enabled.
    • nsslapd-outbound-ldap-io-timeout: Sets the outbound I/O timeout.
    • nsslapd-maxbersize: Sets the maximum Basic Encoding Rules (BER) size.
    • nsslapd-maxsasliosize: Sets the maximum Simple Authentication and Security Layer (SASL) I/O size.
    • nsslapd-listen-backlog-size: Sets the maximum number of sockets available to receive incoming connections.
    • nsslapd-max-filter-nest-level: Sets the maximum nested filter level.
    • nsslapd-ignore-virtual-attrs: Enables or disables virtual attribute lookups.
    • nsslapd-connection-nocanon: Enables or disables reverse DNS lookups.

    • nsslapd-enable-turbo-mode: Enables or disables the turbo mode feature.

      For further details, see the descriptions of the parameters in the Configuration and schema reference

  2. Restart the instance: 

    # dsctl <instance_name> restart
    Copy to Clipboard Toggle word wrap

This section provides a general procedure how to change resource limit settings. Adjust the settings according to your environment.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Server Tuning & Limits.

  2. Update the settings. Optionally, click Show Advanced Settings to display all settings.

    admin tuning and limits
    View larger image
    admin tuning and limits
  3. Click Save Settings.
  4. Click Actions Restart Instance.

Transparent Huge Pages (THP) is the memory management feature in Linux that speeds up Translation Lookaside Buffer (TLB) checks on machines with large amounts of memory by using larger memory pages. The THP feature is enabled by default on RHEL systems and supports 2 MB memory pages.

The THP feature, however, works best when enabled on large, contiguous allocation patterns and can degrade performance on small, sparse allocation patterns that are typical to the Red Hat Directory Server. The resident memory size of the process might eventually exceed the limit and impact performance or get terminated by the out of memory (OOM) killer.

Important

To avoid performance and memory consumption problems, disable THP on RHEL systems with Red Hat Directory Server installed.

Procedure

  1. Check the current status of THP: 

    # cat /sys/kernel/mm/transparent_hugepage/enabled
    Copy to Clipboard Toggle word wrap

  2. If the transparent huge pages feature is active, disable it either at boot time or run time:

    • Disable the transparent huge pages at boot time by appending the following to the kernel command line in the grub.conf file: 

      transparent_hugepage=never
      Copy to Clipboard Toggle word wrap

    • Disable transparent huge pages at run time by running the following commands: 

      # echo never > /sys/kernel/mm/transparent_hugepage/enabled
# echo never > /sys/kernel/mm/transparent_hugepage/defrag
      Copy to Clipboard Toggle word wrap

When the disk space available on a system becomes too small, the Directory Server process terminates. As a consequence, there is a risk of corrupting the database or losing data. To prevent this problem, you can configure Directory Server to monitor the free disk space on the file systems that contain the configuration, transaction log, and database directories. If the free space reaches the configured threshold, Directory Server shuts down the instance.

How Directory Server behaves when when you configure monitoring depends on the amount of remaining free space:

  • If the free disk space reaches the defined threshold, Directory Server:

    • Disables verbose logging
    • Disables access access logging
    • Deletes archived log files
    Note

    Directory Server always continues writing error logs, even if the threshold is reached.

  • If the free disk space is lower than the half of the configured threshold, Directory Server shuts down within a defined grace period.
  • If the available disk space is ever lower than 4 KB, Directory Server shuts down immediately.

If disk space is freed up, then Directory Server aborts the shutdown process and re-enables all of the previously disabled log settings.

Directory Server can monitor the free disk space on the file systems that contain the configuration, transaction log, and database directories. Depending on the remaining free space, Directory Server disables certain logging features or shuts down.

Procedure

  1. Enable the disk monitoring feature, set a threshold value and a grace period: 

    # dsconf <instance_name> config replace nsslapd-disk-monitoring=on nsslapd-disk-monitoring-threshold=3221225472 nsslapd-disk-monitoring-grace-period=60
    Copy to Clipboard Toggle word wrap

    This command sets the threshold of free disk space to 3 GB (3,221,225,472 bytes) and the grace period to 60 seconds.

  2. Optional: Configure Directory Server not to disable access logging or delete archived logs: 

    # dsconf <instance_name> config replace nsslapd-disk-monitoring-logging-critical=on
    Copy to Clipboard Toggle word wrap

  3. Restart the instance: 

    # dsctl <instance_name> restart
    Copy to Clipboard Toggle word wrap

Directory Server can monitor the free disk space on the file systems that contain the configuration, transaction log, and database directories. Depending on the remaining free space, Directory Server disables certain logging features or shuts down.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Server Server Settings Disk Monitoring.

  2. Select Enable Disk Space Monitoring. Set the threshold in bytes and the grace period in minutes:

    admin configure local disk space monitoring
    View larger image
    admin configure local disk space monitoring

    This example sets the monitoring threshold to 3 GB (3,221,225,472 bytes) and the time before Directory Server shuts down the instance after reaching the threshold to 60 minutes.

  3. Optional: Select Preserve Logs Even If Disk Space Gets Low.
  4. Click Save Settings.
  5. Click Actions in the top right corner, and select Restart Instance.

9.7. Tuning transaction logging
Copy link

Every Directory Server instance contains a transaction log which logs updates of databases it manages. Whenever a directory database operation, such as a modify operation, is performed, the server creates a single database transaction for all of the database operations invoked as a result of that LDAP operation. This includes both updating the entry record in the database file containing the entries and updating all attribute indexes. If all of the operations succeed, the server commits the transaction, writes the operations to the transaction log, and verifies that the entire transaction is written to disk. If any of these operations fail, the server rolls back the transaction, and all of the operations are discarded. This all-or-nothing approach guarantees that an update operation is atomic. Either the entire operation succeeds permanently and irrevocably, or it fails.

Periodically, Directory Server flushes the contents of the transaction logs to the actual database index files and checks if the transaction logs require trimming.

If the server experiences a failure, such as a power outage, and shuts down abnormally, the information about recent directory changes is still saved by the transaction log. When the server restarts, the server automatically detects the error condition and uses the database transaction log to recover the database.

Although database transaction logging, flush the database, trimming, and database recovery are automatic processes that require no intervention, it can be advisable to tune some of the database transaction logging attributes to optimize the performance.

At regular intervals, Directory Server writes the transactions logged logged in the transaction log to the database files and logs a checkpoint entry in the database transaction log. By indicating which changes have already been written to the database, checkpoint entries indicate where to begin recovery from the transaction log, thus speeding up the recovery process.

By default, Directory Server sends a checkpoint entry to the database transaction log every 60 seconds. Increasing the checkpoint interval can increase the performance of directory write operations. However, it can also increase the amount of time required to recover directory databases after a disorderly shutdown and require more disk space due to large database transaction log files.

Procedure

  • Change the checkpoint interval, for example, to 120 seconds: 

    # dsconf <instance_name> backend config set --checkpoint-interval=120
    Copy to Clipboard Toggle word wrap

At regular intervals, Directory Server writes the transactions logged logged in the transaction log to the database files and logs a checkpoint entry in the database transaction log. By indicating which changes have already been written to the database, checkpoint entries indicate where to begin recovery from the transaction log, thus speeding up the recovery process.

By default, Directory Server sends a checkpoint entry to the database transaction log every 60 seconds. Increasing the checkpoint interval can increase the performance of directory write operations. However, it can also increase the amount of time required to recover directory databases after a disorderly shutdown and require more disk space due to large database transaction log files.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Database Global Database Configuration.
  2. Click Show Advanced Settings.
  3. Update the value in the Database Checkpoint Interval field.
  4. Click Save Configuration.

9.7.3. Disabling durable transactions
Copy link

Durable transaction logging means that each LDAP update operation, comprised of a sequence of database operations in a transaction, is physically written to disk. Even though each LDAP operation can be comprised of multiple database updates, each LDAP operation is treated as a single database transaction. Each LDAP operation is both atomic and durable.

Warning

Turning off durable transactions can improve the write performance of Directory Server at the risk of data loss.

When you disable durable transaction logging, Directory Server writes every directory database operation to the database transaction log file but it may not be physically written to disk immediately. If a directory change was written to the logical database transaction log file but not physically written to disk at the time of a system crash, the change cannot be recovered. When durable transactions are disabled, the recovered database is consistent but does not reflect the results of any LDAP write operations that completed just before the system crash.

Note that you cannot change the nsslapd-db-durable-transaction parameter if Directory Server is running.

Procedure

  1. Stop the instance: 

    # dsctl <instance_name> stop
    Copy to Clipboard Toggle word wrap

  2. Edit the /etc/dirsrv/slapd-<instance_name>/dse.ldif file, and set the nsslapd-db-durable-transaction parameter in the cn=config,cn=ldbm database,cn=plugins,cn=config entry to off: 

    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
...
nsslapd-db-durable-transaction: off
...
    Copy to Clipboard Toggle word wrap

  3. Start the instance: 

    # dsctl <instance_name> start
    Copy to Clipboard Toggle word wrap

9.8. Managing cache settings
Copy link

Directory Server uses the following caches:

  • The entry cache, which contains individual directory entries.
  • The distinguished name (DN) cache is used to associate DNs and relative distinguished names (RDN) with entries.
  • The database cache, which contains the database index files *.db files.

For the highest performance improvements, all cache sizes must be able to store all of their records. If you do not use the recommended auto-sizing feature and have not enough RAM available, assign free memory to the caches in the previously shown order.

By default, Directory Server uses an auto-sizing feature to optimize the size of both the database and entry cache on the hardware resources of the server when the instance starts.

Important

Red Hat recommends to use the auto-sizing feature and not to set cache sizes manually.

The following parameters in the cn=config,cn=ldbm database,cn=plugins,cn=config entry control the auto-sizing:

nsslapd-cache-autosize

These settings control if auto-sizing is enabled for the database and entry cache. Auto-sizing is enabled:

  • For both the database and entry cache, if the nsslapd-cache-autosize parameter is set to a value greater than 0.
  • For the database cache, if the nsslapd-cache-autosize and nsslapd-dbcachesize parameters are set to 0.
  • For the entry cache, if the nsslapd-cache-autosize and nsslapd-cachememsize parameters are set to 0.
nsslapd-cache-autosize-split
  • The value sets the percentage of RAM that Directory Server uses for the database cache. The server uses the remaining percentage for the entry cache.
  • Using more than 1.5 GB RAM for the database cache does not improve the performance. Therefore, Directory Server limits the database cache to 1.5 GB.

By default, Directory Server uses the following defaults values:

  • nsslapd-cache-autosize: 25
  • nsslapd-cache-autosize-split: 25
  • nsslapd-dbcachesize: 1,536 MB

Using these settings, 25% of the system’s free RAM is used (nsslapd-cache-autosize). From this memory, the server uses 25% for the database cache (nsslapd-cache-autosize-split) and the remaining 75% for the entry cache.

Depending on the free RAM, this results in the following cache sizes:

Expand
Table 9.1. Cache sizes if both nsslapd-cache-autosize and nsslapd-cache-autosize-split use their default values
GB of free RAMDatabase cache sizeEntry cache size

1 GB

64 MB

192 MB

2 GB

128 MB

384 MB

4 GB

256 MB

768 MB

8 GB

512 MB

1,536 MB

16 GB

1,024 MB

3,072 MB

32 GB

1,536 MB

6,656 MB

64 GB

1,536 MB

14,848 MB

128 GB

1,536 MB

31,232 MB

9.8.2. Required cache sizes
Copy link

The dsconf monitor dbmon command enables you to monitor cache statistics at runtime. To display the statistics, enter: 

# dsconf <instance_name> monitor dbmon

DB Monitor Report: 2022-02-24 10:25:16
--------------------------------------------------------
Database Cache:
 - Cache Hit Ratio:     50%
 - Free Space:          397.31 KB
 - Free Percentage:     2.2%
 - RO Page Drops:       0
 - Pages In:            2934772
 - Pages Out:           219075

Normalized DN Cache:
 - Cache Hit Ratio:     60%
 - Free Space:          19.98 MB
 - Free Percentage:     99.9%
 - DN Count:            100000
 - Evictions:           9282348

Backends:
  - dc=example,dc=com (userroot):
    - Entry Cache Hit Ratio:        66%
    - Entry Cache Count:            50000
    - Entry Cache Free Space:       2.0 KB
    - Entry Cache Free Percentage:  0.8%
    - Entry Cache Average Size:     8.9 KB
    - DN Cache Hit Ratio:           21%
    - DN Cache Count:               100000
    - DN Cache Free Space:          4.29 MB
    - DN Cache Free Percentage:     69.8%
    - DN Cache Average Size:        130.0 B
Copy to Clipboard Toggle word wrap

Optionally, pass the -b back_end or -x option to the command to display the statistics for a specific back end or the index.

If your caches are sufficiently sized, the number in DN Cache Count matches the values in the Cache Count backend entries. Additionally, if all of the entries and DNs fit within their respective caches, the Entry Cache Count count value matches the DN Cache Count value.

The output of the example shows:

  • Only 2.2% free database cache is left: 

    Database Cache:
 ...
 - Free Space:          397.31 KB
 - Free Percentage:     2.2%
    Copy to Clipboard Toggle word wrap

    However, to operate efficiently, at least 15% free database cache is required. To determine the optimal size of the database cache, calculate the sizes of all *.db files in the /var/lib/dirsrv/slapd-<instance_name>/db/ directory including subdirectories and the changelog database, and add 12% for overhead.

    To set the database cache, see Setting the database cache size using the command line.

  • The DN cache of the userroot database is well-chosen: 

    Backends:
  - dc=example,dc=com (userroot):
    ...
    - DN Cache Count:               100000
    - DN Cache Free Space:          4.29 MB
    - DN Cache Free Percentage:     69.8%
    - DN Cache Average Size:        130.0 B
    Copy to Clipboard Toggle word wrap

    The DN cache of the database contains 100000 records, 69,8% of the cache is free, and each DN in memory requires 130 bytes on average.

    To set the DN cache, see Setting the DN cache size using the command line.

  • The statistics on the entry cache of the userroot database indicates that the entry cache value should be increased for better performance: 

    Backends:
  - dc=example,dc=com (userroot):
  ...
    - Entry Cache Count:            50000
    - Entry Cache Free Space:       2.0 KB
    - Entry Cache Free Percentage:  0.8%
    - Entry Cache Average Size:     8.9 KB
    Copy to Clipboard Toggle word wrap

    The entry cache contains in this database 50000 records and only 2 Kilobytes of free space are left. To enable Directory Server to cache all 100000 DNs, the cache must be increased to minimum of 890 MB (100000 DNs * 8,9 KB average entry size). However, Red Hat recommends to round the minimum required size to the next highest GB and double the result. In this example, the entry cache should be set to 2 Gigabytes.

    To set the entry cache, see Setting the entry cache size using the command line.

The database cache contains the Berkeley database index files for the database, meaning all of the *.db and other files used for attribute indexing by the database. This value is passed to the Berkeley DB API function set_cachesize(). This cache size has less of an impact on Directory Server performance than the entry cache size, but if there is available RAM after the entry cache size is set, increase the amount of memory allocated to the database cache.

Procedure

  1. Disable automatic cache tuning 

    # dsconf <instance_name> backend config set --cache-autosize=0
    Copy to Clipboard Toggle word wrap

  2. Manually set the database cache size: 

    # dsconf <instance_name> backend config set --dbcachesize=268435456
    Copy to Clipboard Toggle word wrap

    Specify the database cache size in bytes. In this example, the command sets the database cache to 256 MB.

  3. Restart the instance: 

    # dsctl <instance_name> restart
    Copy to Clipboard Toggle word wrap

The database cache contains the Berkeley database index files for the database, meaning all of the *.db and other files used for attribute indexing by the database. This value is passed to the Berkeley DB API function set_cachesize(). This cache size has less of an impact on Directory Server performance than the entry cache size, but if there is available RAM after the entry cache size is set, increase the amount of memory allocated to the database cache.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Database Global Database Configuration.
  2. Deselect Automatic Cache Tuning.
  3. Click Save Config.
  4. Enter the database cache size in bytes, such as 268435456 for 256 MB, into the Database Cache Size field.
  5. Click Save Config.
  6. Click Actions in the top right corner, and select Restart Instance.

Directory Server uses the entryrdn index to associate distinguished names (DN) and relative distinguished names (RDN) with entries. It enables the server to efficiently rename subtrees, move entries, and perform moddn operations. The server uses the DN cache to cache the in-memory representation of the entryrdn index to avoid expensive file I/O and transformation operations.

If you do not use the auto-tuning feature, for best performance, especially with but not limited to renaming entries and moving operations, set the DN cache to a size that enables Directory Server to cache all DNs in the database.

If a DN is not stored in the cache, Directory Server reads the DN from the entryrdn.db index database file and converts the DNs from the on-disk format to the in-memory format. DNs that are stored in the cache enable the server to skip the disk I/O and conversion steps.

Procedure

  1. Display the suffixes and their corresponding back end: 

    # dsconf <instance_name> backend suffix list
dc=example,dc=com (userroot)
    Copy to Clipboard Toggle word wrap

    This command displays the name of the back end database next to each suffix. You require the suffix’s database name in the next step.

  2. Set the DN cache size: 

    # dsconf <instance_name> backend suffix set --dncache-memsize=20971520 userRoot
    Copy to Clipboard Toggle word wrap

    This command sets the DN cache for the userRoot database to 20 megabytes.

  3. Restart the instance: 

    # dsctl <instance_name> restart
    Copy to Clipboard Toggle word wrap

Directory Server uses the entryrdn index to associate distinguished names (DN) and relative distinguished names (RDN) with entries. It enables the server to efficiently rename subtrees, move entries, and perform moddn operations. The server uses the DN cache to cache the in-memory representation of the entryrdn index to avoid expensive file I/O and transformation operations.

If you do not use the auto-tuning feature, for best performance, especially with but not limited to renaming entries and moving operations, set the DN cache to a size that enables Directory Server to cache all DNs in the database.

If a DN is not stored in the cache, Directory Server reads the DN from the entryrdn.db index database file and converts the DNs from the on-disk format to the in-memory format. DNs that are stored in the cache enable the server to skip the disk I/O and conversion steps.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Database Suffixes suffix_name.
  2. Enter the DN cache size in bytes to the DN Cache Size field.
  3. Click Save Configuration.
  4. Click Actions in the top right corner, and select Restart Instance.

Directory Server uses the entry cache to store directory entries that are used during search and read operations. Setting the entry cache to a size that enables Directory Server to store all records has the highest performance impact on search operations.

If entry caching is not configured, Directory Server reads the entry from the id2entry.db database file and converts the distinguished names (DN) from the on-disk format to the in-memory format. Entries that are stored in the cache enable the server to skip the disk I/O and conversion steps.

Procedure

  1. Disable automatic cache tuning: 

    # dsconf <instance_name> backend config set --cache-autosize=0
Successfully updated database configuration
    Copy to Clipboard Toggle word wrap

  2. Display the suffixes and their corresponding back end: 

    # dsconf <instance_name> backend suffix list
dc=example,dc=com (userroot)
    Copy to Clipboard Toggle word wrap

    This command displays the name of the back end database next to each suffix. You require the suffix’s database name in the next step.

  3. Set the entry cache size in bytes for the database: 

    # dsconf <instance_name> backend suffix set --cache-memsize=2147483648 userRoot
    Copy to Clipboard Toggle word wrap

    This command sets the entry cache for the userRoot database to 2 gigabytes.

  4. Restart the instance: 

    # dsctl <instance_name> restart
    Copy to Clipboard Toggle word wrap

Directory Server uses the entry cache to store directory entries that are used during search and read operations. Setting the entry cache to a size that enables Directory Server to store all records has the highest performance impact on search operations.

If entry caching is not configured, Directory Server reads the entry from the id2entry.db database file and converts the distinguished names (DN) from the on-disk format to the in-memory format. Entries that are stored in the cache enable the server to skip the disk I/O and conversion steps.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Database Suffixes suffix_name Settings.
  2. Disable the Automatic Cache Tuning` setting.
  3. Click Save Configuration.
  4. Click Actions in the top right corner, and select Restart Instance.
  5. Navigate to Database Suffixes suffix_name Settings.
  6. Set the size of the database cache in the Entry Cache Size field.
  7. Click Save Configuration.
  8. Click Actions in the top right corner, and select Restart Instance.

Very large attribute sizes or a large number of entries can negatively impact server performance during import operations.

Use the import cache autosizing feature for operations like:

  • importing a very large database
  • importing a database with large attributes, such as binary attributes that store certificate chains or images
Note

Offline imports are faster than online ones. Consider using offline imports where possible.

You can configure the import cache autosizing feature with the nsslapd-import-cache-autosize attribute. By default, Directory Server enables the import cache autosizing for the ldif2db operation only, automatically allocating 50% of the free physical memory for the import cache.

For further details, see the description of the nsslapd-import-cache-autosize attribute in the Configuration, Command, and File Reference documentation.

The nsslapd-numlisteners attribute specifies the number of listener threads the Directory Server can use to monitor established connections. You can improve the response times when the server experiences a large number of client connection by increasing the attribute value.

You can manage the number of connection listener threads by using the command line. The default value is 1.

Procedure

  1. List the number of connection listener threads: 

    # dsconf <instance_name> config get nsslapd-numlisteners
    Copy to Clipboard Toggle word wrap

  2. Modify the number of connection listener threads: 

    # dsconf <instance_name> config replace nsslapd-numlisteners=4
    Copy to Clipboard Toggle word wrap

  3. Restart the instance: 

    # dsctl <instance_name> restart
    Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat