[24873] in Kerberos
Re: context negotiation performance problem
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Nov 2 16:15:27 2005
In-Reply-To: <436929A5.6030301@clusterfs.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <08A35B0E-949B-4FA9-9550-78AABB051CA5@mit.edu>
Content-Transfer-Encoding: 7bit
From: Ken Raeburn <raeburn@mit.edu>
Date: Wed, 2 Nov 2005 16:14:45 -0500
To: Eric Mei <ericm@clusterfs.com>
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
On Nov 2, 2005, at 16:03, Eric Mei wrote:
> I searched archive but didn't find the answer.
>
> I made a simple test for security context negotiation of MIT
> krb5-1.3.5, under Linux, driven by GSSAPI: client call
> gss_init_sec_context() and send token to server, server call
> gss_accept_sec_context() and send back the result token.
>
> on a P4 1.6G machine, the server only could handle ~10 requests per
> second, and there's lots of disk I/O during running. By strace, I
> found krb5 libraries created a temp file under "/var/tmp", and call
> following syscalls for each request:
> write(fd, data, 50);
> fsync(fd);
> The fsync() certainly lead to low performance. Anybody know why it
> is here?
That's almost certainly the replay cache file, meant to prevent the
re-use of a transmitted authenticator by an attacker. The fsync is
there to handle the problem of the machine crashing or losing power
after an authenticator has been accepted and a data exchange
performed, but the on-disk cache not yet updated.
If your protocol or threat model is such that replay attacks are not
a problem, then under later versions of the code (I'd check whether
it's in the 1.4 series, but the machine where I keep my source trees
checked out ate its root file system over the weekend) you could set
the environment variable KRB5RCACHETYPE to "none" before starting the
program. (Look for src/lib/krb5/rcache/rc_none.c to see if you've
got the support.)
> Besides the fsync(), vmstat shows ~200 blocks write per seconds. It
> seems the above "write(fd, data, 50)" can't produce that much data.
> So where those write come from? Are there any other known issue
> might affect performance?
Doesn't ring a bell offhand...
> Our server might experience 1000s of context negotiation requests
> at the same time, so the above performance problem looks serious to
> us.
Is this a single-process server, or multiple processes? Multiple
processes would probably deal better with the fsync calls.
Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
