Hi Dieter,
Please find the below details:
1. 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
2. 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:
1. hardware related
- type of storage
- raid level, if any
- file system of disk(s)
- type of network, 100MB, 1G, 10G
2. 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