[Samba] Debugging a performance issue
jra at samba.org
Fri Apr 2 17:23:35 UTC 2021
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.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 !
More information about the samba