[TriLUG] NFS write performance problem
Scott Stancil
sstancil at geekrooms.com
Sat Dec 28 02:02:12 EST 2002
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.
More information about the TriLUG
mailing list