Can you describe what network hardware lies between the filer and your UNIX machine?
Im more inclined to say you have a transmission problem than a version one.
Smaller transmission windows in v2 may be hiding a performance issue in your LAN/WAN that v3 has a problem with.
End resuly may be going to TCP to introduce more reliable error correction.
-----Original Message----- From: foo [mailto:foo+netapp@eek.org] Sent: Thursday, July 27, 2000 9:18 PM To: toasters@mathworks.com Subject: Performance probs with UDP NFSv3.
Has anyone else experienced performance problems using UDP NFSv3 between Solaris 2.7 and an F760 (running 5.3.5R2)?
Using v3 I get the following errors intermittently:
Jul 27 20:41:07 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:41:07 bullwinkle unix: NFS server 10.20.10.10 ok Jul 27 20:42:06 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:42:06 bullwinkle unix: NFS server 10.20.10.10 ok Jul 27 20:43:30 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:43:30 bullwinkle unix: NFS server 10.20.10.10 ok Jul 27 20:45:40 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:45:40 bullwinkle unix: NFS server 10.20.10.10 ok
When I switched the mount to v2 (udp), these errors went away, and performance seemed to increase. Netapp documentation recommends v3, but it doesnt seem to work very well in my environment.
Since this filer is used for a DB, this is causing huge problems. Should I just leave it at v2, or is worth trying to determine why v3 is performing poorly?
-Brian
Im more inclined to say you have a transmission problem than a version
one.
Smaller transmission windows in v2 may be hiding a performance issue in
your
LAN/WAN that v3 has a problem with.
I concur. This is the most likely explanation. Tune your block size for NFSv3 down to 16K or 8K and see how you do.
End resuly may be going to TCP to introduce more reliable error
correction.
I'd stick with UDP and a smaller block size.
Bruce
I have seen this a few times, and going to TCP does fix the problem in most instances unless there is a more serious underlying network issue.
On Thu, 27 Jul 2000 21:58:39 -0700, you wrote:
Can you describe what network hardware lies between the filer and your UNIX machine?
Im more inclined to say you have a transmission problem than a version one.
Smaller transmission windows in v2 may be hiding a performance issue in your LAN/WAN that v3 has a problem with.
End resuly may be going to TCP to introduce more reliable error correction.
-----Original Message----- From: foo [mailto:foo+netapp@eek.org] Sent: Thursday, July 27, 2000 9:18 PM To: toasters@mathworks.com Subject: Performance probs with UDP NFSv3.
Has anyone else experienced performance problems using UDP NFSv3 between Solaris 2.7 and an F760 (running 5.3.5R2)?
Using v3 I get the following errors intermittently:
Jul 27 20:41:07 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:41:07 bullwinkle unix: NFS server 10.20.10.10 ok Jul 27 20:42:06 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:42:06 bullwinkle unix: NFS server 10.20.10.10 ok Jul 27 20:43:30 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:43:30 bullwinkle unix: NFS server 10.20.10.10 ok Jul 27 20:45:40 bullwinkle unix: NFS server 10.20.10.10 not responding still trying Jul 27 20:45:40 bullwinkle unix: NFS server 10.20.10.10 ok
When I switched the mount to v2 (udp), these errors went away, and performance seemed to increase. Netapp documentation recommends v3, but it doesnt seem to work very well in my environment.
Since this filer is used for a DB, this is causing huge problems. Should I just leave it at v2, or is worth trying to determine why v3 is performing poorly?
-Brian
------------------------ J. Bryan Kelsch, PSE Network Appliance 5220 Spring Valley Road - Suite 350 Dallas, TX 75240 972.759.7528 Office 817.821.0350 Cell 888.374.6422 Pager
I have seen this a few times, and going to TCP does fix the problem in
most
instances unless there is a more serious underlying network issue.
Yes, but going to TCP also reduces your performance. Perhaps even moreso than the occasional delay that gets syslogged.
Bruce