I think I see the problem here: echo "$sender" | grep -i consultant; echo $?
Seriously though, I agree with you Benjamin.
Devender: Please read ALL emails sent to you much more carefully as you have missed/ignored several of the "free" attempts to help you. If you want "free" help from a voluntary community, treat them with more respect, acknowledge all advice given (definitely do not ignore it), and try to help everyone by simply responding with extra information as and when it is asked of you!
Just out of interest, what kind of "Senior Unix Administrator" are you if you can not see a problem with this:
--snip-- - type of storage - Simply SATA had disk attached.
- raid level, if any- No RAID --snip-- if virtual machine, -Yes --snip--
and finally:
--snip-- Databse1:
Number of users : 830000 Number of dns: 830000
Database2:
Number of users: 2000 Number of dns: 800000 --snip-- In Application2(90% dependent on openldap) every user have 1000+ sub leafs entries --snip--
!!!!!!!!!!
To top it off, you're running a potentially very active LDAP database in a VM!! How would you ever expect that level of <quotation_fingers>hardware</quotation_fingers> to cope with such potential volumes of network traffic anyway??
My advice before you post back: 1. Go back through the email trail and read ALL advice and act on it appropriately.
2. Upgrade OpenLDAP to a more (if not the most) recent version.
3. Get it on bare metal (preferably something with higher spec for improved IO (and maybe an off-loaded network card).
My 2pence....
Russell Knighton
On Fri, 2010-08-20 at 13:15 +0100, Benjamin Griese wrote:
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
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra