[Samba] Debugging a performance issue

[Jeremy Allison]

On Fri, Apr 02, 2021 at 02:32:32PM +0200, Stefan G. Weichinger via samba wrote:
>Am 30.03.21 um 10:04 schrieb Stefan G. Weichinger via samba:
>>
>>Am 29.03.21 um 19:38 schrieb Jeremy Allison:
>>
>>>>But I don't think it should be minutes versus seconds, right?
>>>
>>>Need more details I'm afraid. "specific tasks...that take a few minutes"
>>>isn't enough to go on, sorry.
>>
>>Yes, I understand!
>>
>>I also don't know much about what they do. Basically they have 
>>several filebased databases opened, files like
>>
>>BL6F.DAT
>>BL6F.IX (index, I assume)
>>
>>and some .DIA files
>>
>>That's small files, one whole subdir is maybe 20M per customer.
>>
>>And the tasks are some processing in their software, which will 
>>result in much read/write in all the above files.
>>
>>My assumption is that the locking behavior might influence the 
>>overall time needed here. That's why I excluded the DAT files via 
>>"veto oplock files", but that was years ago.
>>
>>What's the general recommendation here, especially with Windows10 clients?
>
>Update: removing that "veto oplock files" statement improved the 
>overall behavior. Customer is happy again.

Ah, that actually makes a lot of sense. veto'ing the oplock
files causes the client to be unable to cache locally.

In the "old days" :-), client caching was a lot less
reliable (whether that was the fault of the client
or server I leave as an excersise for the reader :-).

These days we should act as close as possible
to a Windows server, so having oplocks/leases
will help a lot performance-wise.

Thanks for letting us know !