On Sat, 20 Sep 1997, Brian Tao wrote:
I was getting very poor response when it was first installed, butthat was due to a misconfiguration with the overviews. nnrpd was looking in the wrong directory, and thus fell back to scanning the spool to generate overview records. Once that was remedied, the problems disappeared. Are you using NFSv2 and UDP? How big are your control.cancel and misc.jobs.offered spool directories?
Thanks! We are using NFSv2 with TCP. UDP fails to work with our client box (BSD/OS 3.0), because under heavy reader load (500+ readers) the box gets slower and slower, and CPU system time goes to 90+% and idle time goes to 0%. Something wrong is happening - I think this is due to bugs in BSD/OS. Interestingly, the
Sep 21 11:30:23 tofu kernel: nfs server netapp1.alt.net:/spool: not responding Sep 21 11:30:24 tofu kernel: nfs server netapp1.alt.net:/spool: is alive again Sep 21 11:30:32 tofu kernel: nfs server netapp1.alt.net:/spool: not responding Sep 21 11:30:32 tofu kernel: nfs server netapp1.alt.net:/spool: is alive again Sep 21 11:30:37 tofu kernel: nfs server netapp1.alt.net:/spool: not responding Sep 21 11:30:37 tofu kernel: nfs server netapp1.alt.net:/spool: is alive again
messages do not happen when using UDP - they only happen with TCP.
We use TCP because that works better than UDP on this particular machine. We will be moving the readers to a FreeBSD machine soon and hopefully that we will better with nfsv2/udp. Anyone seeing problems or success with FreeBSD? ;-)
We upgraded to 4.1cD3 to see if that would help, because of the directory prefetch fixes, but it didn't.
control.cancel contains 9,076 files and is 284k big:
tofu: {162} % ls -ld control/cancel drwxrwxr-x 2 news news 290816 Sep 21 11:28 control/cancel
misc.jobs.offered contains 61,515 files and is 1924k big:
tofu: {165} % ls -ld misc/jobs/offered drwxrwxr-x 3 news news 1970176 Sep 21 08:51 misc/jobs/offered
Rock on!
Chris