Hartmann, O. wrote: > Dear Sirs. > > Using FreeBSD 4.6.2-pl2 and FreeBSD 4.7-RC2 on our server system (one 4.7-RC > experimental system) and utilizing AMD for mounting home space and other > services via TCP protocol results in > > nfs server 134.93.180.216:/usr/homes: not responding > nfs server 134.93.180.216:/usr/homes: is alive again > > very often, when load of the appropriate client is very high. That happens > when on our number crunching systems utilization of CPU time is high or > many users try copy from and to via SAMBA to the main NFS server system.
Yup. Happens because either the server or the network is swamped and some NFS packets are not being responded to as quickly as the client expects. Other than being annoying, it's not really a major problem. > This happens under heavy load and, when only a few users are on the systems, > but it happens very often while > > - copying big files/datas from PC systems via SAMBA > - whenever a number crunching job runs on a different server > and on another server a job for copying data has been started, > the influences to a completely different system, in this case the main > NFS server, is significant. > > FreeBSD offers a lot of kernel stuff tunig the system's performance, > especially for NFS etc (also sysctl changeable kernel varibales). > Can anyone help with tuned parameters or give hints how to > investigate problems? Search the mailing list archives. This was discussed some months back, and someone provided info on which knobs to tweak to make the messages go away, along with the possible pitfalls of tweaking those knobs. > What's about the fact running AMD/NFS over TCP instead of UDP? UDP > seems to give the benefit of speed, while TCP seems to be more > reliable and secure from the point of view from the network. I don't think switching to TCP will stop this. To my knowledge, TCP connections only improve reliability over sketchy connections (such as WANs) My experience with NFS/TCP has been that it doesn't really improve reliability that much either (although we were dealing with an _extremely_ flakey wireless WAN - nothing was reliable) -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
