[47487] in SIPB-AFS-requests
Re: sipb cell AFS server tuning
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Tue Jun 18 10:03:30 2013
From kaduk@MIT.EDU Tue Jun 18 14:03:29 2013
Return-Path: <kaduk@MIT.EDU>
Delivered-To: sipb-afsreq-mtg@CHARON.mit.edu
Received: (qmail 6025 invoked from network); 18 Jun 2013 14:03:29 -0000
Received: from mailhub-auth-2.mit.edu (18.7.62.36)
by charon.mit.edu with SMTP; 18 Jun 2013 14:03:29 -0000
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r5IE3LWJ024739;
Tue, 18 Jun 2013 10:03:22 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37])
(authenticated bits=56)
(User authenticated as kaduk@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5IE3J8q025166
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 18 Jun 2013 10:03:21 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308)
id r5IE3J4I002968; Tue, 18 Jun 2013 10:03:19 -0400 (EDT)
Date: Tue, 18 Jun 2013 10:03:19 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Jonathon Weiss <jweiss@MIT.EDU>
cc: sipb-afsreq@MIT.EDU
Subject: Re: sipb cell AFS server tuning
In-Reply-To: <201306181328.r5IDSjpd012090@outgoing.mit.edu>
Message-ID: <alpine.GSO.1.10.1306180959300.26275@multics.mit.edu>
References: <201306181328.r5IDSjpd012090@outgoing.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 18 Jun 2013, Jonathon Weiss wrote:
> I just noticed a few things about the sipb AFS cell.
>
> * it looks like the fileserver is using the arguments that ops
> selected for the athena cell years ago.
>
> * ops recently changed those to increas the number of threads
> ("-p 36" --> "-p 64") and the number of callback slots ("" -->
> "-cb 256000"), and there are indications that the sipb cell
> would benefit from at least the second of these (and possibly
> the first, but that's less clear).
>
> * the sipb cell still restarts weekly. The athena cell hasn't
> done this in a long time.
>
> I'd like to see us update both fileserver arguments, and disable the
> weekly restart. That said, I don't want to interfere with the server
> upgrades Mitch and Ben are working on. Do folks agree in concept with
> these changes, and if so, have any thoughts on coordinateion? (I could
> certainly stageteh arg changes in BosConfig let one last weekly restart
> happen, and then disable that.)
Certainly while we have ~all data on ra, there have been calls waiting for
a thread, so more threads would be expected to help. It's less clear
whether more callback slots are actually needed -- there are some log
messages getting entered in conjunction with callback breaks, but I think
they are more of the "remote host does not exist anymore or is firewalled
off" sort than "we ran out of slots".
I would like to defer disabling weekly restarts (and really, all the
changes) until the software upgrade is finished, though.
-Ben
