[Date Prev][Date Next]
RE: Openldap2.4.16 performance issue
I agree with you. Please suggest me what to do for resolution of this issue.
Thanks & Regards,
Senior Unix Administrator,
(SOA Support Team)
SDG Software India Pvt. Ltd
A-10, Sector 2, Noida 201301, U.P, India
M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020
website : www.sdgc.com
Please Note: The e-mail content is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you have erroneously received this message, please delete it immediately and notify the sender. Before opening any attachments please check them for viruses and defects.
From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Kluenter
Sent: Thursday, August 19, 2010 2:06 PM
Subject: Re: Openldap2.4.16 performance issue
"Singh, Devender (GE Capital, consultant)" <Devender.Singh2@ge.com> writes:
> Please find the below answers:
> [root@abc openldap-data-ge_cw]# du -sh *.bdb
> 3.6M br.bdb
> 72K cn.bdb
> 32K displayName.bdb
> 234M dn2id.bdb
> 104K gr.bdb
> 419M id2entry.bdb
> 56K mail.bdb
> 1.4M objectClass.bdb
> 2.9M pf.bdb
> 212K pr.bdb
> 72K sn.bdb
> 72K uid.bdb
I have seen the problems you describe before. Although a configured
cache size of 250M and a database size of some 660M is not sufficient,
it still is not such a bottleneck. To my experience a heavy cpu load
is most likely based on heavy disk operations.
If moving the transaction logs onto a separate disk didn't solve it,
look for other concurrent read/write operations. Check whether the
logs report constantly deadlocks.
In some cases a journaling file system reduced performance. I
experienced rather bad results with xfs.
Dieter Klünter | Systemberatung
GPG Key ID:8EF7B6C6