Travis Tabbal wrote:
> Thanks for the reply. Yes, I have read it. I'm not thinking that OS, ZFS, or
> the NFS implementation is in error here. Just that it would be nice if I
> could tune it a little better. Preferably on a per-filesystem basis as the
> zfs FS with large files performs very well.
>
> There is mention of a write cache, how can I enable that? The server is on a
> UPS, so I'm not bothered by the possibility of data loss due to the COMMIT
> not doing an fsync before returning. I don't want zil_disable, but I suppose
> I could add an SSD as the ZIL to try to improve that problem.
Hi Travis,
Another option which usually helps is bumping up the number of async
threads (responsible for commits, readaheads, etc) on the client. This
is done with:
nfs:nfs3_max_threads=32
in /etc/system, which changes the default 8 async threads per mount to
32. This is especially helpful for NFS over 10Gb and sun4v client
platforms. Adjust to taste; See:
http://docs.sun.com/app/docs/doc/819-2724/chapter3-3
For ZFS, a separate ZIL (slog) device is critical, particularly for this
workload, as mentioned in the ZFS/NFS perf doc. SSD, while ideal,
isn't the only option which can make a real difference. Just some slice
(1.5-2X RAM is a typical size) of an otherwise lightly loaded disk, or
some small stand alone disk, should provide a real improvement.
- Neil
