Re: Corruption of Index files running readonly slapd (ITS#2582)

[Franky Van Liedekerke <liedekef@pandora.be>]

This seems to be more of a indexing problem to me. Aare all the correct
indexes defined on the database? Searching a large setup for a
non-indexed field can cause major problems ...

Franky

On Thu, 26 Jun 2003 10:53:49 +0200
Christoph Neerfeld <Christoph.Neerfeld@fh-bonn-rhein-sieg.de> wrote:

> 
> We have quite the same problem. In our setup we have only 500 entries 
> and at most 200 client machines. The database is mostly read only 
> besides the changes of user passwords.
> 
> After the import of the data via ldif the server runs very fast and 
> after three weeks the performace degrades dramatically. slapd starts 
> eating up cpu cycles for each request. Restarting slapd does not 
> change anything.
> 
> I read the FAQ and most parts of the bdb documentation. AFAIR most 
> tips for performance tuning are related to write access to the 
> database which is of no concern to us.
> The only hint I found is to increase the bdb cache but
> 'db_stat -m' already reports a cache hit rate of 98%.
> 
> So I tried another thing. I stoped slapd, removed those __db.00? files
> and all log.00* files which db_archive reported are not longer used 
> and started slapd again. I don't know if this can corrupt my database 
> but it fixes the problem. slapd runs again with the same speed as 
> after a fresh import of the data.
> 
> If this is a configuration problem and no bug I would appreciate any 
> hints to what I have to change.
> 
> Here are some details to our setup:
> 
> - Linux SMP kernel 2.4.20 running on i386 with two processors
> - debian woody
> - ext2 filesystem
> - openldap 2.1.21
> - bdb 4.1.25 compiled with --disable-largefiles
> 
> Regards
> 
> Christoph Neerfeld
> 
> > There are other sites with larger installations running under heavy 
> > load that
> > have not experienced this problem. As such, this sounds like a cache
> > configuration problem on your end. Have you read the FAQ?
> > http://www.openldap.org/faq/data/cache/893.html
> 
> >  -- Howard Chu
> >  Chief Architect, Symas Corp.       Director, Highland Sun
> >  http://www.symas.com               http://highlandsun.com/hyc
> >  Symas: Premier OpenSource Development and Support
> 
> > > -----Original Message-----
> > > From: owner-openldap-bugs@OpenLDAP.org
> > > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of ldap@uic.edu
> 
> > > Full_Name: Andrew J. Herbert
> > > Version: 2.1.21
> > > OS: Linux
> > > URL: ftp://ftp.openldap.org/incoming/
> > > Submission from: (NULL) (128.248.172.135)
> > >
> > >
> > > System master and slave pair running openldap v2.1.21 and
> > > Berkeley DB 4.1.25 on
> > > Linux 2.4.18 systems (RH7.3 with updates) filesystems are ext3.
> > >
> > > We have an issue using the PADL software pam_ldap module on a
> > > Solaris V880 with
> > > approx 40,000 users against OpenLDAP. pam_ldap is not
> > > configured with the root
> > > DN and the ACL are setup to allow no modification by anyone
> > > bar the root DN. As
> > > such the LDAP database can be considered to be read-only.
> > >
> > > After running for a few hours, the server starts taking an
> > > inordinately long (>1
> > > min) to do a simple lookup. If we stop the server and compare
> > > the database files
> > > with a 'known good' one, we find that the files have changed.
> > > Performing a
> > > slapcat on the database takes in excess of 30 mins to run,
> > > but produces a
> > > correct LDIF which can then be reloaded (around an hour for
> > > this) and the server
> > > then continues to run normally for another few hours.
> > >
> > > We can reproduce this, we have tried the following
> > >
> > > Originally this system came online running 2.1.17 on a pair
> > > of IDE based
> > > servers. We moved it to newer faster SCSI based servers (Sun
> > > LX50's) and still
> > > had the same problems. We upgraded the system to 2.1.21 and
> > > the problem was
> > > still present. If we leave the master and slave running long
> > > enough, eventually
> > > they both enter this slow mode of operation.
> 
> -- 
> Christoph Neerfeld
> 
> FH Bonn-Rhein-Sieg       | e-mail: Christoph.Neerfeld@FH-BRS.DE
> FB Angewandte Informatik |
> Grantham Allee 20        | phone : +49 2241/865-241
> 53757 Sankt Augustin     |
> Germany - Deutschland    | fax   : +49 2241/865-8241
> 
> 
> 
>