[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?
<esc>:wq<CR>