一个介绍如何tunning openLDAP的文章!好!
http://www.tivoli.com/support/pu ... am39_perftune05.htm
Performance Tuning Guide
--------------------------------------------------------------------------------
Special case IBM LDAP directory tunings
This section contains tunings that are not normally recommended; however, but there may be some environments where these tunings are useful.
--------------------------------------------------------------------------------
Using LDAP cache
The LDAP cache is more efficient in memory usage and speedier than the DB2 cache, yet not as efficient as the Access Manager credential cache. Disadvantages to the LDAP cache are that it becomes invalidated on most update operations and can take a long time to load. The environments that gain most from LDAP caching are those with small registry sizes and few updates.
Keep in mind that increasing the LDAP cache size can cause the slapd process memory size to exceed system limits. For information about increasing these limits, see " rocess memory size limits".
Setting the LDAP cache parameters
The LDAP cache parameters that are recommended for use with Access Manager are RDBM_CACHE_SIZE and RDBM_FCACHE_SIZE. These parameters are defined to LDAP with environment variables. To define LDAP cache environment variables, do either of the following:
To define the LDAP cache environment variables in the command shell (before starting slapd), run the following commands:
stop LDAP (slapd process)
export RDBM_CACHE_SIZE=<value>
export RDBM_FCACHE_SIZE=<value>
start LDAP (slapd process)
To define the LDAP cache environment variables in the slap32.conf file, add the following entries to the file as follows:
dn: cn=Front End,cn=Configuration
objectclass: top
objectclass: ibm-slapdFrontEnd
ibm-slapdSetEnv: RDBM_CACHE_SIZE=<value>
ibm-slapdSetEnv: RDBM_FCACHE_SIZE=<value>
For information on the definition of these and other LDAP cache parameters, see the IBM SecureWay Directory documentation ("IBM SecureWay Directory").
Choosing the LDAP cache values for Access Manager
The primarily use of the LDAP cache is for caching authenticated users. There are a couple of ways to choose values for the LDAP cache parameters. One is to base the choice on the number of users to be cached. Another is to base the choice on the amount of memory available for caching. Both ways require information on the memory usage per cached user and the number of cache entries used per cached user.
For Access Manager, the memory usage per cached user is approximately 3 KB and the number of cache entries used (per cached user) is four for the entry cache and five for the filter cache. The entry cache is controlled by RDBM_CACHE_SIZE and the filter cache is controlled by RDBM_FCACHE_SIZE. These approximations vary greatly with the various Access Manager configuration settings and usage.
The following items affect Access Manager's use of LDAP cache resources:
User-and-group-in-same-suffix setting in the webseald.conf file
Default-policy-override-support setting in the webseald.conf file
Ordering and number of LDAP suffixes in the /etc/slapd32.conf file
Authenticating through GSO junctions
Whether the user was created using Version 3.7 or Version 3.8 of IBM Tivoli SecureWay Policy Director. Related to this is the usage of the PD38_SCHEMA_OFF environment variable.
Note:
An LDAP registry containing users that were created using a version of Policy Director earlier than Version 3.8 does not immediately benefit from the LDAP cache. The reason for this is that Access Manager performs an automatic migration of pre-Version 3.8 users to the new attributes introduced in Policy Director, Version 3.9. This automatic migration causes updates to LDAP that invalidate or remove users from the cache. For information about the PD38_SCHEMA_OFF parameter and turning off automatic migration, see"Automatic migration of IBM SecureWay Policy Directory 3.7 users during authentication".
Choosing cache values based on the number of users to be created
Use the following formulas for choosing the LDAP cache settings:
LDAP entry cache size = (number of AM users) * 4
LDAP filter cache size = (number of AM users) * 5
Memory requirements = (number of AM users) * 3 KB
Choosing cache values based on the amount of memory available for caching
Use the following formulas for choosing the LDAP cache settings:
number of AM users cached = desired memory usage / 3 KB
LDAP cache size = (number of AM users) * 4
LDAP filter cache size = (number of AM users) * 5
Example cache size settings
The following table provides guidelines for cache size settings. Because these settings might not apply in every case, make certain to verify them (as explained in the following section).
Table 1. Cache Size Settings
Number of AM Users Entry Cache Size Filter Cache Size Memory Usage Additional Data Segments Needed (AIX)
10,000 40000 50000 30 MB 0
50,000 200000 250000 150 MB 0
100,000 400000 500000 300 MB 1
Verifying the LDAP cache resources usage
Typically, there are two things to verify regarding the LDAP cache settings. One is whether cache misses have been eliminated and another is if the LDAP process memory usage is as expected.
To verify that cache misses have been eliminated, issue the following commands periodically while LDAP searches are in progress:
ldapsearch -h ldap_host -s base -b 'cn=monitor' 'objectclass=*' │
grep entry_cache_miss
If all results come from the LDAP cache, the entry_cache_miss count remains constant throughout the usage of LDAP.
To verify that the LDAP cache memory usage is as expected, monitor the process memory growth as users are cached. The UNIX ps utility is recommended. For example, the following ps command shows the current memory size of the LDAP process:
ps -e -o vsz -o -comm │ grep slapd
Repeat this command periodically to determine what at what memory size the slapd process is when it levels off.
To verify that the LDAP cache memory usage does not exceed process memory size limits, watch the slapd process and verify that it does not end unexpectedly. If the slapd process ends after increasing the LDAP cache, it is probably because it has exceeded the memory limits.
-------------------------------------------------------------------------------- |