Ten to 1 expansion of SMB requests to fcntl system calls?

[Richard Sharpe]

On Thu, May 23, 2013 at 11:46 PM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Thu, May 23, 2013 at 01:52:41PM -0700, Jeremy Allison wrote:
>> On Wed, May 22, 2013 at 09:04:50PM -0700, Richard Sharpe wrote:
>> > Hi folks,
>> >
>> > I have been running some dbench runs using the standard client.txt
>> > file and using dtrace to measure system calls made by the smbd.
>> >
>> > For ~97,000 requests (SMB1 requests) I see 1,288,252 fcntl syscalls.
>> > This seems excessive. Where might those be coming from?
>> >
>> > This is a FreeBSD 8.0 system.
>>
>> This is almost certainly the tdb locking primitives.
>
> True. But which tdb and what can we do about it?

A more useful performance indicator captured with the dtrace
procsystime script shows this:

    gettimeofday            9212264
           lseek            9336442
        pathconf           18606662
          statfs           29714064
          access           30073540
         fstatfs           31360178
           lstat           33902417
  extattr_get_fd           38793210
          fchmod          147266506
          rename          156300564
           fstat          234898224
          utimes          237551881
   getdirentries          253926535
extattr_set_link          371269699
           pread          671050763
          unlink          768327954
          pwrite          825201124
         fstatat          866823356
   clock_gettime         1257134991
          writev         1984839112
            read         2922189298
           close         6180434183
           fcntl         7849631277
            stat         7872399963
extattr_get_file         7887564205
           ioctl         9034605338
            open        23145865857
          select       274329462364
            poll       753606057912
        _umtx_op      1097794513187

These are in nanoseconds accumulated in each syscall.

Here, fcntl is not the biggest target. I have to figure out what
umtx_op is. The fact that select and poll are there suggests that they
are waiting in the kernel rather than spending time doing much, but
maybe not.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)