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

[hyc@highlandsun.com]

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.
>