Modifying entries takes ages, slurpd consumes much cpu time, replication way behind (2nd try)

[Andreas Rother <rother-ml@gmx.de>]

I have three OpenLDAP servers (all 2.1.29 with db-4.2.52.2) in my 
environment. The master server (SLES8) feeds the two slaves (Redhat 
ES3). I had replication problems with previous versions of OpenLDAP, so 
I upgrade to 2.1.29 and start a shell script that adds one hundred 
attributes to a specific user using ldapmodify. All ldap servers run 
with debuglevel 65535.

That script runs over 30 minutes and terminates with the error message:
---
modifying entry "uid=arother,ou=people,ou=preprod,o=company,c=de"
ldapmodify: update failed: uid=arother,ou=people,ou=preprod,o=company,c=de
ldap_modify: Internal (implementation specific) error (80)
      additional info: commit failed

(repeating several times)
---
But all 100 attributes are in the database.

The slurpd consumes up to 99% cpu time. When the shellscript fails, the 
slurpd process writes the messages:
---
ldap_msgfree
Error: copy_replog: Error closing 
"/app/openldap/var/openldap-slurp/replica/slur
pd.replog"
new work in /app/openldap/var/openldap-slurp/replica/slurpd.replog
copy replog "/app/openldap/var/openldap-slurp/replica/slurpd.replog" to 
"/app/op
enldap/var/openldap-slurp/replica/slurpd.replog"
Error: Re_parse: bad type <imestamp>
Warning: freeing re (dn: (null)) with nonzero refcnt
error: malformed replog entry (begins with "imestamp: 20040329141337Z")
ldif_parse_line: missing ':' after replace
Error: malformed replog line "replace"
Warning: freeing re (dn: 
uid=arother,ou=people,ou=preprod,o=company,c=de) with n
onzero refcnt
error: malformed replog entry (begins with "replica: skuld.company.de")
new work in /app/openldap/var/openldap-slurp/replica/slurpd.replog
copy replog "/app/openldap/var/openldap-slurp/replica/slurpd.replog" to 
"/app/op
enldap/var/openldap-slurp/replica/slurpd.replog"
new work in /app/openldap/var/openldap-slurp/replica/slurpd.replog
copy replog "/app/openldap/var/openldap-slurp/replica/slurpd.replog" to 
"/app/op
enldap/var/openldap-slurp/replica/slurpd.replog"
(repeating several times)
---

The slaves recieve only 14 of 100 modifications. There are no remarkable 
error messages about failed updates in their logs.

Maybe there is sth. buggy with the config? Here is the slapd.conf:
---
pidfile         /app/openldap/var/run/slapd.pid
argsfile        /app/openldap/var/run/slapd.args
loglevel        1
access to attr=userPassword
      by dn="cn=root,ou=preprod,o=company,c=de" write
      by 
group/groupofuniquenames/uniquemember="cn=AdminUsers,ou=People,ou=preprod,o=company,c=de" 
write
      by dnattr=owner write
      by self write
      by * auth
access to *
      by dn="cn=root,ou=preprod,o=company,c=de" write
      by 
group/groupofuniquenames/uniquemember="cn=AdminUsers,ou=People,ou=preprod,o=company,c=de" 
write
      by dnattr=owner write
      by self write
      by * read
allow bind_v2 bind_anon_dn
database        bdb
suffix          "ou=preprod,o=company,c=de"
rootdn          "cn=root,ou=preprod,o=company,c=de"
rootpw          secret
directory       /app/openldap/var/openldap-data
index   objectClass,uid eq
replogfile /app/openldap/var/openldap-slurp/replica/slurpd.replog
replica host=skuld.company.de
  bindmethod=simple
  binddn="cn=root,ou=preprod,o=company,c=de"
  credentials=secret
replica host=urd.company.de
  bindmethod=simple
  binddn="cn=root,ou=preprod,o=company,c=de"
  credentials=secret
---

I don't know whether that helps but I preserved all debug files on disk, 
if you need further information.

I think it's quite strange that a update of 100 attributes causes so 
much trouble to the ldap server. Where is my mis-configuration?