OpenLDAP Performance Tuning 5.0: Difference between revisions
No edit summary
|Line 92:||Line 92:|
[[Category:Performance and Tuning]]
[[Category:Performance and Tuning]]
Revision as of 19:49, 24 November 2009
Zimbra OpenLDAP Server
Currently only one master LDAP server can be set up; this server is authoritative for user information, server configuration, etc. Replica LDAP servers can be defined to improve performance and to reduce the load on the master server. All updates are made to the master server and these updates are copied to the replica servers.
We don't recommend running more than 6 replicas.
The more replicas you have the more threads there are trying to sync with the only master. If you over-saturate things there's a higher likelihood some replicas will fall behind while others monopolize the master, particularly in a heavy write environment. Daisy-chaining replicas is another matter/not a typical configuration for the purposes of this document.
Upcoming on radar: RFE 27872 - Support multi-master LDAP deployment > RFE 21991 - OpenLDAP 2.4 upgrade with BDB 4.7
LDAP server performance modifications
For best performance, the following settings in the /opt/zimbra/conf/slapd.conf.in file should be modified. These settings apply to both the master LDAP server and the replica servers.
Note: Changes to slapd.conf.in have to be re-applied after an upgrade.
- Add a command to set the threads count to 8. The default is 16. The threads config should be above the pidfile setting.
- Change cachesize. The number set should be the number of configured active accounts and the number of configured active domains. The default is 10000.
# number of entries to keep in memory cachesize 50000
- Set idlcachesize. The number set should be the same as the cachesize setting.
Important: You must restart the LDAP server after you make these changes. cachesize and idlcachesize should be configured in the database section (look for existing values and modify them).
If you have more than 100 domains, we suggest adjusting the following local config setting:
- ldap_cache_domain_maxsize. This sets the cache of the number of domains in the server. The default is 100. If more than 100 domains are configured, you should adjust this to the lower of the number of domains you have configured and 30,000. For example, with 45,000 domains, set as this to 30000.
# Apply this to all mailbox servers! zmlocalconfig -e ldap_cache_domain_maxsize=30000
Configuring the BDB subsystem to increase LDAP server performance
BDB is the underlying high-performance transactional database used to store the LDAP data. Proper configuration of this database is essential to maintaining a performant LDAP service. There are several parameters involved in tuning the underlying BDB database. This always involves editing the DB_CONFIG file. Modifications to the DB_CONFIG file require a restart of the LDAP server before they are picked up, and should be made to both master and replica servers. The proper way to do this for Zimbra is documented at Managing_Customized_BDB_configurations
You can increase LDAP server performance by adjusting the BDB backend cache size to be at or near the size of your data set. This is subject to the limit of 4 GB for 32 bit and 10 TB for 64 bit, and the amount of RAM you have. The size of the data set is the sum of the Berkeley DataBase (BDB) files in /opt/zimbra/openldap-data. To increase the cache size, add (or replace) the following line to the DB_CONFIG file in /opt/zimbra/openldap-data/. The following would set the database in-memory cachesize to 500MB:
set_cachesize 0 524288000 1
The format for the set_cachesize command is <gigabytes> <bytes> <segments>
On 32 bit systems, when setting cachesize greater than 2 GB, the cachesize must be split across multiple segments, such that no one segment is larger than 2 GB. For example, for 4 GB, to split across multiple segments, you would type.
set_cachesize 4 0 2
It is possible to check that the cache setting has taken effect by using the /opt/zimbra/sleepycat/bin/db_stat -m -h /opt/zimbra/openldap-dataǀhead -n 11 command can be used to see the current cache setting, as well as to find other important information. Example output:
500MB Total cache size 1 Number of caches 500MB Pool individual cache size 0 Requested pages mapped into the process' address space. 3437M Requested pages found in the cache (100%). 526125 Requested pages not found in the cache. 47822 Pages created in the cache. 526125 Pages read into the cache. 27M Pages written from the cache to the backing file. 0 Clean pages forced from the cache. 0 Dirty pages forced from the cache.
The above output shows that there is a 500MB total cache in a single segment all of which is allocated to the cache pool. The other important data to evaluate are the Requested pages found in the cache, the Clean pages forced from the cache and the Dirty pages forced from the cache. For optimal performance, the Requested pages found in the cache should be above 95%, and the pages forced from the cache should be 0.
As part of the transaction interface, BDB uses a number of locks, lockers, and lock objects. The default value for each of these parameters is 1000. How many of each are being used depends on the number of entries and indices in the BDB database. The /opt/zimbra/sleepycat/bin/db_stat -c -h /opt/zimbra/openldap-dataǀhead -n 12 command can be used to determine current usage:
5634 Last allocated locker ID. 2147M Current maximum unused locker ID. 9 Number of lock modes. 3000 Maximum number of locks possible. 1500 Maximum number of lockers possible. 1500 Maximum number of lock objects possible. 93 Number of current locks. 1921 Maximum number of locks at any one time. 483 Number of current lockers. 485 Maximum number of lockers at any one time. 93 Number of current lock objects. 1011 Maximum number of lock objects at any one time.
The above output shows that there are a maximum of 3000 locks, 1500 lockers, and 1500 lock objects available to the BDB database located in /opt/zimbra/openldap-data. Of those settings, there are currently 93 locks in use, 483 lockers in use, and 93 lock objects in use. Over the course of the lifetime of the database, the highest recorded values have been 1921 locks used, 485 lockers used, and 1011 lock objects used. As long as usage is within 85% of the configured value(s), it should not be necessary to modify the settings.
The following entries in DB_CONFIG would increase the number of locks to 3000, the lock objects to 1500, and the lockers to 1500:
set_lk_max_locks 3000 set_lk_max_objects 1500 set_lk_max_lockers 1500