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:
> >
> >
> >
> > 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
> >
> >
> >
> > --
> >
> > 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
>
>

--
- Russell Knighton -

Motion Picture Solutions Ltd
Richmond Cottage, 7b North End Road, London, W14 8ST
Mob: +44 (0) 7758 210 744, Tel: +44 (0) 207 371 2396

http://www.motionpicturesolutions.com

Company No. 5388229    VAT No. 858 22 0127