Mailing List
Home
Forum Home
Linux - General Red Hat Linux discussion list
Installation - Getting started with Red Hat Linux
Enterprise Linux 3 - Discussion of Red Hat Enterprise Linux 3 (Taroon)
Red Hat Linux 9 - Discussion of Red Hat Linux 9 (Shrike)
Red Hat Linux 7.2 - Discussion of Red Hat Linux 7.2 (Enigma)
Red Hat Linux 7.3 - Discussion of Red Hat Linux 7.3 (Valhalla)
Apache Web Server
Oracle database, Microsoft SQL server ...
Subjects
application/x mplayer2 plugin
RPM error: db4 error(16) from dbenv >remove: Device or resource
   busy
Command stream end of file while reading
X Windows problem (xauth)
Upgrading openoffice 1 1 rpm
FTP: connection refused
FTP: connection refused
mount: /dev/cdrom: is not a valid block device
Dell Precision 650, RedHat 9, no sound
how to trace the cause resulting in the crash of bind server
Virus on the list
UNINSTALL RPM MYSQL
usb pen drives: mounting as a user
broadcom network interface
make mrproper
Couldn 't open PID file /var/run/named/named pid Permission denied
sendmail configuration on redhat
kernel 2 6 and /dev/sound/mixer not found
Promise 378 controller
Problem using up2date
mrtg step by step howto/configuration for a newbie?
Compiling and Installing Kernel 2 6
Can 't locate module ppp0, can 't locate module ppp compress 21
Lotus Notes under Wine
HOW I CAN MAKE BOOTABLE FLOPPY DISKET
/etc/security/limits conf question
Intel E/1000 driver
rpm database corrupt
Command stream end of file while reading
qla2300 modules
 
NFS Help! Terrible performance with sync, fast performancewith async

NFS Help! Terrible performance with sync, fast performancewith async

2006-11-23       - By Chris Wornell

 Back
Reply:     1     2  

Tom Sightler wrote:

>I'm not sure that this comparison is fair at all.  When you ran the
test
>on the NFS server directly, did you use sync (I'm not that familiar
with
>bonnie++ so I don't know what it does by default).  Running NFS sync
>would be comparable to running locally with the sync option since this
>forces ALL operations to be synchronous.
>
>Basically, for a fair comparison you need to mount the local filesystem
>with the "sync" option and run the test locally and then compare those
>numbers to the "sync" option with NFS.  To me it's not at all
surprising
>that "sync" operation would be MUCH slower for items like file
creation,
>even on local disks.
>
>It's possible that bonnie++ runs in sync mode, but once again I'm not
>that familiar with it.
>
>Later,
>Tom

That's a good suggestion and I gave it a try.  Mounting the NFS share
locally gave me the exact same problem as mounting it remotely.  In
fact, when it came to the meta-data changes, the NFS server had the same
performance as the NFS clients that mounted the share remotely.  

After some more research, I found the culprit.  The write policy on the
RAID controller was set to "write through".  When I changed the policy
to "write back", I got the increase in performance I was looking for.

Can anyone give a dumbed-down explanation between write through and
write back. The information I found, even on wikipedia was too sparse
for me to get a firm grasp. I'm not completely clear on what the data
store is exactly (though I assume it would be the onboard RAM on the
RAID controller) and what cache lines are.

And my last question is after reading about NFSv3 more, I found that
async on NFSv3 appears to be a hybrid of what NFSv2 async and sync.  I
read that when an NFSv3 server has async enabled on a share, the server
will reply to the client that the data has been written, but the client
will still hold the data in it's cache until the server replies back
with a commit.  To me, this looks like the compromise I'm looking for in
getting the performance of async but the safety of sync.  Can anyone
comment on this?  How do I know this behavior is happening if I enable
async for a share?

Thanks,

Chris Wornell
Network Administrator, Information Technology
Peerless Systems Corporation
http://www.peerless.com
office: 310.727.5723
fax: 310.727.5715
mailto:cwornell@(protected)

-- --Original Message-- --
From: taroon-list-bounces@(protected)
[mailto:taroon-list-bounces@(protected)] On Behalf Of Tom Sightler
Sent: Tuesday, November 21, 2006 11:35 AM
To: Discussion of Red Hat Enterprise Linux 3 (Taroon)
Subject: Re: NFS Help! Terrible performance with sync, fast
performancewith async

On Sun, 2006-11-19 at 04:58 -0500, Chris Wornell wrote:

> For testing, I'm using bonnie++. The following are some sample test
> results that sum up the problem:
>
> Test on NFS server directly (not NFS loopback)
> -Sequential File Creation: 2976
> -Sequential File Deletion: N/A
> -Random File Creation: 3077
> -Random File Deletion: 9922
>
> NFS test with sync enabled
> -Sequential File Creation: 39
> -Sequential File Deletion: 79
> -Random File Creation: 39
> -Random File Delection: 65
>
> NFS test with async enabled
> -Sequential File Creation: 575
> -Sequential File Deletion: 1718
> -Random File Creation: 543
> -Random File Deletion: 1228
>
I'm not sure that this comparison is fair at all.  When you ran the test
on the NFS server directly, did you use sync (I'm not that familiar with
bonnie++ so I don't know what it does by default).  Running NFS sync
would be comparable to running locally with the sync option since this
forces ALL operations to be synchronous.

Basically, for a fair comparison you need to mount the local filesystem
with the "sync" option and run the test locally and then compare those
numbers to the "sync" option with NFS.  To me it's not at all surprising
that "sync" operation would be MUCH slower for items like file creation,
even on local disks.

It's possible that bonnie++ runs in sync mode, but once again I'm not
that familiar with it.

Later,
Tom



--
Taroon-list mailing list
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list

--
Taroon-list mailing list
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list