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

Re: ITS#3950

Quanah Gibson-Mount wrote:


--On Friday, January 13, 2006 11:28 PM -0800 Quanah Gibson-Mount <quanah@symas.com> wrote:

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 loads
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
back up.

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. 

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 higher otherwise)

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.)

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/