Tom Tucker wrote: > Maybe this this is a TCP_BACKLOG issue? > Hmm, Google does not yield much information about this. I think I know what that would be, is there a cure or some kernel switches for tuning that? > BTW, with that many mounts won't you run out of "secure" ports (< 1024), > so you'll need to use 'insecure' as a mount option. Not to my knowledge. All connections go to a single port onto the server box (well, one port per service). Only the clients may run out of privileged ports of they do too much mounting, but mostly this option is just for "security" reasons. At least that's my understanding. By the ways, discussing this issue with my colleague cluster admins, the question popped up, if there is a guideline/rule of thump of how many nfsd one should run - or asking the other way round, how to arrive at a good compromise. Our server boxes are pretty big (8 cores, 16 GB memory, 16 disk Areca1261 RAID6), so the resources used by the nfsd are not much of an issue - I even tested with 1024 nfsd idling around. AT some point increasing the number does not make much sense because I cannot get the data out fast enough or the seeks will likely "kill" the box^Wperformance. Any thoughts on that? Cheers Carsten ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ NFS maillist - NFS@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/nfs _______________________________________________ Please note that nfs@xxxxxxxxxxxxxxxxxxxxx is being discontinued. Please subscribe to linux-nfs@xxxxxxxxxxxxxxx instead. http://vger.kernel.org/vger-lists.html#linux-nfs -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
