Hello,
this message exchange is really funny, since someone who calls himself an senior unix administrator is not able to answer simple questions about his own systems and wants uberfast results from an application point of view he doesn't pay any support for.
Dear Devender, please review your questions and the answers you gave on this mailinglist and how you wrote and may think of the impression other people get from you.
Thank for reading. bye. :)
On Fri, Aug 20, 2010 at 12:18, Singh, Devender (GE Capital, consultant) Devender.Singh2@ge.com wrote:
Hi Dieter,
Please find the below details:
- hardware related
- type of storage - Simply SATA had disk attached.
- raid level, if any- No RAID
- file system of disk(s)- ext3 on LVm
- type of network, 100MB, 1G, 10G
- is this host running on a virtual machine or on bare metal.
- if virtual machine, -Yes, OS installed on VM
-- what type ---Don’t know
Thanks & Regards,
Devender Singh
Senior Unix Administrator,
(SOA Support Team)
-----Original Message-----
From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Kluenter Sent: Thursday, August 19, 2010 11:40 PM To: openldap-technical@openldap.org Subject: Re: Openldap2.4.16 performance issue
"Singh, Devender (GE Capital, consultant)" Devender.Singh2@ge.com writes:
I agree with you. Please suggest me what to do for resolution of this issue.
Frankly, this is simple unix system administration.
A few questions:
- hardware related
- type of storage
- raid level, if any
- file system of disk(s)
- type of network, 100MB, 1G, 10G
- is this host running on a virtual machine or on bare metal.
- if virtual machine,
-- what type
-Dieter
"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