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

Re: Openldap2.4.16 performance issue



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