[TriLUG] NFS write performance problem

[Scott Stancil]

Ok, using async is a little scary from the description, but tested it out
with...

#time dd if=/dev/zero of=/mnt/home/testfile bs=8k count=32768
32768+0 records in
32768+0 records out

real    0m35.032s
user    0m0.050s
sys     0m6.790s

That works out to roughly 7.65MB/second write speed.  Just to confirm that
my testing before was 8k v. 8 (previous post), I change the async to sync
on the server in the /etc/exports file.

# time dd if=/dev/zero of=/mnt/home/testfile bs=8k count=32768
32768+0 records in
32768+0 records out

real    2m48.587s
user    0m0.040s
sys     0m4.190s

Approximately 1.5MB/second.

Wow.  Sync v. async.  What a difference in performance.

All of our default production Linux boxes have never crashed due to the OS
or our applications.  So, I _think_ for my application of the file server,
async would be a reasonable risk for the performance increase.  That said,
I have read that throwing "data=journal" at my ext3 partitions could
improve or hurt performance (Google archived news postings).  Is anyone
else using "data=journal" versus the default "data=ordered"?

Thanks for everyone's help and postings.

-- 
Scott Stancil
sstancil at geekrooms.com


> On Fri, 2002-12-27 at 14:39, Stephen P. Schaefer wrote:
>
>> Note the sync call: the NFS standard demands a sync after every write.
>>  If you want to live dangerously for more speed, you can forgo the
>> standard and NFS export your file systems "async" -- see the
>> exports(5)  man page.
>
> Note also that apparently the linux NFS implementation used
> to default to async and now, instead, defaults to sync (or
> at least that's what it told me today when I didn't have that
> in my exports file...).  So, that could be part of the problem.