On Fri, Oct 31, 2008 at 8:30 PM, Miles O'Neal <[log in to unmask]> wrote:
> Stephen John Smoogen said...
>
> |useful info deleted for focus.
> |
> |> So, we have two (possibly) problems.
> |>
> |> 1) Are the stats wrong, or is the problem not really
> |>   in the number of threads?  This is a fast, dual,
> |>   quadcore SuperMicro server, so I'm not worried
> |>   that it can handle the load; we have much slower
> |>   systems handling 100 threads without a hiccup
> |>   (the nature of the projects means this newer
> |>   system will get a lot more traffic).
> |>
> |>   The NIC doesn't seem to be swamped.
> |>
> |>   Is there a kernel param I need to tweak for
> |>   more open sockets or something?
> |>
> |
> |actually I think you need to look at the various nfs kernel proc/sys
> |items first before bumping up the number of threads. You could be
> |saturating various memory handlers and such and then you are just
> |exasperating the problem with more threads and such. The process may
> |be running out of open files or other items.
>
> Can you recommend a good doc for tuning these in the 2.6 kernel?
> sysctl -a doesn't show me anything that looks problematic but
> maybe I just don't know what to look for in this case.  We just
> started using the 2.6 kernels...
>

Not off the top of my head... I am going to have to punt that...
pretty much every site I have run with since 2.6.1 has gone to netapps
for NFS servers so I havent done much with it. I normally check to see
if I can get iostat/nfsstat/sar running at 10->60 second intervals and
collect that data to see what might be the problem. Sometimes it can
be that the switch/router doesn't like the packets. Sometimes its that
the buffer size for a packet needs to be increased.

http://www.ibm.com/developerworks/linux/library/l-tune-lamp-1/

I would usually start on the NFS lists and see if they can help out on this.

>
> |> 2) If I do need more daemons, how do I determine
> |>   how much memory I need?  What is the limit on
> |>   the number of daemons?
> |
> |Well the big issue may not be memory at that point but 32bit versus
> |64bit. The box might run out of possible allocations at 4GB of ram as
> |that is as much one process can map to. I am guessing that each nfsd
> |is allocating potential memory it can use for readahead and is running
> |out of what it can set-aside for a buffer.
>
> It's all 64 bit hardware and the 64 bit distro.
>

Darn.. there goes the simple answer.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"