This chapter describes the tools provided with Netscape Directory Server (Directory Server) to help optimize performance. It also provides tips to improve the performance of your directory.
This chapter contains the following sections:
You can manage your server's performance by limiting the amount of resources the server uses to proces client search requests. You can define:
To configure Directory Server to optimize performance:
For a better understanding of how these parameters impact your server's search performance, see About Indexes.
This section is divided into the following parts which describe methods for tuning database performance:
You can improve server performance on searches by tuning database settings. The database attributes that affect performance mainly define the amount of memory available to the server.
To improve the cache hit ratio on search operations, you can increase the amount of data that the Directory Server maintains in the database cache. Do this by increasing the number of entries stored in the cache and by increasing the cache size. The maximum values that you can set for these attributes depends on the amount of real memory on your machine. Roughly, the amount of available memory on your machine should always be greater than Maximum Entries in Cache x Average Entry Size.
Use caution when changing these two attributes. Your ability to improve server performance with these attributes depends on the size of your database, the amount of physical memory available on your machine, and whether directory searches are random (that is, if your directory clients are searching for random and widely scattered directory data).
If your database does not fit into memory and if searches are random, attempting to increase the values set on these attributes does not help directory performance. In fact, changing these attributes may harm overall performance.
You can tune the following attributes:
To configure the default database attributes that apply to all other database instances:
To configure the attributes of each database that stores your directory data:
Every Directory Server contains a transaction log which logs operations for all the databases it manages. Whenever a directory database operation such as a write is performed, the server logs the operation to the transaction log. For best performance, the directory does not perform the operation immediately. Instead, the operation is stored in a temporary memory cache on the Directory Server until the operation is completed.
If the server experiences a failure, such as a power outage, and shuts down abnormally, the information about recent directory changes that were stored in the cache is lost. However, when the server restarts, the directory automatically detects the error condition and uses the database transaction log to recover the database.
Although database transaction logging and
database recovery are automatic processes that require no intervention,
you may want to tune some of the database transaction logging
attributes to optimize performance.
By default, the database transaction log file is stored in the serverRoot/slapd-serverID/db directory along with the database files themselves. Because the purpose of the transaction log is to aid in the recovery of a directory database that was shut down abnormally, it is a good idea to store the database transaction log on a different disk from the one containing the directory database. Storing the database transaction log on a separate physical disk may also improve directory performance.
To change the location of the database transaction log file, use the following procedure:
At regular intervals, the Directory Server writes operations logged in the transaction log to the disk and logs a checkpoint entry in the database transaction log. By indicating which changes have already been written to the directory, checkpoint entries indicate where to begin recovery from the transaction log, thus speeding up the recovery process.
By default, the Directory Server is set up to send a checkpoint entry to the database transaction log every 60 seconds. Increasing the checkpoint interval may increase the performance of directory write operations. However, increasing the checkpoint interval may 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. Therefore, you should only modify this attribute if you are familiar with database optimization and can fully assess the effect of the change.
To modify the checkpoint interval while the
server is running, use the ldapmodify
command-line utility to add the
nsslapd-db-checkpoint-interval
attribute to the
cn=config,cn=ldbm database,cn=plugins,cn=config entry.
For more information on the syntax of the nsslapd-db-checkpoint-interval attribute, refer to the Netscape Directory Server Configuration, Command, and File Reference. For instructions on using ldapmodify, refer to Adding and Modifying Entries Using ldapmodify.
Durable transaction logging means that the temporary database transaction log is, in fact, physically written to disk.
When durable transaction logging is disabled, every directory database operation is written to the database transaction log file but 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, you cannot recover the change. 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.
By default, durable database transaction logging is enabled. To disable durable transaction logging, use the following procedure:
To improve update performance when full transaction durability is not required, you can use the nsslapd-db-transaction-batch-val attribute to specify how many transactions will be batched before being committed to the transaction log. Setting this attribute to a value of greater than 0 causes the server to delay committing transactions until the number of queued transactions is equal to the attribute value. For transaction batching to be valid, the nsslapd-db-durable-transaction attribute must be set to on.
To specify or modify transaction batching while the server is running, use the ldapmodify command-line utility to add the nsslapd-db-transaction-batch-val attribute to the cn=config,cn=ldbm database,cn=plugins,cn=config entry.
For more information on the syntax and values of the nsslapd-db-transaction-batch-val attribute, refer to the Netscape Directory Server Configuration, Command, and File Reference. For instructions on using ldapmodify, refer to Adding and Modifying Entries Using ldapmodify.
This section provides you with some performance related tips and concepts you ought to remember. This section includes:
The cn=config entry in the simple, flat dse.ldif configuration file is not stored in the same highly scalable database as regular entries. As a result, if many entries, particularly entries that are likely to be updated frequently, are stored under cn=config, performance will probably suffer.
Although we recommend you do not store
simple user entries under cn=config
for performance reasons, it can be useful to store special user entries
such as the Directory Manager entry or Replication Manager (supplier
bind DN) entry under cn=config, as this allows you to centralize
configuration information.
| Previous |
Contents |
Index |
DocHome | Next |