Need for cleanup of idle winbindd child processes...

[Ravindra Channabasappa]

Hi Jeremy/David,


>> > If we enable trusted domain flag and there are 10 trusted domains, the number of processes increase (10x10) under load. Once started these processes do not exit. Also, it is observed in our setup that the memory consumed by these child processes keeps on increasing (for every load test run) without any sign of reducing. This has performance implications as we successively run load test on the winbindd daemon.
>> 
>> Do you have any "smbcontrol <pid> pool-usage" dumps, or valgrind logs 
>> showing the memory leak?

>Yep. Fixing the memory leak would be preferable :-).
>Finding it comes first..

Whether we have memory leak or not, IMO, it is not a good idea to have 100 winbindd (for example)   processes sitting idle in the box.
Agreed, fixing memory issue is a priority... will try to collect pool usage. This can be another bug to fix.

Thanks,
--ravindra


-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Thursday, March 27, 2014 11:58 PM
To: David Disseldorp
Cc: Ravindra Channabasappa; metze at samba.org; gd at samba.org; samba-technical at lists.samba.org
Subject: Re: Need for cleanup of idle winbindd child processes...

On Thu, Mar 27, 2014 at 03:56:32PM +0100, David Disseldorp wrote:
> Hi Ravindra,
> 
> On Thu, 27 Mar 2014 14:25:01 +0000, Ravindra Channabasappa wrote:
> 
> > If we enable trusted domain flag and there are 10 trusted domains, the number of processes increase (10x10) under load. Once started these processes do not exit. Also, it is observed in our setup that the memory consumed by these child processes keeps on increasing (for every load test run) without any sign of reducing. This has performance implications as we successively run load test on the winbindd daemon.
> 
> Do you have any "smbcontrol <pid> pool-usage" dumps, or valgrind logs 
> showing the memory leak?

Yep. Fixing the memory leak would be preferable :-).
Finding it comes first..

> I'd prefer something like...
> 
> 3. Attach a tevent timer to the child process, which is re-initialized
>    on ~every request. When the timer fires after a period of inactivity,
>    cleanup and die.

Yes, that's much more like the way we do things internally now.

Jeremy.