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

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

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


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) (
> >
> >
> > 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