The primary backend provided by the OpenDS Directory Server uses the Berkeley DB Java Edition to store user-provided data in a local repository. It is the traditional "directory server" backend and is similar to the backends provided by the Sun Java System Directory Server. The stores the entries in an encoded form and also provides indexes that can be used to quickly locate target entries based on different kinds of criteria. ds-cfg-local-db-backend ds-cfg-backend cn=Index cn=VLV Index org.opends.server.backends.jeb.BackendImpl enabled Specifies the number of times that the server should retry an attempted operation in the backend if a deadlock results from two concurrent requests that interfere with each other in a conflicting manner. A value of "0" indicates no limit. 10 ds-cfg-deadlock-retry-limit Default this to the db/backend-id Specifies the path to the filesystem directory that will be used to hold the Berkeley DB Java Edition database files containing the data for this backend. The path may be either an absolute path or a path relative to the directory containing the base of the OpenDS Directory Server installation. The path may be any valid directory path in which the server has appropriate permissions to read and write files and has sufficient space to hold the database contents. ds-cfg-db-directory Indicates whether the backend should use a compact form when encoding entries by compressing the attribute descriptions and object class sets. Note that this property applies only to the entries themselves and does not impact the index data. Changes to this setting will only take effect for writes that occur after the change is made. It will not be retroactively applied to existing data. true ds-cfg-compact-encoding Indicates whether the backend should attempt to compress entries before storing them in the database. Note that this property applies only to the entries themselves and does not impact the index data. Further, the effectiveness of the compression will be based on the type of data contained in the entry. Changes to this setting will only take effect for writes that occur after the change is made. It will not be retroactively applied to existing data. false ds-cfg-entries-compressed Specifies the amount of memory that should be used as an internal buffer for index information when processing an LDIF import. Changes will not take effect for any import that may already be in progress. 256mb ds-cfg-import-buffer-size Specifies the maximum number of entries that should be imported in each import pass. An import pass consists of the processing required to import a set of entries as well as the index post-processing required to index those entries. A value of zero for this property indicates that all entries should be processed in a single pass, which is the recommended configuration for most deployments, although a non-zero value may be required when importing a very large number of entries if the amount of memory required for index post-processing exceeds the total amount available to the server. Changes will not take effect for any import that may already be in progress. 0 ds-cfg-import-pass-size Specifies the size (in number of entries) of the queue that will be used to hold the entries read during an LDIF import. Changes will not take effect for any import that may already be in progress. 100 ds-cfg-import-queue-size Default to something derived from the backend-id Specifies the location of the directory that will be used for the files used to hold temporary information that will be used during the index post-processing phase of an LDIF import. The specified directory will only be used while an import is in progress and the files created in this directory will be deleted as they are processed. It may be an absolute path or one that is relative to the instance root directory. Changes will not take effect for any import that may already be in progress. ds-cfg-import-temp-directory Specifies the number of threads that will be used for concurrent processing during an LDIF import. This should generally be a small multiple (e.g., 2x) of the number of CPUs in the system for a traditional system, or equal to the number of CPU strands for a CMT system. Changes will not take effect for any import that may already be in progress. 8 ds-cfg-import-thread-count Specifies the maximum number of entries that will be allowed to match a given index key before that particular index key is no longer maintained. This property is analogous to the ALL IDs threshold in the Sun Java System Directory Server. Note that this is the default limit for the backend, and it may be overridden on a per-attribute basis.A value of 0 means there is no limit. If any index keys have already reached this limit, indexes will need to be rebuilt before they will be allowed to use the new limit. 4000 ds-cfg-index-entry-limit Specifies the permissions that should be applied to the directory containing the server database files. They should be expressed as three-digit octal values, which is the traditional representation for UNIX file permissions. The three digits represent the permissions that will be available for the directory's owner, group members, and other users (in that order), and each digit is the octal representation of the read, write, and execute bits. Note that this only impacts permissions on the database directory and not on the files written into that directory. On UNIX systems, the user's umask will control permissions given to the database files. 700 ^7[0-7][0-7]$ MODE Any octal value between 700 and 777 (the owner must always have read, write, and execute permissions on the directory). ds-cfg-db-directory-permissions Specifies the length of time that the backend will be allowed to spend "pre-loading" data when it is initialized. The pre-load process may be used to pre-populate the database cache so that it can be more quickly available when the server is processing requests. A duration of zero means there will be no pre-load. 0s ds-cfg-preload-time-limit Specifies the maximum number of entries that may be deleted from the backend when using the subtree delete control. If a subtree delete operation targets a subtree with more than this number of entries, then multiple passes may be required to remove all entries in that subtree. 100000 ds-cfg-subtree-delete-size-limit Specifies the maximum number of entries that may be deleted from the backend when using the subtree delete control within a single transaction. If a subtree delete operation targets a subtree with more than this number of entries, then additional transactions are used to remove the remaining entries in that subtree. 5000 ds-cfg-subtree-delete-batch-size The percentage of JVM memory to allocate to the database cache. Specifies the percentage of memory available to the JVM that should be used for caching database contents. Note that this will only be used if the value of the db-cache-size property is set to "0 MB". Otherwise, the value of that property will be used instead to control the cache size configuration. 10 ds-cfg-db-cache-percent The amount of JVM memory to allocate to the database cache. Specifies the amount of memory that should be used for caching database contents. A value of "0 MB" indicates that the db-cache-percent property should be used instead to specify the cache size. 0 MB ds-cfg-db-cache-size Specifies the minimum percentage of "live" data that the database cleaner will attempt to keep in database log files. If the amount of live data in any database log file drops below this percentage, then the cleaner will move the remaining live data in that file to the end of the database and will delete the original file in order to keep the database relatively compact. 75 ds-cfg-db-cleaner-min-utilization This indicates whether the database cleaner threads should be enabled. The cleaner threads will be used to periodically compact the database by identifying database files with a low (i.e., less than the amount specified by the db-cleaner-min-utilization property) percentage of live data, moving the remaining live data to the end of the log and deleting that file. true ds-cfg-db-run-cleaner Indicates whether the database should evict existing data from the cache based on an LRU policy (where the least recently used information will be evicted first). If the value of this configuration property is set to "false", then eviction will prefer to keep internal nodes of the underlying Btree in the cache over leaf notes, even if the leaf nodes have been accessed more recently, which may be a better configuration for databases in which only a very small portion of the data is cached. true ds-cfg-db-evictor-lru-only Specifies the number of Btree nodes that should be evicted from the cache in a single pass if it is determined that it is necessary to free existing data in order to make room for new information. Changes to this property do not take effect until the backend is restarted. It is recommended that you also change this property when you set db-evictor-lru-only to false. This setting controls the number of Btree nodes that are considered, or sampled, each time a node is evicted. A setting of 100 often produces good results, but this may vary from application to application. The larger the nodes per scan, the more accurate the algorithm. However, setting it too high is detrimental; the need to consider larger numbers of nodes for each eviction may delay the completion of a given database operation, which will impact the response time of the application thread. 10 ds-cfg-db-evictor-nodes-per-scan Specifies the maximum size that may be used for a database log file. 50mb ds-cfg-db-log-file-max Indicates whether the database should maintain a je.info file in the same directory as the database log directory. This file will contain information about the internal processing performed by the underlying database. true ds-cfg-db-logging-file-handler-on Use an enumeration This specifies the log level that should be used by the database when it is writing information into the je.info file. The database trace logging level is (in increasing order of verbosity) chosen from: OFF, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, ALL. CONFIG ds-cfg-db-logging-level Specifies the maximum number of bytes that may be written to the database before it will be forced to perform a checkpoint. This can be used to bound the recovery time that may be required if the database environment is opened without having been properly closed. If this property is set to a non-zero value, the checkpointer wakeup interval is not used. To use time based checkpointing, set this property to zero. 20mb ds-cfg-db-checkpointer-bytes-interval Specifies the maximum length of time that may pass between checkpoints. Note that this will only be used if the value of the checkpointer bytes interval is zero. 30s ds-cfg-db-checkpointer-wakeup-interval This specifies the number of lock tables that should be used by the underlying database. This can be particularly important to help improve scalability by avoiding contention on systems with large numbers of CPUs. The value of this configuration property should be set to a prime number that is less than or equal to the number of worker threads configured for use in the server. 19 ds-cfg-db-num-lock-tables Specifies the number of threads that the backend should maintain to keep the database log files at or near the desired utilization. In environments with high write throughput, multiple cleaner threads may be required to maintain the desired utilization. 1 ds-cfg-db-num-cleaner-threads Indicates whether database writes should be primarily written to an internal buffer but not immediately written to disk. Setting the value of this configuration attribute to "true" may improve write performance but could cause some number of the most recent changes to be lost if the OpenDS Directory Server or the underlying JVM exits abnormally, or if an OS or hardware failure occurs (a behavior similar to running with transaction durability disabled in the Sun Java System Directory Server). false ds-cfg-db-txn-no-sync Indicates whether the database should synchronously flush data as it is written to disk. If this value is set to "false", then all data written to disk will be synchronously flushed to persistent storage and thereby providing full durability. If it is set to "true", then data may be cached for a period of time by the underlying operating system before actually being written to disk. This may improve performance, but could cause some number of the most recent changes to be lost in the event of an underlying OS or hardware failure (but not in the case that the OpenDS Directory Server or the JVM exits abnormally). true ds-cfg-db-txn-write-no-sync Specifies the database and environment properties for the Berkeley DB Java Edition database serving the data for this backend. Any Berkeley DB Java Edition property can be specified using the following form: property-name=property-value Refer to OpenDS documentation for further information on related properties, their implications and range values. The definitive identification of all the property parameters available in the example.properties file of Berkeley DB Java Edition distribution. ds-cfg-je-property