[Date Prev][Date Next]
Re: (ITS#5508) slapd process consumes all of CPU
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.
> --On Tuesday, May 13, 2008 01:20:49 AM -0700 Howard Chu<email@example.com>
>> firstname.lastname@example.org 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) (188.8.131.52)
>>> 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/