Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 craig@mfoundry.com does not designate 74.125.149.199 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E961A00.9000201@gmail.com>
References: 
 <CACFiKfocTJC10LugxRZ4BYLAt7DOspXcN=Qmk8BNOsE3A83ULg@mail.gmail.com>
	<4E961A00.9000201@gmail.com>
Date: Thu, 13 Oct 2011 10:31:28 -0500
Message-ID: 
 <CACFiKfqmJvWrKSx3kSpS44p-zrpU5ye_hP7vM9mD3JDEWXZR9g@mail.gmail.com>
Subject: Re: Performance issues and strange logs
From: Craig Setera <craig@mfoundry.com>
To: "users@directory.apache.org" <users@directory.apache.org>
Content-Type: multipart/alternative; boundary=0016e6db66ff9c0c8204af2fd5a7

--0016e6db66ff9c0c8204af2fd5a7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Assuming that the errors and warnings are not a big deal, can you suggest
any reasons that we would have connections stacking up and timing out?  The
use case is likely heavier on write than would be standard for LDAP, but it
seems the failure threshold (number of connections) is very low.  This is
hosted on a multi-core machine (virtual machine) and when it gets bad, our
operations people say that a single core of the machine is pegged at 100%
CPU while others are essentially idle.  Are there parts of Apache DS that
have thread affinity and would be "stuck" to a single processor?

Any thoughts would be appreciated,
Craig

On Wednesday, October 12, 2011, Emmanuel Lecharny wrote:

> On 10/12/11 10:24 PM, Craig Setera wrote:
>
>> Hello,
>>
>
> Hi,
>
> which ADS version are you using ? Is it still 1.5.5 ?
>
>
>> Last week I was asking about indexing and performance gains from those
>> indexes.  The question stemmed from some performance problems that we ar=
e
>> currently having in our environment.  In that environment, we are seeing
>> extremely poor performance and Apache DS getting bogged down after a
>> relatively small number of connections (under 100).  When that happens,
>> the
>> connections start to "stack up" and eventually time out.  I was surprise=
d
>> by
>> the performance, but was looking at things like indexing and disabling
>> sync
>> on write as ways to improve the situation.
>>
>> Now, I've received some logs from testing and I'm beginning to wonder if
>> there is something else going on.  I'm seeing many entries in the logs
>> that
>> look like:
>>
>> [18:27:52] WARN [org.apache.directory.server.**ldap.LdapSession] -
>> AbandonableRequest with messageId 2 not found in outstandingRequests.
>> [18:27:53] WARN [org.apache.directory.shared.**asn1.ber.Asn1Decoder] -
>> The PDU
>> has been fully decoded but there are still bytes in the buffer.
>> [18:27:53] WARN [org.apache.directory.shared.**asn1.ber.Asn1Decoder] -
>> The PDU
>> has been fully decoded but there are still bytes in the buffer.
>> [18:27:53] WARN [org.apache.directory.server.**ldap.LdapSession] -
>> AbandonableRequest with messageId 2 not found in outstandingRequests.
>> [18:27:53] WARN [org.apache.directory.shared.**asn1.ber.Asn1Decoder] -
>> The PDU
>> has been fully decoded but there are still bytes in the buffer.
>> [18:27:53] WARN [org.apache.directory.shared.**asn1.ber.Asn1Decoder] -
>> The PDU
>> has been fully decoded but there are still bytes in the buffer.
>>
> This message just means that some data has been received, decoded
> correctly, but we have still some remaining bytes in the buffer. It's a
> warning, not an error. The remaining bytes will be decoded later. Nothing=
 to
> be scared about.
>
>>
>>
> --
> Regards,
> Cordialement,
> Emmanuel L=E9charny
> www.iktek.com
>
>

--=20
Craig Setera
Director, Product Engineering
mFoundry
p 415.324.5801
craig@mfoundry.com

--0016e6db66ff9c0c8204af2fd5a7--