[OpenAFS] Re: Openafs performance with Apache/PHP

Nate Gordon nlgordon@gmail.com
Mon, 13 Aug 2007 19:03:08 -0500

On 8/13/07, Russ Allbery <rra@stanford.edu> wrote:

> That -daemons value is way too high and will cause a ton of context
> switches, so that isn't what you want.  However, it sounded like you'd
> already tried tweaking that.  See the afsd man page:
>        The default number of background daemons is two, enough to service
>        at least five simultaneous users of the machine. To increase the
>        number, use the -daemons argument. A value greater than six is not
>        generally necessary.
> That's the first thing I'd reduce if you're seeing an insane number of
> context switches.

So I must have missed that chunk of the docs...  I had tried dropping
it down to 10 before and that didn't help the situation, I dropped it
down to 6 and the performance degradation finally levels off at 8
requests per second.  Context switches also dropped some, but still
hover around 220,000 when I'm hitting it with 30 users.  So this is at
least a partial solution to my problem.

> Other than that, I looked at the original message and thought "oh, that's
> interesting" but I didn't really have any useful feedback.  Have you seen
> jhutz's document on cache tuning?  It's probably the best place to start
> just to make sure that the cache values are generally reasonable and
> consistent with your working set and cache size.

I've looked through it before, but I usually get too annoyed when the
asfd process kernel panics my machine if I get dcache/stats too high.
My webservers deal with an annoying large volume of content (~35GB)
and defining a working set size seems to be a moving target to say the
least, but I'll take another stab at it.

> Certainly, if Arla is scaling, using Arla is a valid option.  I'm curious
> on improving OpenAFS to match, of course, but Arla uses a considerably
> different kernel architecture and I can see some theoretical reasons why
> it might scale better under certain loads.

Unfortunately there are other issues preventing me from using arla,
and I do realize that its almost like comparing apples to oranges as
far as internals go.  It simply degraded how I would expect it to
degrade.  This is the real crux of the problem I'm running into

Thank you all very much for the feedback.

-Nathan Gordon

If the database server goes down and there is no code to hear it, does
it really go down?