OpenLDAP Performance Tuning 8.0: Difference between revisions

(Created page with "{{ZC}}{{Article Infobox|{{admin}}|{{ZCS 7.0}}|{{ZCS 6.0}}||}}=Zimbra OpenLDAP Server= Currently only one master LDAP server can be set up; this server is authoritative for user ...")
 
No edit summary
 
(30 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{ZC}}{{Article Infobox|{{admin}}|{{ZCS 7.0}}|{{ZCS 6.0}}||}}=Zimbra OpenLDAP Server=
{{BC|Certified}}
__FORCETOC__
<div class="col-md-12 ibox-content">
=OpenLDAP Performance Tuning 8.0=
{{KB|{{ZC}}|{{ZCS 8.0}}||}}
{{WIP}}
=Zimbra OpenLDAP Server=
As of 8.0.0, multiple master LDAP servers can be set up; these servers are authoritative for user information, server configuration, etc.  Zimbra recommends having no more than 4 master servers deployed. Replica LDAP servers can be defined to improve performance and to reduce the load on the master servers. All updates are made to the master servers and these updates are then replicated to the replica servers.


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.
See also the documentation on configuring [http://wiki.zimbra.com/wiki/LDAP_Multi_Master_Replication Multiple Masters].


Upcoming on radar: [http://bugzilla.zimbra.com/show_bug.cgi?id=27872 RFE 27872 - Support multi-master LDAP deployment]
You may also wish to read over the entire set of keys available on the [http://wiki.zimbra.com/wiki/OpenLDAP_Tuning_Keys_8.0 OpenLDAP Tuning Keys Wiki].
 
You may also wish to read over the entire set of keys available on the [http://wiki.zimbra.com/wiki/OpenLDAP_Tuning_Keys OpenLDAP Tuning Keys Wiki].


== OpenLDAP Server Tuning ==
== OpenLDAP Server Tuning ==
For best performance, the following settings should be modified.  These settings apply to both the master LDAP server and the replica servers.
For best performance, the following settings should be modified.  These settings apply to both the master LDAP server and the replica servers.


* Set the '''threads''' count to an appropriate level. The ZCS default is 8, which is fine for 1 or 2 CPU servers.  The general rule of thumb is 4 threads for every real core.
* Set the '''threads''' count to an appropriate level. The ZCS default is 8, which is fine for servers with up to 8 real cores.  The general rule of thumb is one thread per real core.


  zmlocalconfig -e ldap_common_threads=8
  zmlocalconfig -e ldap_common_threads=8


* Set the '''toolthreads''' count to an appropriate level.  The ZCS default is 1.  It should be set to the number of real cores you have available.  The purpose of the toolthreads setting is to decrease the amount of time it takes to slapadd a database.
* Set the '''toolthreads''' count to an appropriate level.  The ZCS default is 2.  It should be set to 2.  The purpose of the toolthreads setting is to decrease the amount of time it takes to slapadd a database.


  zmlocalconfig -e ldap_common_toolthreads=4
  zmlocalconfig -e ldap_common_toolthreads=2


* Change the entry '''cachesize''' for the primary database. The number set should be the number of configured active accounts and the number of configured active domains. The default is 10000.
=== Notes on MDB ===
zmlocalconfig -e ldap_db_cachesize=50000
Starting with ZCS 8, Zimbra has moved to using the new MDB backend for OpenLDAP.  More information on MDB in general can be found at [http://www.symas.com/mdb/ Symas' MDB information page]. ZCS previously used the HDB backend with BerkeleyDB as the underlying database software. Switching to MDB results in an increase in both read and write performance for the LDAP server over previous ZCS releases.  In addition, there are no performance related tuning parameters for MDB.  It simply works out of the box.  You can find performance metric differences for [http://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance MDB vs HDB with Zimbra here].


* Set '''idlcachesize''' for the primary database. The number set should optimally be three times the '''cachesize''' setting.
==== Maximum database size ====
There is one parameter for MDB that deployments may wish to adjust, which is the maximum database size. The default is 80GB on ZCS installations.  When ZCS is installed, a [http://en.wikipedia.org/wiki/Sparse_file sparse file] will be created that will be appear to be the same size as the DB maxsize.  I.e., there will be a "data.mdb" file on disk that appears to be 80GB in size.  In fact, it will only be the size of your actual database. For example:


  zmlocalconfig -e ldap_db_idlcachesize=50000
  zimbra@zre-ldap002:~/data/ldap/mdb/db$ ls -l
total 700
-rw------- 1 zimbra zimbra 85899345920 Nov 29 12:18 data.mdb
-rw------- 1 zimbra zimbra        8192 Nov 29 13:03 lock.mdb
zimbra@zre-ldap002:~/data/ldap/mdb/db$ du -c -h data.mdb
696K    data.mdb
696K    total


* Change the '''dn entry cachseize''' for the primary database.  It is highly recommended to leave it at the default value of zero, which means an unlimited DN cache.  If it is set to a non-zero value, it should be no less than two times the entry cache.
So the actual size of data.mdb is 696KB, although it appears to be 80GB.  The maxsize setting for the database must always be greater than the total size of the LDAP DB or else writes will be rejected, slapd will stop, and data loss may occur.  If it is desired to reduce the maxsize of the database to trim down the size of the sparse file, this can be controlled via the following two localconfig keys:


  zmlocalconfig -e ldap_db_dncachesize=0
  ldap_db_maxsize
ldap_accesslog_maxsize


If you have more than 100 domains, we suggest adjusting the following local config setting:
* The first key is for the primary LDAP DB (/opt/zimbra/data/ldap/mdb/db)
* The second key is for the accesslog DB for LDAP masters (/opt/zimbra/data/ldap/accesslog/db)


* '''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.
Keep in mind that in addition to the size of the data in the database it also needs room for page commits and expansion. If this value is changed to something less than the default of 80GB, careful monitoring of the size of "data.mdb" compared to the maximum size should be implemented.


  # Apply this to all mailbox servers!
====automated database monitoring====
  zmlocalconfig -e ldap_cache_domain_maxsize=30000
With ZCS 8.0.4 and later, there is a cron job named zmldapmonitordb that runs on the LDAP servers to monitor the size of the MDB databases. By default, it will simply alert the admin account if the MDB database is close to running out of space vs its configured max size.  It can be configured to take preemptive action if so desired.  There is no need to restart services if one of the following localconfig keys are changed. The related localconfig keys which can be modified via '''zmlocalconfig''' are:


==Configuring the Berkeley DB subsystem to increase LDAP server performance==
* ldap_monitor_mdb (default true): Whether or not to monitor the LDAP MDB databases.
* ldap_monitor_alert_only (default true): If true, only generate email alerts.  If false, actively adjust the MDB database sizes if possible, and send out an email noting the actions taken.
* ldap_monitor_warning (default 80): The percentage of used space at which to issue a warning alert (and if ldap_monitor_alert_only is false, adjust the MDB maxsize upwards)
* ldap_monitor_critical (default 90): The percentage of used space at which to issue a critical alert (and if ldap_monitor_alert_only is false, adjust the MDB maxsize upwards)
* ldap_monitor_growth (default 25): The percentage of new space to allocate to the MDB database if an alert is triggered and ldap_monitor_alert_only is false


Berkeley DB 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 serviceThere are several parameters involved in tuning the underlying Berkeley DB database. 
====mdb_stat utility====
The mdb_stat utility ships with ZCS 8.0.2 and later.  It allows the gathering of various information about the state of the MDB database via the command lineAvailable options are


===Berkeley DB and Shared memory keys===
* -e: prints database environment information
Starting with ZCS 6.0 and later, it is possible to instruct slapd to allocate a shared memory key for usage with the Berkeley DB cache backing files.  Prior to ZCS 6.0, a disk-based backing cache was always used.  Using a shared memory key rather than using a disk-based cache shows a 3x improvement over the disk-based method IF and ONLY IF the size of your database is over 8GB, and results in the same amount of memory usage as the disk-based backing cache.  To configure the LDAP server to use a shared memory key takes multiple steps.  You will need to use the value of your BDB cachesize (See Berkeley DB DB_CONFIG section below) to set the correct values.
* -f: prints the freelist information
* -a: prints out the information for all sub-databases (indexes and entry database)
* -s '''sub database''': prints out the information specific to the sub database specified


* Get the current configured pagesize for the system
Format is:
<code>
mdb_stat [-e] [-f] [-a|-s subdb]/path/to/database
</code>


  getconf PAGE_SIZE
Examples:
  <code>
mdb_stat -f /opt/zimbra/data/ldap/mdb/db
mdb_stat -a -e -f /opt/zimbra/data/ldap/mdb/db
mdb_stat -s id2e /opt/zimbra/data/ldap/mdb/db
</code>


* Divide the amount of RAM you will need for your shared memory key by the value of PAGE_SIZE, and assign this to the kernel.shmall sysctl value. For example, if I have a 14GB BDB cachesize and the PAGE_SIZE result is 4096, the setting would be 3801088.  Which is 14.5*1024*1024*1024/4096The extra .5 GB is for other OS processes that will also need to use shared memory.
====mdb_copy utility====
The mdb_copy utility ships with ZCS 8.0.2 and laterIt allows one to safely copy an MDB database from one location to another via the command lineThis utility can be used while slapd is running.
# For Linux add to /etc/sysctl.conf:
  kernel.shmall=3801088
# Then update the currently used value:
/sbin/sysctl -e kernel.shmall=3801088


# For OSX 10.5 add to/etc/sysctl.conf:
Format is:
kern.sysv.shmall=3801088
  mdb_copy /src/dir /destination/dir
# Then update the currently used value:
  /usr/sbin/sysctl -w kern.sysv.shmall=3801088


  # For OSX 10.4, modify the current listed value for kernel.sysv.shmall in the /etc/rc file
Example:
  # if necessary.  The line will look similar to:
  <code>
#sysctl -w kern.sysv.shmmax=4194304 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=3801088
mdb_copy /opt/zimbra/data/ldap/mdb/db /opt/zimbra/backups/ldap/mdb/db
  </code>


* Configure the maximum size allowed for an individual shared memory keyFor example, if I have a 14GB BDB cachesize, the value would be 15032385536 (14*1024*1024*1024).
Note: The copied MDB file will *not* be a sparse file.  It will be the actual size of the databaseI.e., if your databse is 25MB in size, the resulting copied database will be a full 25MB, and not an 80GB sparse file.


# For Linux add to /etc/sysctl.conf:
=== Mailbox store tuning with LDAP ===
kernel.shmmax=15032385536
If you have more than 500 domains, we suggest adjusting the following local config setting:
# Then update the currently used value:
/sbin/sysctl -e kernel.shmmax=15032385536


# For OSX 10.5 add to /etc/sysctl.conf:
* '''ldap_cache_domain_maxsize'''. This sets the cache of the number of domains in the server. The default is 500. If more than 500 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 this to 30000.
kernel.sysv.shmmax=15032385536
# Then update the currently used value:
/usr/sbin/sysctl -w kern.sysv.shmmax=15032385536


  # For OSX 10.4, modify the current listed value for kernel.sysv.shmmax in the /etc/rc file
  # Apply this to all mailbox servers!
# if necessary.  The line will look similar to:
  zmlocalconfig -e ldap_cache_domain_maxsize=30000
#sysctl -w kern.sysv.shmmax=15032385536 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=3801088
# Also on OSX 10.4, you will now want to run your fully modified sysctl line:
/usr/sbin/sysctl -w kern.sysv.shmmax=15032385536 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=3801088
 
* For all OSes, as the zimbra user, you will now need to tell slapd to use a shared memory key by setting it in localconfig.  slapd and zmmtaconfig must both be running.  On a master, it is also possible to tell the accesslog database to use a shared memory key.  If a shared memory key is going to be used for both the accesslog and main db, then the shmmax value needs to be the larger of the two BDB cachesizes (this will most likely always be the main db value), and the shmall value needs to be the total of the two databases BDB cachesizes plus .5.  So, if I had an 8 GB main DB and a 2GB accesslog DB cachesize, I would want to use 10.5 as the value for determining shmall size.  Shared memory key values must be unique inside slapd, and they can be set to any number.  For example, to set the main DB to use a shared memory key with the value 5:
 
zmlocalconfig -e ldap_db_shmkey=5
 
* If it was then desired to set the accesslog DB to use a shared memory key, it would need a different unique value:
 
  zmlocalconfig -e ldap_accesslog_shmkey=7
 
* Wait several minutes (it can take up to at least 5 minutes for zmmtaconfig to react to the change) and verify that the modification has occurred in the LDAP configuration database.  The value for olcDbShmKey should match what you set ldap_db_shmkey to be.
 
# On a replica or stand-alone server
ldapsearch -LLL -s base-x -H ldapi:/// -D cn=config -w `zmlocalconfig -s -m nokey ldap_root_password` -b olcDatabase={2}hdb,cn=config olcDbShmKey
# On a master with replication enabled
ldapsearch -LLL -s base-x -H ldapi:/// -D cn=config -w `zmlocalconfig -s -m nokey ldap_root_password` -b olcDatabase={3}hdb,cn=config olcDbShmKey
 
* To check the SHM key value for the accesslog database on a master:
 
# On a master with replication enabled, to check the accesslog DB setting:
ldapsearch -LLL -s base-x -H ldapi:/// -D cn=config -w `zmlocalconfig -s -m nokey ldap_root_password` -b olcDatabase={2}hdb,cn=config olcDbShmKey
 
* Once you have verified the settings have been applied, restart slapd as the zimbra user
 
  ldap stop
  ldap start
 
===Berkeley DB DB_CONFIG tuning===
Most of the tuning for BDB 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/data/ldap/hdb/db'''.  To increase the cache size, add (or replace) the following line to the '''DB_CONFIG''' file in '''/opt/zimbra/data/ldap/hdb/db'''.  The following would set the database in-memory cachesize to 500MB:
 
set_cachesize 0 524288000 1
 
The format for the set_cachesize command is &lt;gigabytes&gt; &lt;bytes&gt; &lt;segments&gt;
 
It is possible to check that the cache setting has taken effect by using the '''/opt/zimbra/bdb/bin/db_stat -m -h /opt/zimbra/data/ldap/hdb/db&#x01c0;head -n 16''' 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
1 Maximum number of caches
500MB Pool individual cache size
0 Maximum memory-mapped file size
0 Maximum open file descriptors
0 Maximum sequential buffer writes
0 Sleep after writing maximum sequential buffers
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/bdb/bin/db_stat -c -h /opt/zimbra/data/ldap/hdb/db&#x01c0;head -n 16''' command can be used to determine current usage:
 
5634 Last allocated locker ID
0x7fffffff 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 lock object partitions
93 Number of current locks
1921 Maximum number of locks at any one time
6 Maximum number of locks in any one bucket
0 Maximum number of locks stolen by for an empty partition
0 Maximum number of locks stolen for any one partition
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/data/ldap/hdb/db'''.  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


{{Article_Footer|ZCS 7.0, ZCS 6.0|9/3/2009}}
{{Article_Footer|ZCS 8.0|7/20/2012}}


[[Category:LDAP]]
[[Category:LDAP]]
[[Category:Performance and Tuning]]
[[Category:Performance and Tuning]]
[[Category:ZCS 7.0]]
[[Category:ZCS 8.0]]
[[Category:ZCS 6.0]]

Latest revision as of 00:45, 11 July 2015

OpenLDAP Performance Tuning 8.0

   KB 18249        Last updated on 2015-07-11  




0.00
(0 votes)

Zimbra OpenLDAP Server

As of 8.0.0, multiple master LDAP servers can be set up; these servers are authoritative for user information, server configuration, etc. Zimbra recommends having no more than 4 master servers deployed. Replica LDAP servers can be defined to improve performance and to reduce the load on the master servers. All updates are made to the master servers and these updates are then replicated to the replica servers.

See also the documentation on configuring Multiple Masters.

You may also wish to read over the entire set of keys available on the OpenLDAP Tuning Keys Wiki.

OpenLDAP Server Tuning

For best performance, the following settings should be modified. These settings apply to both the master LDAP server and the replica servers.

  • Set the threads count to an appropriate level. The ZCS default is 8, which is fine for servers with up to 8 real cores. The general rule of thumb is one thread per real core.
zmlocalconfig -e ldap_common_threads=8
  • Set the toolthreads count to an appropriate level. The ZCS default is 2. It should be set to 2. The purpose of the toolthreads setting is to decrease the amount of time it takes to slapadd a database.
zmlocalconfig -e ldap_common_toolthreads=2

Notes on MDB

Starting with ZCS 8, Zimbra has moved to using the new MDB backend for OpenLDAP. More information on MDB in general can be found at Symas' MDB information page. ZCS previously used the HDB backend with BerkeleyDB as the underlying database software. Switching to MDB results in an increase in both read and write performance for the LDAP server over previous ZCS releases. In addition, there are no performance related tuning parameters for MDB. It simply works out of the box. You can find performance metric differences for MDB vs HDB with Zimbra here.

Maximum database size

There is one parameter for MDB that deployments may wish to adjust, which is the maximum database size. The default is 80GB on ZCS installations. When ZCS is installed, a sparse file will be created that will be appear to be the same size as the DB maxsize. I.e., there will be a "data.mdb" file on disk that appears to be 80GB in size. In fact, it will only be the size of your actual database. For example:

zimbra@zre-ldap002:~/data/ldap/mdb/db$ ls -l
total 700
-rw------- 1 zimbra zimbra 85899345920 Nov 29 12:18 data.mdb
-rw------- 1 zimbra zimbra        8192 Nov 29 13:03 lock.mdb
zimbra@zre-ldap002:~/data/ldap/mdb/db$ du -c -h data.mdb
696K    data.mdb
696K    total

So the actual size of data.mdb is 696KB, although it appears to be 80GB. The maxsize setting for the database must always be greater than the total size of the LDAP DB or else writes will be rejected, slapd will stop, and data loss may occur. If it is desired to reduce the maxsize of the database to trim down the size of the sparse file, this can be controlled via the following two localconfig keys:

ldap_db_maxsize
ldap_accesslog_maxsize
  • The first key is for the primary LDAP DB (/opt/zimbra/data/ldap/mdb/db)
  • The second key is for the accesslog DB for LDAP masters (/opt/zimbra/data/ldap/accesslog/db)

Keep in mind that in addition to the size of the data in the database it also needs room for page commits and expansion. If this value is changed to something less than the default of 80GB, careful monitoring of the size of "data.mdb" compared to the maximum size should be implemented.

automated database monitoring

With ZCS 8.0.4 and later, there is a cron job named zmldapmonitordb that runs on the LDAP servers to monitor the size of the MDB databases. By default, it will simply alert the admin account if the MDB database is close to running out of space vs its configured max size. It can be configured to take preemptive action if so desired. There is no need to restart services if one of the following localconfig keys are changed. The related localconfig keys which can be modified via zmlocalconfig are:

  • ldap_monitor_mdb (default true): Whether or not to monitor the LDAP MDB databases.
  • ldap_monitor_alert_only (default true): If true, only generate email alerts. If false, actively adjust the MDB database sizes if possible, and send out an email noting the actions taken.
  • ldap_monitor_warning (default 80): The percentage of used space at which to issue a warning alert (and if ldap_monitor_alert_only is false, adjust the MDB maxsize upwards)
  • ldap_monitor_critical (default 90): The percentage of used space at which to issue a critical alert (and if ldap_monitor_alert_only is false, adjust the MDB maxsize upwards)
  • ldap_monitor_growth (default 25): The percentage of new space to allocate to the MDB database if an alert is triggered and ldap_monitor_alert_only is false

mdb_stat utility

The mdb_stat utility ships with ZCS 8.0.2 and later. It allows the gathering of various information about the state of the MDB database via the command line. Available options are

  • -e: prints database environment information
  • -f: prints the freelist information
  • -a: prints out the information for all sub-databases (indexes and entry database)
  • -s sub database: prints out the information specific to the sub database specified

Format is:


mdb_stat [-e] [-f] [-a|-s subdb]/path/to/database

Examples:


mdb_stat -f /opt/zimbra/data/ldap/mdb/db
mdb_stat -a -e -f /opt/zimbra/data/ldap/mdb/db
mdb_stat -s id2e /opt/zimbra/data/ldap/mdb/db

mdb_copy utility

The mdb_copy utility ships with ZCS 8.0.2 and later. It allows one to safely copy an MDB database from one location to another via the command line. This utility can be used while slapd is running.

Format is:

mdb_copy /src/dir /destination/dir

Example:


mdb_copy /opt/zimbra/data/ldap/mdb/db /opt/zimbra/backups/ldap/mdb/db

Note: The copied MDB file will *not* be a sparse file. It will be the actual size of the database. I.e., if your databse is 25MB in size, the resulting copied database will be a full 25MB, and not an 80GB sparse file.

Mailbox store tuning with LDAP

If you have more than 500 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 500. If more than 500 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 this to 30000.
# Apply this to all mailbox servers!
zmlocalconfig -e ldap_cache_domain_maxsize=30000
Verified Against: ZCS 8.0 Date Created: 7/20/2012
Article ID: https://wiki.zimbra.com/index.php?title=OpenLDAP_Performance_Tuning_8.0 Date Modified: 2015-07-11



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Jump to: navigation, search