[Date Prev][Date Next]
Re: ldapsearch SASL/GSSAPI bind really slow
On Tue, 2012-09-04 at 08:50 -0700, Quanah Gibson-Mount wrote:
> --On Wednesday, July 25, 2012 2:39 PM -0600 "Matthew B. Brookover"
> <email@example.com> wrote:
> > When using an anonymous bind, the old server takes longer then the new
> > server -- which is what I would expect given that the new server has
> > twice the number of faster processors and double the memory of the old
> > server.
> > Any ideas?
> DNS lookup issues? MIT's Kerberos replay cache? If it is pausing in the
> GSSAPI negotiation, see if you can figure out which function call is
> hanging the longest using a one entry result and -d -1 to ldapsearch.
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> Zimbra :: the leader in open source messaging and collaboration
It turns out, that this is only a problem when selinux is enabled. Turn
off selinux and SASL is much faster. I do not know if saslauthd or
Kerberos is the problem. I have been able to recreate the issue with
the sasl-sample client and server when selinux is enabled. I have also
been able to recreate the issue with the CentOS 6.3 build of Cyrus SASL
2.1.23 and my own build of Cyrus SASL 2.1.25 on CentOS 6.3. On my todo
list is to re-post the issue to the SASL mail list, but unfortunately I
have not had time.
I figured my original message got gobbled up by a moderator or spam
filter. I posted this in July and was rather surprised to see it show
I like your suggestion of looking for a specific function call where it
is hanging. When I get a chance, I will try gprof on saslauthd.