Date: Thu, 1 Jul 2010 14:12:52 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: alan bryan <alan.bryan@yahoo.com> Cc: freebsd-stable@freebsd.org Subject: Re: NFS 75 second stall Message-ID: <AANLkTimTpz2tG9q7Ql7T_e6mRy0Q_cjkvWkYC8HgcHu_@mail.gmail.com> In-Reply-To: <119072.59868.qm@web50504.mail.re2.yahoo.com> References: <AANLkTikxnw7sQ_cWCekS-qI3mP1Ui3dPjK1KAVqRg239@mail.gmail.com> <119072.59868.qm@web50504.mail.re2.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 1, 2010 at 1:36 PM, alan bryan <alan.bryan@yahoo.com> wrote: > > > --- On Thu, 7/1/10, Garrett Cooper <yanefbsd@gmail.com> wrote: > >> From: Garrett Cooper <yanefbsd@gmail.com> >> Subject: Re: NFS 75 second stall >> To: "alan bryan" <alan.bryan@yahoo.com> >> Cc: freebsd-stable@freebsd.org >> Date: Thursday, July 1, 2010, 1:28 PM >> On Thu, Jul 1, 2010 at 1:18 PM, alan >> bryan <alan.bryan@yahoo.com> >> wrote: >> > >> > >> > --- On Thu, 7/1/10, Garrett Cooper <yanefbsd@gmail.com> >> wrote: >> > >> >> From: Garrett Cooper <yanefbsd@gmail.com> >> >> Subject: Re: NFS 75 second stall >> >> To: "alan bryan" <alan.bryan@yahoo.com> >> >> Cc: freebsd-stable@freebsd.org >> >> Date: Thursday, July 1, 2010, 12:23 PM >> >> On Thu, Jul 1, 2010 at 11:51 AM, alan >> >> bryan <alan.bryan@yahoo.com> >> >> wrote: >> >> > >> >> > >> >> > --- On Thu, 7/1/10, Garrett Cooper <yanefbsd@gmail.com> >> >> wrote: >> >> > >> >> >> From: Garrett Cooper <yanefbsd@gmail.com> >> >> >> Subject: Re: NFS 75 second stall >> >> >> To: "alan bryan" <alan.bryan@yahoo.com> >> >> >> Cc: freebsd-stable@freebsd.org >> >> >> Date: Thursday, July 1, 2010, 11:13 AM >> >> >> On Thu, Jul 1, 2010 at 11:01 AM, alan >> >> >> bryan <alan.bryan@yahoo.com> >> >> >> wrote: >> >> >> > Setup: >> >> >> > >> >> >> > server - FreeBSD 8-stable from >> today.=A0 2 UFS >> >> dirs >> >> >> exported via NFS. >> >> >> > client - FreeBSD 8.0-Release. >> =A0Running a >> >> test php >> >> >> script that copies around various files >> to/from 2 >> >> separate >> >> >> NFS mounts. >> >> >> > >> >> >> > Situation: >> >> >> > >> >> >> > script is started (forked to do 20 >> >> simultaneous runs) >> >> >> and 20 1GB files are copied to the NFS >> dir which >> >> works >> >> >> fine.=A0 When it then switches to reading >> those >> >> files back >> >> >> and simultaneously writing to the other >> NFS mount >> >> I see a >> >> >> hang of 75 seconds.=A0 If I do an "ls -l" >> on the >> >> NFS mount it >> >> >> hangs too.=A0 After 75 seconds the client >> has >> >> reported: >> >> >> > >> >> >> > nfs server >> 192.168.10.133:/usr/local/export1: >> >> not >> >> >> responding >> >> >> > nfs server >> 192.168.10.133:/usr/local/export1: >> >> is alive >> >> >> again >> >> >> > nfs server >> 192.168.10.133:/usr/local/export1: >> >> not >> >> >> responding >> >> >> > nfs server >> 192.168.10.133:/usr/local/export1: >> >> is alive >> >> >> again >> >> >> > >> >> >> > and then things start working >> again.=A0 The >> >> server was >> >> >> originally FreeBSD 8.0-Release also but >> was >> >> upgraded to the >> >> >> latest stable to see if this issue could >> be >> >> avoided. >> >> >> > >> >> >> > # nfsstat -s -W -w 1 >> >> >> > =A0GtAttr Lookup Rdlink=A0=A0=A0Read >> Write >> >> Rename >> >> >> Access=A0 Rddir >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> 222 >> >> 257 >> >> >> =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> 178 >> >> 135 >> >> >> =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> =A0=A0=A085 >> >> =A0 127 >> >> >> =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> =A0 0 >> >> =A0 0 >> >> >> =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> =A0 0 >> >> =A0 0 >> >> >> =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> =A0 0 >> >> =A0 0 >> >> >> =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> =A0 0 >> >> =A0 0 >> >> >> =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> =A0 0 >> >> =A0 0 >> >> >> =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > >> >> >> > ... for 75 rows of all zeros >> >> >> > >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> 272 >> >> 266 >> >> >> =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > =A0 =A0 =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> 167 >> >> 165 >> >> >> =A0 0=A0 =A0 =A0 0=A0 =A0 =A0 0 >> >> >> > >> >> >> > I also tried runs with 15 >> simultaneous >> >> processes and >> >> >> 25. =A015 processes gave only about a 5 >> second >> >> stall but 25 >> >> >> gave again the same 75 second stall. >> >> >> > >> >> >> > Further, I tested with 2 mounts to >> the same >> >> server but >> >> >> from ZFS filesytems with the exact same >> >> stall/timeout >> >> >> periods. =A0So, it doesn't appear to >> matter what >> >> the >> >> >> underlying filesystem is - it's something >> in NFS >> >> or >> >> >> networking code. >> >> >> > >> >> >> > Any ideas on what's going on here? >> =A0What's >> >> causing >> >> >> the complete stall period of zero NFS >> activity? >> >> Any flaws >> >> >> with my testing methods? >> >> >> > >> >> >> > Thanks for any and all help/ideas. >> >> >> >> >> >> What network driver are you using? Have >> you tried >> >> >> tcpdumping the packets? >> >> >> -Garrett >> >> >> >> >> > >> >> > I'm using igb currently but have also used >> em. =A0I >> >> have not tried tcpdumping the packets yet on this >> test. >> >> =A0Any suggestions on things to look out for (I'm >> not that >> >> familiar with that whole process). >> >> > >> >> > Which brings up another point - I'm using >> TCP >> >> connections for NFS, not UDP. >> >> >> >> =A0 =A0 Is the net.inet.tcp.tso sysctl enabled or >> >> not? What about rxcsum and txcsum? >> >> Thanks, >> >> -Garrett >> >> >> > >> > I haven't intentionally/explicitly set any of this so >> it's "default": >> > >> > # sysctl net.inet.tcp.tso >> > net.inet.tcp.tso: 1 >> > >> > >> > igb0: >> flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> >> metric 0 mtu 1500 >> > >> =A0options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4> >> > =A0 =A0 =A0 =A0ether 00:30:48:c3:26:94 >> > =A0 =A0 =A0 =A0inet 192.168.10.133 netmask 0xffffff00 >> broadcast 192.168.10.255 >> > =A0 =A0 =A0 =A0media: Ethernet autoselect (1000baseT >> <full-duplex>) >> > =A0 =A0 =A0 =A0status: active >> >> Devise all of the available permutations that you need to >> use to test >> this out; there are a total of 3 variables, so 9 >> permutations, but >> you've already `tested one', so that makes the permutation >> count 8. >> Example: >> >> TXCSUM=3Doff, RXCSUM=3Don, TSO=3Don >> TXCSUM=3Don, RXCSUM=3Doff, TSO=3Don >> TXCSUM=3Don, RXCSUM=3Doff, TSO=3Doff >> >> ... >> >> Try executing the permutations on the client first, keeping >> the server >> constant, then make the client constant and make the server >> variable, >> and finally do both to the server and client. >> >> Be sure to take measurements for each permutation to ensure >> that >> things make functional sense. >> >> The reason why I'm suggesting this is that there were >> issues with >> em(4) [and igb(4) too I think since it uses common code], >> with various >> hardware offload bits on 8.0-RELEASE (IIRC disabling txcsum >> did the >> trick, but you may have to do more than that in order to >> get things to >> work). >> >> Here's a similar thread with a different driver: >> http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008264.html >> (just to illustrate the thought process used to determine >> the source >> of failure). > > Thanks for the detailed test plan! Np ;).. > Is it also fair to then assume that if I update the NFS client machine to= the latest 8-Stable that should also fix this issue? =A0(Both will then be= running the latest 8-stable code). =A0These are not in production so I can= test or upgrade with no issues. You can try that, but it would be better to determine (with minimal effort) that disabling one of the features is the root cause; after that you can upgrade to a later version if you want and see whether or not there's an issue with the stack (there's been some churn with em(4) cards though so I'd avoid doing that unless you're willing to live with soaking things in a bit more on the 8.0-RELEASE machine side). FWIW I've seen whacky ass problems with TSO on and ipfw on my Dell 2950 (uses bce(4)) so I've disabled it for the time being... Cheers, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimTpz2tG9q7Ql7T_e6mRy0Q_cjkvWkYC8HgcHu_>