[1021] in arla-drinkers
RE: proposed PAG handling changes for Arla
daemon@ATHENA.MIT.EDU (Neulinger, Nathan R.)
Mon Jul 26 15:32:22 1999
From owner-arla-drinkers@stacken.kth.se Mon Jul 26 19:32:21 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 19500 invoked from network); 26 Jul 1999 19:32:20 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 26 Jul 1999 19:32:20 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id VAA10662
for arla-drinkers-list; Mon, 26 Jul 1999 21:26:10 +0200 (MET DST)
Received: from umr.edu (hermes.cc.umr.edu [131.151.1.68])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id VAA10656
for <arla-drinkers@stacken.kth.se>; Mon, 26 Jul 1999 21:25:52 +0200 (MET DST)
Received: from umr-mail01.cc.umr.edu (umr-mail01.cc.umr.edu [131.151.37.121]) via ESMTP by hermes.cc.umr.edu (8.8.7/R.4.20) id OAA29212; Mon, 26 Jul 1999 14:25:47 -0500 (CDT)
Received: by umr-mail01 with Internet Mail Service (5.5.2448.0)
id <3598YDPX>; Mon, 26 Jul 1999 14:25:47 -0500
Message-ID: <9DA8D24B915BD1118911006094516EAF029EEB2E@umr-mail02>
From: "Neulinger, Nathan R." <nneul@umr.edu>
To: "'Jeffrey Hutzelman'" <jhutz+@cmu.edu>,
Chris Wing
<wingc@engin.umich.edu>
Cc: arla-drinkers@stacken.kth.se
Subject: RE: proposed PAG handling changes for Arla
Date: Mon, 26 Jul 1999 14:25:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="ISO-8859-1"
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
The performance hit can be QUITE noticeable. Random 20-30 second lockups on
a machine that gets thousands of logins a day from users with 24 hour
tokens, some with 30 day tokens... The in-memory structure gets huge VERY
quickly.
On Solaris and some other architectures, transarc has implemented something
that scans the pags and gets rid of tokens in any unused pags.
I wrote a script to clean them up on HP-UX that is specialized for our
situation (no users running stuff authenticated as other userids on the
problem machines). It is at:
http://www.unixtools.org/~nneul/sw/afs/clean-unused-tokens.pl
It's designed for a hpux 10.20 box, though I'm sure it could easily be
adapted to others.
Running that out of cron on a regular basis has eliminated all the
performance problems/lockups.
NOTE - If you run that on a machine that has a huge pag/token list in memory
and it gets rid of a LOT of tokens/pags, you will get a couple of 40-60
second lock ups while the kernel compacts the hash. Once that is done, it
shouldn't lock up again unless you let it get huge again.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz+@cmu.edu]
> Sent: Saturday, July 24, 1999 3:58 PM
> To: Chris Wing
> Cc: arla-drinkers@stacken.kth.se
> Subject: Re: proposed PAG handling changes for Arla
>
>
> > So does the official AFS never get rid of tokens or PAG
> data structures
> > unless there is always an explicit unlog? We run some
> pretty big login
> > servers around here that use the latest 'official' AFS on Solaris or
> > HP-UX, and I haven't noticed them being particularly slow
> to setpag(),
> > despite long uptimes and the fact that most of the users don't unlog
> > before logging out.
>
> A PAG isn't a data structure; it's just a number, like a UID.
> The mere
> existence of a PAG doesn't occupy any resources -- the resources are
> occupied by the structure that holds a user's credentials.
> Such structures
> are created as needed (when you set tokens), and are automatically
> garbage-collected from time to time, if they contain no
> current tokens.
> The problem is that if a user doesn't unlog, the data
> structure holding his
> credentials is not reclaimed until up to two hours after
> those credentials
> expire.
>
> The net effect is that you don't see problems on machines
> with long uptimes
> but relatively few login sessions, but you _will_ see
> problems on machines
> which have lots of users logging in and out all day. Also,
> the performance
> hit isn't on setpag(), which is essentially free; it's on looking up
> credentials for users.
>
>
>
