| From | Sent On | Attachments |
|---|---|---|
| Rick C. Petty | Jun 27, 2010 3:15 pm | |
| Rick Macklem | Jun 27, 2010 4:47 pm | |
| Rick C. Petty | Jun 27, 2010 8:13 pm | |
| Rick C. Petty | Jun 27, 2010 8:47 pm | |
| Rick Macklem | Jun 27, 2010 9:13 pm | |
| Rick Macklem | Jun 27, 2010 9:18 pm | |
| Jeremy Chadwick | Jun 27, 2010 9:58 pm | |
| Rick C. Petty | Jun 28, 2010 7:00 am | |
| Rick C. Petty | Jun 28, 2010 7:20 am | |
| Jeremy Chadwick | Jun 28, 2010 7:55 am | |
| Rick C. Petty | Jun 28, 2010 8:18 am | |
| Rick C. Petty | Jun 28, 2010 8:35 am | |
| Jeremy Chadwick | Jun 28, 2010 9:28 am | |
| Rick Macklem | Jun 28, 2010 4:33 pm | |
| Rick Macklem | Jun 28, 2010 4:54 pm | |
| Rick Macklem | Jun 28, 2010 6:57 pm | |
| Rick C. Petty | Jun 28, 2010 7:28 pm | |
| Rick C. Petty | Jun 28, 2010 7:36 pm | |
| Rick C. Petty | Jun 28, 2010 8:06 pm | |
| Ian Smith | Jun 28, 2010 8:59 pm | |
| Rick Macklem | Jun 29, 2010 7:42 am | |
| Adam Vande More | Jun 29, 2010 8:20 am | |
| Rick C. Petty | Jun 29, 2010 8:32 am | |
| Rick Macklem | Jun 29, 2010 8:59 am | |
| Dan Nelson | Jun 29, 2010 9:06 am | |
| Rick Macklem | Jun 29, 2010 9:14 am | |
| Ian Smith | Jun 29, 2010 9:14 pm | |
| Rick Macklem | Jun 30, 2010 4:56 pm | |
| Rick Macklem | Jul 1, 2010 7:49 am | |
| Rick Macklem | Jul 5, 2010 8:38 pm | |
| Rick C. Petty | Aug 28, 2010 8:22 pm | |
| Rick Macklem | Aug 29, 2010 8:43 am | |
| Rick C. Petty | Aug 30, 2010 10:22 am | |
| Rick Macklem | Aug 30, 2010 6:59 pm | |
| Rick Macklem | Aug 30, 2010 7:24 pm | |
| Hannes Hauswedell | Sep 1, 2010 6:38 am | |
| Rick Macklem | Sep 1, 2010 8:46 am | |
| Rick C. Petty | Sep 3, 2010 7:30 pm | |
| Rick C. Petty | Sep 3, 2010 7:35 pm | |
| Rick Macklem | Sep 4, 2010 9:24 am | .patch |
| Rick Macklem | Sep 4, 2010 9:55 am | |
| Rick Macklem | Sep 12, 2010 8:44 am | |
| Oliver Fromme | Sep 13, 2010 8:03 am | |
| Rick Macklem | Sep 13, 2010 8:15 am | |
| Rick C. Petty | Sep 13, 2010 8:38 am | |
| Goran Lowkrantz | Sep 13, 2010 9:35 am |
| Subject: | Re: Why is NFSv4 so slow? | |
|---|---|---|
| From: | Rick Macklem (rmac...@uoguelph.ca) | |
| Date: | Jun 27, 2010 4:47:17 pm | |
| List: | org.freebsd.freebsd-stable | |
On Sun, 27 Jun 2010, Rick C. Petty wrote:
First off, many thanks to Rick Macklem for making NFSv4 possible in FreeBSD!
I recently updated my NFS server and clients to v4, but have since noticed significant performance penalties. For instance, when I try "ls a b c" (if a, b, and c are empty directories) on the client, it takes up to 1.87 seconds (wall time) whereas before it always finished in under 0.1 seconds. If I repeat the test, it takes the same amount of time in v4 (in v3, wall time was always under 0.01 seconds for subsequent requests, as if the directory listing was cached).
Weird, I don't see that here. The only thing I can think of is that the experimental client/server will try to do I/O at the size of MAXBSIZE by default, which might be causing a burst of traffic your net interface can't keep up with. (This can be turned down to 32K via the rsize=32768,wsize=32768 mount options. I found this necessary to avoid abissmal performance on some Macs for the Mac OS X port.)
The other thing that can really slow it down is if the uid<->login-name (and/or gid<->group-name) is messed up, but this would normally only show up for things like "ls -l". (Beware having multiple password database entries for the same uid, such as "root" and "toor".)
If I try to play an h264 video file on the filesystem using mplayer, it often jitters and skipping around in time introduces up to a second or so pause. With NFSv3 it behaved more like the file was on local disk (no noticable pauses or jitters).
Has anyone seen this behavior upon switching to v4 or does anyone have any suggestions for tuning?
Both client and server are running the same GENERIC kernel, 8.1-PRERELEASE as of 2010-May-29. They are connected via gigabit. Both v3 and v4 tests were performed on the exact same hardware and I/O, CPU, network loads. All I did was toggle nfsv4_server_enable (and nfsuserd/nfscbd of course).
It seems like a server-side issue, because if I try an nfs3 client mount to the nfs4 server and run the same tests, I see only a slight improvement in performance. In both cases, my mount options were "rdirplus,bg,intr,soft" (and "nfsv4" added in the one case, obviously).
I don't recommend the use of "intr or soft" for NFSv4 mounts, but they wouldn't affect performance for trivial tests. You might want to try: "nfsv4,rsize=32768,wsize=32768" and see how that works.
When you did the nfs3 mount did you specify "newnfs" or "nfs" for the file system type? (I'm wondering if you still saw the problem with the regular "nfs" client against the server? Others have had good luck using the server for NFSv3 mounts.)
On the server, I have these tunables explicitly set:
kern.ipc.maxsockbuf=524288 vfs.newnfs.issue_delegations=1
On the client, I just have the maxsockbuf setting (this is twice the default value). I'm open to trying other tunables or patches. TIA,
When I see abissmal NFS perf. it is usually an issue with the underlying transport. Looking at things like "netstat -i" or "netstat -s" might give you a hint?
Having said that, the only difference I can think of between the two NFS subsystems that might affect the transport layer is the default I/O size, as noted above.
rick
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "free...@freebsd.org"






.patch