[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: slapd eating up resource on 2.3.14
- To: <openldap-software@OpenLDAP.org>
- Subject: RE: slapd eating up resource on 2.3.14
- From: "Spicer, Kevin" <KevinS@bmrb.co.uk>
- Date: Thu, 5 Jan 2006 22:32:03 -0000
- Content-class: urn:content-classes:message
- Thread-index: AcYSHbvuKsH/9ZHxSYuoLoE29zaQagABkOAgAAQ6ASAABLAgsA==
- Thread-topic: slapd eating up resource on 2.3.14
I've now installed 2.3.15 on my test system and also see the problem
there so have submitted an ITS #4308
-----Original Message-----
From: Spicer, Kevin (MBLEA it)
Sent: 05 January 2006 20:33
To: Spicer, Kevin (MBLEA it); Quanah Gibson-Mount;
openldap-software@OpenLDAP.org
Subject: RE: slapd eating up resource on 2.3.14
Okay, I've done some testing with both 2.3.14 and 2.3.13 (without
patches), it seems that 2.3.14 is substantially slower.
To test I kicked off the following command 15 times (concurrently)
ldapsearch >/dev/null &
This returns the 4400 odd entries in my directory that can be viewed
with an anonymous bind and no ssl.
Admittedly this is a crude test, and there are other apps on the system
that will be making ldap queries - but nothing like this order of
magnitude. I was running my regular slapd.conf except with logging 0.
I repeated the tests using various values for threads in slapd.conf (the
problems on my production systems seem to have lessened since I raised
the threads parameter to an insane value!).
In all cases the 'user' time was around 6.5 - 7s and the 'sys' time was
around 1.2 - 1.5s however the 'real' time varied greatly - see below...
Threads
2 4 8 16 32
2.3.13 10.7s 9.1s 8.3s 8.4s 8.1s
2.3.14 171.9s 47s 31s 64.7s 30.6s
Following some of Matthews advice I took a look at the output of prstat
-L, it seems that one thread is using lots of CPU (2.3.14 16 threads)
prstat -L -p `cat /var/run/slapd/slapd.pid`
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
11383 ldap 245M 28M cpu0 0 0 0:00:17 28% slapd/2
11383 ldap 245M 28M sleep 59 0 0:00:00 1.0% slapd/17
11383 ldap 245M 28M sleep 59 0 0:00:00 0.7% slapd/15
11383 ldap 245M 28M sleep 59 0 0:00:00 0.6% slapd/16
11383 ldap 245M 28M sleep 59 0 0:00:00 0.6% slapd/10
11383 ldap 245M 28M sleep 59 0 0:00:00 0.6% slapd/14
11383 ldap 245M 28M sleep 59 0 0:00:00 0.6% slapd/13
11383 ldap 245M 28M sleep 59 0 0:00:00 0.6% slapd/4
11383 ldap 245M 28M sleep 59 0 0:00:00 0.6% slapd/7
11383 ldap 245M 28M sleep 59 0 0:00:00 0.6% slapd/11
11383 ldap 245M 28M sleep 59 0 0:00:00 0.5% slapd/3
11383 ldap 245M 28M sleep 59 0 0:00:00 0.5% slapd/5
11383 ldap 245M 28M sleep 59 0 0:00:00 0.5% slapd/6
11383 ldap 245M 28M sleep 59 0 0:00:00 0.4% slapd/9
11383 ldap 245M 28M sleep 59 0 0:00:00 0.4% slapd/8
11383 ldap 245M 28M sleep 59 0 0:00:00 0.4% slapd/12
11383 ldap 245M 28M sleep 59 0 0:00:00 0.1% slapd/1
11383 ldap 245M 28M sleep 59 0 0:00:00 0.0% slapd/18
After the test completes that one thread continues to eat cpu for up to
several minutes.
I feel an ITS coming on...
=================================================================
BMRB wins two BMRA awards - http://www.bmrb.co.uk
_________________________________________________________________
This message (and any attachment) is intended only for the
recipient and may contain confidential and/or privileged
material. If you have received this in error, please contact the
sender and delete this message immediately. Disclosure, copying
or other action taken in respect of this email or in
reliance on it is prohibited. BMRB Limited accepts no liability
in relation to any personal emails, or content of any email which
does not directly relate to our business.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++