[Date Prev][Date Next]
Quanah Gibson-Mount wrote:
--On Friday, January 13, 2006 11:28 PM -0800 Quanah Gibson-Mount
I started benchmarking on OpenLDAP 2.3.17 tonight. I found that on
Solaris, there was no change in performance over previous OpenLDAP
releases. However, I found that on linux, performance on just the prime
job (which doesn't measure the full performance of the server, just
the cache) had dropped from approximately 1500 searches/second to 100
searches/second (15X reduction in speed).
Changing portable.h to #undef REPLACE_BROKEN_YIELD brought performance
I then tested
# define REPLACE_BROKEN_YIELD 1
# undef HAVE_NANOSLEEP
This also brought performance back up.
So some part of this change likely needs to be reverted, and is also
likely the cause of the performance issue reports seen on -software.
Here is a further update.
First, I note that the above tests, and the following, were all done
on a Linux 2.4 kernel. I believe the REPLACE_BROKEN_YIELD bit *must*
be disabled for 2.4 kernels.
Agreed; I would have only enabled it for 2.6 really.
I did some more timing of test008 with and without a background CPU
burning job. (just a for loop, so it had minimal impact on CPU cache.)
The results from a full throttle test of 2.3.17 on the linux 2.4 kernel:
REPLACE_BROKEN_YIELD, NANOSLEEP = 535 searches/second average
REPLACE_BROKEN_YIELD, SELECT = 4706 searches/second average
UNDEF REPLACE_BROKEN_YIELD = 8138 searches/second average (and I
believe I maxed out my 100MB/s ethernet here, possible it could be
On a 2GHz Pentium-M laptop with Linux 2.6.5:
test008 test008+CPU job
original 0:27 1:10
BROKEN/select 0:24 0:24
BROKEN/nano 0:33 0:33
On 2GHz AMD64 X2 with Linux 2.6.14 (SMP):
original 0:31 0:43
BROKEN/select 17:09 17:47
BROKEN/nano 1:28 1:29
I have a feeling we're going to be seeing pretty varied results across a
range of configurations. My feeling is we're best off using
sched_yield(), and possibly using the SCHED_FIFO scheduler to get
deterministic performance on 2.6 kernels. I'm also inclined to just back
out all of this stuff and completely ignore the issue, as I did before.
There's no good reason to have other jobs soaking up the CPU on the same
machine as your infrastructure services.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/