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

Re: slapd hangs up and uses 100% CPU (v2.1.12 release)

Does this solve only the problems originating from group.c, so pb with groups I suppose ? or is it a general correction to all slapd 100% CPU usage pb ?


Igor Brezac wrote: 
For those of you interested, this issue is fixed in CVS.  Check out
http://www.OpenLDAP.org/its/index.cgi?findid=2195

Thanks to Jonghyuk Choi!

-Igor

On Wed, 5 Feb 2003, Igor Brezac wrote:


On Wed, 5 Feb 2003, Kirill Ponazdyr wrote:


Greetings,

When i truss (Solaris?s strace) the hanging process I see a loop made of:

/4:     yield()                                         = 0

lines.

I have tried to recompile bdb in its newest version, compile with -O
instead -O3 as I usually do, no change at all.

I also tried to change file descriptor soft limit to 1024, systemwide. No
change again.

Now I gaved up and went to ldbm on the base of gdbm, it works flawlessly.
It really seems to be a "exclusive" bdb backend problem.


I can reproduce this on Solaris 9.
Check out http://www.OpenLDAP.org/its/index.cgi?findid=2195

Do you use 'group' in your acls?

-Igor


Regards

Kirill


I have the same pb, but cannot reproduct it as I want ...
However I noticed that when I stoped playing with bdb tunning it worked
better ... By playing with bdb, i mean using the cachesize and
checkpoint directives in slapd.conf, if you put silly values, as I might
have done, this will maybe trash slapd ... ? Since I put reseaonable
values, now it seems to work fine .

my slapd.conf

#cachesize      6000
checkpoint      100000 360
#dbnosync

and DB_Config file for my database

$ cat /var/lib/ldap/int/DB_CONFIG
#set the logfile size to 100MB.
#set_lg_max 104857600
#set the in-memory log buffer size
set_lg_bsize 204800
#temporary while we're slapadding the database
set_flags DB_TXN_NOSYNC
#set the (per db?) cachesize to 0GB + X bytes, split into N pieces of
memory set_cachesize 0 5120000 2


Although I still don't know which ones are used, slapd.conf directives
or DB_CONFIG ones ??

when slapd takes 100% , could you make a strace -p pid  (pid=pid of
slapd at 100%) to check what is is actually doing. For me it was looping
on something, can't remember what, but it's somewhere in the list .

Let us know if you find an explanation.

Thanks.

Kirill Ponazdyr wrote:

Greetings,

We have a problem with slapd hanging up and using 100% CPU time on our
machine when we try to do operations on a tree, it happens in random
places but we could find one where it happens every time, when we try
to delete a certain object in the tree. We can repro the problem as
many times as we wish. Unfortunately the slapd has to be killed by
kill -9 and this corrupts our databases, so we have to reload a
directory (PITA).

Thus two questions: Why is this stuff happening ? and is there a way
to run a consistency check on BDB databases, thus not requiering the
full reload ?

Here are release infos, configs and debug output:

Releases:
-----------------------------------------
Openldap v2.1.12 release
Bdb libraries 4.1.24
Solaris 9 Sparc with latest patch cluster

HW:
-----------------------------------------
Sun Netra T1125 with 1 Gig RAM.


DB_CONFIG
-------------------------------
set_lg_bsize 2097152
set_cachesize 0 209715200 2


slapd.conf:
--------------------------------------------------------------
include                 /etc/openldap/schema/core.schema
include                 /etc/openldap/schema/cosine.schema
include                 /etc/openldap/schema/nis.schema
include                 /etc/openldap/schema/qmail.schema
include                 /etc/openldap/schema/inetorgperson.schema
include                 /etc/openldap/schema/qmailControl.schema
pidfile                 /var/run/slapd.pid
argsfile                /var/run/slapd.args
disallow                bind_anon
allow                   bind_v2

database                bdb
suffix                  "o=Codeangels, c=CH"
directory               /export/ldap-databases/codeangels
rootdn                  ** censored **
rootpw                  ** censored **
index                   cn,sn,uid pres,eq,approx,sub
index                   objectClass eq
... snip ....

Debug:
---------------- snip -------------------
=> access_allowed: write access granted by write(=wrscx)
====> bdb_unlocked_cache_return_entry_r( 526 ): returned (0)
bdb_dn2entry_rw("cn=managers,ou=codeangels.com,ou=mail,ou=itaccounts,o=codeangels,c=ch")
=> bdb_dn2id_matched(
"cn=managers,ou=codeangels.com,ou=mail,ou=itaccounts,o=codeangels,c=ch"
) ====>
bdb_cache_find_entry_dn2id("cn=managers,ou=codeangels.com,ou=mail,ou=itaccounts,o=codeangels,c=ch"):
542 (1 tries)
bdb_cache_entry_db_lock: entry
cn=managers,ou=codeangels.com,ou=mail,ou=itaccounts,o=codeangels,c=ch,
rw 1, rc -30995 ====> bdb_cache_find_entry_id( 542 ): 542 (busy) 2
locker = -2147483031
bdb_cache_entry_db_lock: entry
cn=managers,ou=codeangels.com,ou=mail,ou=itaccounts,o=codeangels,c=ch,
rw 1, rc -30995 ====> bdb_cache_find_entry_id( 542 ): 542 (busy) 2
locker = -2147483031
bdb_cache_entry_db_lock: entry
cn=managers,ou=codeangels.com,ou=mail,ou=itaccounts,o=codeangels,c=ch,
rw 1, rc -30995 ====> bdb_cache_find_entry_id( 542 ): 542 (busy) 2
locker = -2147483031
.... repeat above 2 lines until killed ....
---------------- snip -------------------

---
Kirill Ponazdyr
Technical Director
Codeangels Solutions
Tel: +41 (0)43 844 90 10
Fax: +41 (0)43 844 90 12











--
Jehan Procaccia 			| Ingenieur Systemes & Reseaux
Institut National des Telecommunications| Tel : +33 (0) 160764436
MCI, Moyens Communs Informatiques  | Mail: Jehan.Procaccia@int-evry.fr
9 rue Charles Fourier 91011 Evry France | Fax : +33 (0) 160764321