Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234801 - openldap got poor performance with RHEL5 on HP DL380 G4 and G5
Summary: openldap got poor performance with RHEL5 on HP DL380 G4 and G5
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap
Version: 5.0
Hardware: i686
OS: Linux
Target Milestone: ---
: ---
Assignee: Jan Zeleny
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-02 07:09 UTC by Ching-Che Yen
Modified: 2009-10-19 14:24 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-10-19 14:24:05 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Ching-Che Yen 2007-04-02 07:09:03 UTC
Description of problem:

I created a ldap server(openldap-2.3.27-5) with RHEL5,I found the performance is
very bad on a very powerful machine(HP DL380 G5,2 way 3.2GHZ cpu,4GB Memory,SAS
disks),even I had tuned the slapd.conf and DB_CONFIG.I test it with my own
script , I found the ldap server could just handle 4 authentication queries per
second !!!

Then I tried to create ldap server  with RHEL5 on my Desktop computer(AMD
1.7Gz,2GB Memory,IDE disk),and I get greater ldap query performance on it (about
160 authentication queries per second !!!)

In order to test it further,I install RHEL4(openldap-2.2.13-6.4) and
RHEL3(openldap-2.0.27-22) on the HP DL380.All performance is very bad (about 4
to 12 authenticaion queries per second).

Then I guess that maybe it's the SMP or Hyper-threading to influence the
So I tried to unplug one cpu to reduce the number of cpu from 2 ways to 1
way,and disable Hyper-threading in the BIOS.
The result is.....still very bad.....

btw,I install the RHEL5 on another pc(p4 2.8Ghz 1GB ram),It works
smoothly.(about 140 authentication queries per second).

No I really don't know how to test it further....@_@
Could any one give me a suggesstion?

Thank you very much,and sorry for my poor english.

Comment 1 Jan Zeleny 2009-09-01 13:30:47 UTC
It has been over two years since this bugzilla was created. Is this issue still present or was there any progress?

Comment 2 Timm Stamer 2009-09-01 13:33:31 UTC
I've got a similar problem on a brand-new FSC RX200 S5 (Intel Nehalem, 12G RAM) running RHEL 5.3 x86_64.

In the first minute after enabling this host on the upstream loadbalancer (Foundry ServerIron GT E2) everything working fine. LDAP answers takes ~0.1 seconds. After some time connections get stucked and answers take up to 5 seconds or got timed out.

Other servers in the cluster are much older xeon processors w 2gb of RAM running RHEL AS4 (i386). One of these is ldap master, the new one is a replica.


Comment 3 Timm Stamer 2009-09-01 13:35:14 UTC
sorry jan, several "human interrupts" delayed my post ;)

Comment 4 Jan Zeleny 2009-09-01 15:23:45 UTC
Thank you for the info. I suggest consulting these issues with customer support, those guys might have some tips about it and there might even be no need for any patch.

Comment 5 Ching-Che Yen 2009-09-03 06:35:54 UTC
This problem was solved after about 2 months.

I think that the yum update some rpm packages to fix it.

Then I checked the yum.log file,but there are no openldap or some similar updates.

I had tried to update the rpm packages in the yum.log one bye one manually to try to repeat the problem,but I just can't repeat it anymore.(to many packages and dependence problems)

Now I just know that if I install the newest RHEL,the openldap server is ok now.

Comment 6 Jan Zeleny 2009-10-19 14:24:05 UTC
Original reporter of this bug solved the issue and I have no information to consider this to be a bug, so I'm closing it. If anyone else has similar troubles, please contact our customer support, they might help you with debugging before it gets to me as a new bug.

Note You need to log in before you can comment on or make changes to this bug.