[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: optimisation

> >>I have imported over 40,000 entries (person's) to the server however now
> >>when our mail servers  do a look up it times out... it just seems to take
> >>ages to retrieve the information. (there are only 40,000 entries in this
> >>ldbm - surely it can take more?)
> >>We installed Netscape Directory Server on the same machine (different
> >>port) and used the same entries and the Mail servers worked fine.
> >>Is there something fundamental which I have forgotten to optimise
> >>OpenLDAP?
> >>Will the INDEX command help at all and if so how is it best to use this?
> >Yes.  Refer to the documentation on slapd.conf.  When you add the index
> >you will have to dump your database to an ldif file so that you can
> >generate the index.  I've previously posted to this list the procedure
> >for how to do this, and you may also find information about it in the
> >FAQ-O-MATIC.  Alternatively, you could add the index and reload the
> >entire database, which shouldn't take long for only 40,000 entries.
> >You should probably have at least presence and equality indexes.
> Does anyone have any formulas for tuning the dbcachesize (memory cache for
> indexes) and cachesize (memory cache for elements)?  What are the best
> statistics to look at to know if these need to grow?  It is my understanding
> that "cachesize" is actually the number of objects to cache in memory and not a
> Kb number,  since object can vary greatly in size this seems like a real hard
> one to manage.

Dbcachesize is relevant more to the underlying database, vs. OpenLDAP
itself.  If you are using the Sleepycat 2.7.7 underneath LDBM, for
example, then go to the www.sleepycat.com site and look there for
more information on caching.  Most of the documentation is now for DB 3.1,
but the principles will be the same.  By the way, dbcachesize (last I looked)
only applies to the index files, not to the id2entry.dbb.

As for cachesize, there's going to be a diminishing return for a given
cachesize.  Where the shape of the size vs. time curve is begins to get
flat is about where you want your cachesize.  That's going to depend on
the degree of randomness of the searches (and modifications) it is asked
to do.