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

RE: 2.2.23 vs 2.3.1alpha speed compairisons

On Mon, 2005-02-21 at 20:24, Quanah Gibson-Mount wrote:
> --On Monday, February 21, 2005 6:39 PM -0500 Samuel Tran <stran@amnh.org> 
> wrote:
> >> Here a extract of my slapd.conf:
> >
> > cachesize       100000
> > checkpoint      512     720
> If you have 4,000 entries, why would you try and cache 100,000?  You're 
> never going to fill that.  I also don't see any idlcachesize setting here.

Should I set cachesize to the size of my directory, ie 4,000 ?
Ok. I forgot idlcachesize. I am not sure what size I should use here.

> > index   objectClass,uid,uidNumber,gidNumber,memberUid eq
> > index   cn,mail,surname,givenname eq,subinitial
> The indexing necessary depends entirely on the searches you are performing. 
> I would check that your logs to see if you are getting any index_param 
> failed messages, which would mean inadequate indexing for the requested 
> search.


> > Here is the content of my DB_CONFIG:
> >
> > set_cachesize   0       52428800        0
> > set_lg_regionmax        1048576
> > set_lg_max              10485760
> > set_lg_bsize            2097152
> > set_lg_dir              /var/log/openldap_bdb
> > set_tmp_dir             /tmp
> >
> > We are starting with less than 4,000 entries in our LDAP directory.
> I would assume that is fine for now, but that's just an assumption. ;)
> Also, is the 350 queries/second from a single process doing the query, or 
> multiple processes?  A single process querying will never give you the full 
> results of the servers performance.

No each query is done by a single process.

I am resinstalling BDB-4.2.52 with the transaction patch.
If i am not mistaken, in order to have TXN_NOLOG set I need to have DB_TXN_NOT_DURABLE set in DB_CONFIG.

From Sleepycat doc:

        If set, Berkeley DB will not write log records for this
        database. This means that updates of this database exhibit the
        ACI (atomicity, consistency, and isolation) properties, but not
        D (durability); that is, database integrity will be maintained,
        but if the application or system fails, integrity will not
        persist. [snip]

Isn't it a bigger risk to use this flag?

Thanks for your help.

Attachment: signature.asc
Description: This is a digitally signed message part