Enabling profiling globally ...

[Richard Sharpe]

On Thu, Apr 7, 2016 at 7:38 AM, Ralph Boehme <slow at samba.org> wrote:
> On Thu, Apr 07, 2016 at 07:19:38AM -0700, Richard Sharpe wrote:
>> On Thu, Apr 7, 2016 at 3:34 AM, Ralph Boehme <slow at samba.org> wrote:
>> > On Wed, Apr 06, 2016 at 04:59:32PM -0700, Richard Sharpe wrote:
>> >> On Wed, Apr 6, 2016 at 11:54 AM, Richard Sharpe
>> >> <realrichardsharpe at gmail.com> wrote:
>> >> >> that put it in your smb.conf. Cf man smb.conf, this is an existing
>> >> >> parameter.
>> >> >>
>> >> >> This seems so obvious that I'm suspecting that I miss something
>> >> >> here...
>> >> >
>> >> > Actually, there is one additional thing I would like to be able to do,
>> >> > and that is have this switched on dynamically when the smb.conf
>> >> > changes.
>> >> >
>> >> > Currently it is only checked/change when the smbd starts.
>> >>
>> >> It turns out I was asking the wrong question.
>> >>
>> >> What I really want is profiling on a per-share basis so I can figure
>> >> out which shares to co-locate on the same nodes in a cluster and so
>> >> forth based on which ones are getting more or less ops.
>> >
>> > I have some dated wip patches that do just that afair. Attached, feel
>> > free to munge and make something usable out of it. They don't apply to
>> > master, but should be easy to massage them so they do.
>> >
>> > The main problem is, that the stats aggregation becomes expensive with
>> > many users and shares.
>>
>> Thanks. I haven't looked at them yet, but was thinking along the lines
>> of separate shared segments per share.
>
> Shared segments of what? :) Note that the profiling code doesn't use
> sysv shared memory anymore, but a tdb.

Well, that is incredibly civilized!

>> However, that becomes expensive
>> if the customer wants thousands of shares (and I have heard of that,
>> although most of them seem to be fake shares of the sort you get when
>> you dynamically create a share per user for their home directory, for
>> example.)
>
> if you only have care about shares I think it's okay. It gets
> expensive if you enable per user *and* per share profiling, because
> then the aggregation has O(user*share) performance.

We only care about per-share info, so we might not aggregate, although
we might want to use SMB2 ops as a proxy for the amount of CPU devoted
to serving a particular share :-(

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