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

RE: Openldap2.4.16 performance issue



I agree with you. Please suggest me what to do for resolution of this issue.

Thanks & Regards,
Devender Singh
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.

-----Original Message-----
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
To: openldap-technical@openldap.org
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
-- 
Dieter Klünter | Systemberatung 
sip: 7770535@sipgate.de 
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6