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

cpu stall on concurrent accessess (ITS#1138)



Full_Name: Paolo Pennisi
Version: 2.0.7
OS: rh7.0 (fully patched) kernel 2.4.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.121.64.2)


We are experiencing frequent slapd thread cpu stalling and subsequent server
malfunction with an in-house mail delivery agent which uses the LDAP directory
to hold user/mailbox information. the deliver/pop/imap system uses lock
attributes
on mailboxes to enforce coherent access. Frequently on creation or removal of
the lock attribute the slapd thread stalls and starts eating up all the
available cpu.
All subsequent accesses to the same dn/attribute stall. We are thus forced to
shut
down the slapd server, but sometimes after a gracefull shutdown and restart the
server
stalls or dumps at the first write (we are compelled to export the tree into
ldif format
and reload from scratch)
we're using berkeley db 3.2.9, redhat 7.0 updated with all the latest fixes,
glibc-2.2.2
env CPPFLAGS="-I/usr/local/include" \
LDFLAGS="-L/usr/local/lib" \
./configure  --enable-ldbm --enable-ldbm-api=berkeley --disable-rlookups

our software, written in python 2.0, uses python-ldap-1.10alpha3 to connect to
the slapd
server.

We have around 20 people checking their mailboxes every minute with pop-3.

When we add to the current tree ( ~1000 entries big ), a new domain with around
1500
mailboxes and 3/4000 total entries, even if this new domain is not accessed at
all,
the pop processes (working on first domain)eventually get stuck when locking or
releasing the Inbox lock.

The lock is set simply adding to the Inbox the attribute (lock=1), which
normally
fails if somebody else has already written the attribute.
Here is the line of code which performs the locking:
self.LDS.modify_s ( self.inboxDN, [ ( ldap.MOD_ADD, "lock", "1" ) ] )

and the following releases the lock:
self.LDS.modify_s ( self.inboxDN, [ ( ldap.MOD_DELETE, "lock", "1" ) ] )