[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SLOW Performance: OpenLDAP on Linux and IBM Dual Xeon?
On Wed, 14 Apr 2004, Carl Wilhelm Soderstrom wrote:
> On 04/14 05:58 , Digant Kasundra wrote:
> > Yes, my wa column of vmstat is up around 100 on my slow Xeon and only 9 or
> > 10 on my kick ass Pentium 3. :)
> >
> > Surprisingly, when I ran under single processor kernel, openldap seemed to
> > perform better, but I don't have the metrics saved to conclude that. But I
> > can definitely say performance is abismal on my super fast machines and
> > superb on my jallopy.
>
> have you tried turning off hyperthreading? Could be that processes are
> trying to contend for processors which aren't really there, and which
> wouldn't benefit them anyway (since the problem may be I/O bound rather than
> CPU bound).
>
I am wondering if this may be an NPTL issue. I have been running a lot of
tests on Dell 1650s (P3-1266's, some single, some dual proc boxes), and
RHEL3 performs much worse than RHEL2.1(in some cases up to 10 times worse)
on the same machine with the same database files, with binaries built
from the same SRPM, even when running the RHEL2.1 openldap packages on
RHEL3.
In fact, RHEL3 has yet to meet our performance targets (whereas RHEL2.1
with almost any openldap version on any database backend does).
For instance:
RHEL2.1 with current update packages of openldap:
1000 searches:
Wed Mar 17 14:40:39 SAST 2004
Wed Mar 17 14:40:53 SAST 2004
(14s for 1000 searches)
RHEL3 with original openldap packages:
1000 searches:
Wed Mar 17 14:59:51 SAST 2004
Wed Mar 17 15:01:58 SAST 2004
(127s for 1000 searches)
(these tests were done quite carefully, basically everything is identical
except for the OS and in some cases the openldap version/backend, and
every single test has shown exactly the same tendency).
Someone mentioned that on "linux", performance when compiled with
threading was worse. I wonder if that "linux" was with NPTL ...
(/me building on RHEL3 without threading ...)
(Ahh, yes, this is one case where benchmarks are both valid and important,
we have a wholelot of mail that will be delayed if we don't get sufficient
performance ... and the benchmarks did expose a problem ...).
Regards,
Buchan