Re: 2.1.17 performance issues

[BsD JuNkiE <bsd_junkie@fastmail.fm>]

Ok, thanks for the input. I noticed you made reference that by using dbm
my data would be safe, are you saying that by using ldbm for its quicker
speed i would be sacrificing data security? 

thanks

xoror@infuse.org wrote:
> On Thu, 17 Apr 2003, BsD JuNkiE wrote:
>
> > Is GDBM better than Berkeley DB in terms of reliability "Stability" and 
> > speed?
> > I am encountering the same slow ,"very slow at times", searches after we 
> > hit about 2500+ queries
> > and usually slapd will just stop responding or sometimes crash after we 
> > hit 3200+.
> > We are testing Openldap 2.1.17 in our lab, here is the specs:
> >   
>
> Hi 
>
> increasing the cache size solved the problem here (set cache size in
> DB_CONFIG, see my previous postings). Be sure to have your cache big
> enough. Be sure also to test a couple of 100k operations, because
> when your cache is full it will somehow try to swap out old pages en read
> in new pages. this process is __very__ slow (i haven't figured out why
> yet, it shouldn't be this bad).
>
> LDBM is faster then bdb. this is logical since bdb does WAL and has
> transaction overhead. But you data is 'safe' with BDB.
>
>  
> > openldap 2.1.17 server: AMD athlon 2-ghz , 1-gig pc 2100 ram, segate sci 
> > disks and intel pro 10/100 nic.
> >
> > OS: we have tried openldap on several os's with same speed problems,.... 
> > FreeBSD, NetBSD, OpenBSD and Linux.
> >
> > network connections: 10/100 / switched
> >
> > slapd conf:
> >
> > # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.5 2002/11/26 
> > 18:26:01 kurt Exp $
> > #
> > # See slapd.conf(5) for details on configuration options.
> > # This file should NOT be world readable.
> > #
> > include         /usr/local/etc/openldap/schema/core.schema
> > include           /usr/local/etc/openldap/schema/cosine.schema
> > include           /usr/local/etc/openldap/schema/inetorgperson.schema
> > include           /usr/local/etc/openldap/schema/nis.schema
> >
> >
> > # Define global ACLs to disable default read access.
> >
> > #pidfile          /usr/local/var/slapd.pid
> > argsfile        /usr/local/var/slapd.args
> >
> >
> > access to attr=userPassword
> >     by dn="cn=admin,dc=dev-null,dc=homeunix,dc=org" write
> >     by self write
> >     by * auth
> > access to *
> >     by dn="cn=admin,dc=dev-null,dc=homeunix,dc=org" write
> >     by self    read
> >     by anonymous read
> >
> >
> >
> > #######################################################################
> > # Database 1 "dev-null.homeunix.org"
> > #######################################################################
> >
> > database        bdb
> > suffix          "dc=dev-null, dc=homeunix, dc=org"
> > rootdn          "cn=Manager,dc=dev-null, dc=homeunix, dc=org"
> > schemacheck  on
> >
> > # Cleartext passwords, especially for the rootdn, should
> > # be avoid.  See slappasswd(8) and slapd.conf(5) for details.
> > # Use of strong authentication encouraged.
> > rootpw          test
> > # The database directory MUST exist prior to running slapd AND
> > # should only be accessible by the slapd/tools. Mode 700 recommended.
> > directory    /var/LDAP/var/openldap-data/qmail
> > # Indices to maintain
> >
> > index cn,sn,uid pres,eq
> > index mail,mailAlternateAddress eq
> > index objectClass eq
> >
> >
> > here is the ldif used to setup the initial database:
> >
> > dn: dc=dev-null,dc=homeunix,dc=org
> > objectclass: dcObject
> > objectclass: organization
> > o: test
> > dc: test
> >
> > dn: cn=admin,dc=dev-null,dc=homeunix,dc=org
> > objectclass: top
> > objectclass: person
> > userPassword: tx07334664
> > cn: admin
> > sn: admin
> >
> > dn: ou=people, dc=dev-null,dc=homeunix,dc=org
> > objectclass: top
> > objectclass: organizationalUnit
> > ou: people
> >
> >
> > dn: ou=groups, dc=dev-null,dc=homeunix,dc=org
> > objectclass: top
> > objectclass: organizationalUnit
> > ou: groups
> >
> >
> >
> > ldapadd -vxc -h localhost -D "cn=Manager,dc=dev-null,dc=homeunix,dc=org" 
> > -w test -f ./setup.ldif
> >
> >
> > Our goal is to switch from netscape to openldap but currently that is 
> > not feasible as the netscape ldap server is serving a user base of about 
> > 25000. If we can get the speed issues resolved it should work, i am 
> > looking into using load balancing with maybe 3 openldap servers to see 
> > if this might work in the meantime.
> >
> > Andreas wrote:
> >
> > > On Wed, Apr 16, 2003 at 01:52:07PM -0300, Andreas wrote:
> > >  
> > >
> > > > - number of entries in the directory
> > > > - indexes being used
> > > > - cpu/ram
> > > > - performance (btw, how does one measure this?)
> > > >    
> > > >
> > > >       
> > > Answering to myself, it would be interesting to repeat these tests
> > > with current versions of openldap and libdb, since they were done with
> > > openldap-2.0.7:
> > >
> > > http://www.daasi.de/staff/norbert/thesis/
> > >
> > > Page 73 has some graphs
> > >
> > >
> > >  
> > >
> > >     
> >