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

Steve Dickson
2009-06-05T14:00:26Z

Trond Myklebust wrote:
> On Fri, 2009-06-05 at 09:30 -0400, Steve Dickson wrote:
>> Tom Talpey wrote:
>>> 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.
>> Ok... So do you think removing it as a default would cause
>> any regressions?
>
> It might for NFSv2 clients, since they don't have the option of using
> unstable writes. I'd therefore prefer a kernel solution that makes write
> gathering an NFSv2 only feature.
Sounds good to me! ;-)

steved.