Re: Link performance over NFS degraded in RHEL5. -- was : Read/Write NFS I/O performance degraded by FLUSH_STABLE page flushing

Tom Talpey
2009-06-05T13:05:32Z

On 6/5/2009 7:35 AM, Steve Dickson wrote:
> Brian R Cowan wrote:
>> Trond Myklebust<trond.myklebust@fys.uio.no> wrote on 06/04/2009 02:04:58
>> PM:
>>
>>> Did you try turning off write gathering on the server (i.e. add the
>>> 'no_wdelay' export option)? As I said earlier, that forces a delay of
>>> 10ms per RPC call, which might explain the FILE_SYNC slowness.
>> Just tried it, this seems to be a very useful workaround as well. The
>> FILE_SYNC write calls come back in about the same amount of time as the
>> write+commit pairs... Speeds up building regardless of the network
>> filesystem (ClearCase MVFS or straight NFS).
>
> Does anybody had the history as to why 'no_wdelay' is an
> export default?

Because "wdelay" is a complete crock?

Adding 10ms to every write RPC only helps if there's a steady
single-file stream arriving at the server. In most other workloads
it only slows things down.

The better solution is to continue tuning the clients to issue
writes in a more sequential and less all-or-nothing fashion.
There are plenty of other less crock-ful things to do in the
server, too.

Tom.

As Brian mentioned later in this thread
> it only helps Linux servers, but that's good thing, IMHO. ;-)
>
> So I would have no problem changing the default export
> options in nfs-utils, but it would be nice to know why
> it was there in the first place...
>
> Neil, Greg??
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>