The cachesize & idlcachesize are calculated using some formula we have been using where we account for sudden increase in ldap entries. But the difference does seem to be too much. I will change it. Is it ok to change cachesize and restart ldap daily or should ldap be allowed to run for longer period of time ?

I was in doubt about the threads setting too. On googling I found that number of threads should be equal to 4 times the number of cpu cores. But which cores, the physical or the logical? logical meaning the number of cpus listed in /proc/cpuinfo.

Thanks a lot in advance.

Amol

----- Original Message -----

From: Quanah Gibson-Mount

Sent: 09/15/09 11:40 pm

To: Amol Kulkarni, openldap-technical@openldap.org

Subject: Re: connections falling short

 

--On Tuesday, September 15, 2009 2:08 PM +0200 Amol Kulkarni
wrote:

>
>
>
> Hi Quanah,
>
> Sorry to trouble you, but I was a bit early in reporting that the problem
> was solved. Indeed the problem is not solved even after setting the
> cachesizes correct. 
>
> Foll. is the info abt the server :
>
>
> OpenLDAP Release - symas-openldap-silver-2.4-12.1
>
> BDB version and patch level - not sure abt this
>
> Size of database on disk - 1.3 g
>
> DB_CONFIG parameters - 
>   set_cachesize 0 1944506368 1
>   set_lg_regionmax 262144
>   set_lg_bsize 2097152
>   set_flags DB_LOG_AUTOREMOVE
>    
> slapd.conf/cn=config tuning done (cachesize, idlcache, etc)
>   loglevel 256
>   threads 8

If your total number of entries is 328177 where did you get the following
numbers? They make no sense. The cachesize should match (or only be
slightly larger than, say 350000) the total number of entries.
idlcachesize for back-bdb, since that is what you using, would probably be
find then at 700,000.


>   cachesize 950817
>   idlcachesize 2852451

Upgrading as was already suggested is probably a wise thing to do, too.
 

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration