 | | | NFS Help! Terrible performance with sync, fast performancewith async | NFS Help! Terrible performance with sync, fast performancewith async 2006-11-23 - By John Newbigin
Back
write through = Save the data in the cache, and write it to the disk
now. The data is cached for future reads.
write back = Save the data in the cache. Write it to the disk later.
Data may be available later for read but the main purpose is to speed up
writes. Often the RAID controller will require a battery before it will
operate in this mode. If there is a failure (such as power failure) the
data is kept in the cache until it can be written to disk.
John.
Chris Wornell wrote:
> 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
>
>
>
--
John Newbigin
Computer Systems Officer
Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Australia
http://www.ict.swin.edu.au/staff/jnewbigin
--
Taroon-list mailing list
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list
|
|
|