Bill MacAllister wrote:
Attached is the output of db4.2_stat -CA of the database.
Thanks for looking at this.
So far it just looks like a very busy server. Can you turn off the network
access to it and see if it settles down when the query traffic stops?
It's a bit odd that a single transaction has so many pages of the
suPrivilegeGroup index locked.
The backtrace is somewhat suspicious, there are several <value optimized out>
items in the trace. In thread 8, frames 5 and 6 the locker value is odd;
usually in BDB the locker ID associated with a transaction has bit 31 set,
yielding a very large 32 bit number. Also there is no locker with that ID in
the db_stat output you provided.
It looks like you'll have to try this again with a non-optimized binary to get
a reliable backtrace.
Bill
--On Tuesday, May 13, 2008 01:20:49 AM -0700 Howard Chu<hyc(a)symas.com>
wrote:
> whm(a)stanford.edu wrote:
>> Full_Name: Bill MacAllister
>> Version: 2.3.41-1su2
>> OS: debian etch kernel 2.6.18-4-amd64
>> URL:
http://www.stanford.edu/~whm/ldap-test1-bt.txt
>> Submission from: (NULL) (171.64.19.165)
>>
>>
>> The slapd process will sometimes consume all of available CPU. We
>> observed this when we upgraded our production servers from 2.3.35-2su2
>> to 2.3.41-1su2. The problem was bad enough that we downgraded the
>> production servers to 2.3.35-2su2. We have been trying to provoke the
>> problem in our test environment and have not been successful in making
>> it happen on demand. Today, we noticed that one of our test servers
>> went completely CPU bound. I took a backtrace. It is available at the
>> URL below. The interesting thing about the problem is that although top
>> shows a pinned CPU and a high load the server is still responsive and
>> continues to answer LDAP searches. The test server that exhibits the
>> problem is still CPU bound and has been for 2-3 hours now. We will
>> leave this server in this state in case there is other information that
>> we should harvest in resolving the problem.
> Please also provide the output from db_stat -CA on the database in
> question, thanks.
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/