dds@spsd.uu.net (Dennis D. Sherod) (04/06/90)
How does one go about determinig how many of each type of daemon is optimal for a given server? The documentation suggests that "4 is probably a good number", but makes no mention of how this is derived. -- Dennis Sherod, Data General Corporation UUCP: ..!uunet!spsd!dds 2603 Main St., Ste. 360, Irvine, CA 92714 ARPA: sherod_d@sdsa01.CEO.DG.COM FAX: +1 714 250 6061 VOICE: +1 714 250 6005 x4233
liam@cs.qmw.ac.uk (William Roberts) (04/09/90)
In article <DDS.90Apr5214722@spsd.uu.net> dds@spsd.uu.net (Dennis D. Sherod) writes: >How does one go about determinig how many of each type of >daemon is optimal for a given server? The documentation >suggests that "4 is probably a good number", but makes no >mention of how this is derived. You really know how to ask the $64,000 questions! First off, the number of biods is probably irrelevant so long as it is more than one, and in any case it makes no difference once you have exceeded the size of the array allocated for client structures in the kernel. Try asking for 10 biods and see how many actually clock up CPU time. The number of nfsds is harder, but the most recent Sun documentation hints at "four or more" which is progress of a sort. It is almost impossible to determine because there isn't any useful statistics gathering in the kernel for this. One number to look at is the nullrecv total in the "nfsstat -s" output: this tells you how many times and nfsd woke up to do some work but had it snatched away by an nfsd which had finished work and was just checking to see if more work was available. If you are getting lots of these then you could lower then number of nfsds, because it means that nfsds are lying idle even though there is a lot of work to be done. The amount of work to be done is essentially limited by having a fixed sized socket buffer for UDP requests (nfsds all share the same socket). If you look at "netstat -s" and consider the number of UDP socket overflows then that includes packets lost due to buffering problems (Sun, how about a buffering strategy based on number of packets rather than total data length? Say one packet per nfsd...). If your system uses NFS 3.2 or above then you shouldn't be penalised for having more nfsds - before NFS 3.2 the kernel would wake up all of the nfsds to handle a single request, so if you had 20 then 1 would do the work and 19 would wake up and go to sleep again, just to slow the whole thing down! Summary: if Sun knew, they wouldn't write such stupid things in their manual pages. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 01-975 5250 (Fax: 01-980 6533)