[Date Prev][Date Next]
Re: (ITS#6383) Very Slow Query Response
--On Tuesday, November 17, 2009 09:11:23 PM -0800 Quanah Gibson-Mount <firstname.lastname@example.org> wrote:
> On Nov 16, 2009, at 9:03 PM, Bill MacAllister <email@example.com> wrote:
>> --On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount
>> <firstname.lastname@example.org> wrote:
>>> --On November 16, 2009 8:27:21 PM +0000 email@example.com wrote:
>>>> Full_Name: Bill MacAllister
>>>> Version: 2.4.19+
>>>> OS: Debian 5
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (220.127.116.11)
>>>> On a system where slapd is the top CPU process and is consuming 4%
>>>> of the
>>>> CPU simple queries are taking ten of seconds to complete. Here is
>>>> example query:
>>> Last time we saw this it appeared that it might be related to DNS.
>>> How long does a netstat -a take on the affected systems when the
>>> LDAP queries are slow?
>> I don't have that number. I have only see it once in the test
>> environment I am not sure how long it will take me to get it. Since
>> this plastered the production service today, I will have to reproduce
>> it though before we attempt another production upgrade.
>> Not clear to me why a DNS issue would appear only under load and not
>> at other times. And it seems strange that it appears in
>> lenny/openldap-2.4 and not in etch/openldap-2.3.
>> Bill MacAllister, System Software Programmer
>> Unix Systems Group, Stanford University
> For historical note this was caused by Cyrus-sasl being built
> incorrectly by the debian packagers when heimdal is used.
I don't understand why you refer to this finding as historical. If I
am reading this correctly you and Howard have found the underlying
cause. Now that the problem is understood can you suggest a way for
us to cause the problem in our test environments? At this point we
will really need to convince ourselves that the problem is indeed fixed
before we try to deploy 2.4 in our production environment again.
Bill MacAllister, System Software Programmer
Unix Systems Group, Stanford University