samba - Nov 2024 - Slow reply to "smbclient -NL localhost" : strace

On 04/11/2024 15:11, Rowland Penny via samba wrote:
> As I said previously, I do not think this has anything to do with
> Samba. In an earlier post, you had this output when you ran the same
> command using 'time':
>
> real    0m12.500s
> user    0m0.732s
> sys     0m0.102s
>
> The 'real' time is the total time it took to run the command, but
> 'user' + 'sys' is the actual time it took for the Samba
part of it, in
> this case 0.834 seconds, the remaining 11.666 seconds is where your
> problem lies, what is causing this ?
> That is what you need to trace, what is getting in the way, it doesn't
> seem to be anything to do with Samba.
>
> When it comes down to it, your 'strace' appears to be useless in
this
> context, there is no 'time' involved.
Thanks. So I'll look elsewhere to understand why that command is taking 
so long.

FWIW, there's no delay after I run it once? but only for a couple of 
minutes.

On Tue, 5 Nov 2024 10:36:49 +0100
Gilles via samba <samba at lists.samba.org> wrote:
> On 04/11/2024 15:11, Rowland Penny via samba wrote:
> > As I said previously, I do not think this has anything to do with
> > Samba. In an earlier post, you had this output when you ran the same
> > command using 'time':
> >
> > real    0m12.500s
> > user    0m0.732s
> > sys     0m0.102s
> >
> > The 'real' time is the total time it took to run the command,
but
> > 'user' + 'sys' is the actual time it took for the
Samba part of it,
> > in this case 0.834 seconds, the remaining 11.666 seconds is where
> > your problem lies, what is causing this ?
> > That is what you need to trace, what is getting in the way, it
> > doesn't seem to be anything to do with Samba.
> >
> > When it comes down to it, your 'strace' appears to be useless
in
> > this context, there is no 'time' involved.
> 
> Thanks. So I'll look elsewhere to understand why that command is
> taking so long.
I took a look at your strace again and I noticed that the hostname was
'sheevaplug', now I can only really think of one reason why such a
hostname would be used, if it was an actual Sheevaplug.

If this is a Sheevaplug, then that could be your problem.
From memory, the Sheevaplug had a single core ARM CPU, running at just
over 1GHZ with about 512MB of memory. To be honest I haven't heard of
one of these for years, they were supplanted by the Raspberry pi, a
much more capable computer, that has only got better and better.
 
> 
> FWIW, there's no delay after I run it once? but only for a couple of 
> minutes.
It is probably getting cached in memory and then overwritten.

Rowland

05.11.2024 12:36, Gilles via samba wrote:
> On 04/11/2024 15:11, Rowland Penny via samba wrote:
>> As I said previously, I do not think this has anything to do with
>> Samba. In an earlier post, you had this output when you ran the same
>> command using 'time':
>>
>> real??? 0m12.500s
>> user??? 0m0.732s
>> sys???? 0m0.102s
>>
>> The 'real' time is the total time it took to run the command,
but
>> 'user' + 'sys' is the actual time it took for the Samba
part of it, in
>> this case 0.834 seconds, the remaining 11.666 seconds is where your
>> problem lies, what is causing this ?
>> That is what you need to trace, what is getting in the way, it
doesn't
>> seem to be anything to do with Samba.
>>
>> When it comes down to it, your 'strace' appears to be useless
in this
>> context, there is no 'time' involved.
> 
> Thanks. So I'll look elsewhere to understand why that command is taking
so long.
Rowland gives unverified information here, and is
adding to the confusion and distracting attention
from actual problem to somewhere else.

time command shows *CPU* time spent in user space
or system space.  There, CPU time spent by the user
space is 0.7s, and in system is 0.1s.

But the rest of the time might be spent in any system
call which is waiting for something.

For example:

  $ time sleep 5
  real	0m5,001s
  user	0m0,001s
  sys	0m0,000s


If smbclient were just to run usleep() function, it will
show exactly the same behavior.

What's happening here, most likely, is that smbclient is
making some network calls and is waiting for the reply.

It might be a DNS problem or samba (configuration) problem,
depending on where and what it is waiting for.

And yes, this will be visible in the strace output.
> FWIW, there's no delay after I run it once? but only for a couple of
minutes.
This suggests it might be a name resolution issue.

/mjt