[PATCH] winbindd: control number of winbindd's client connections

Uri Simchoni urisimchoni at gmail.com
Wed Jun 3 12:46:08 MDT 2015


Well, if the user has one less parameter to worry about...
In principle we should accept new connections if the number of clients
is below limit, and the existing parameter (winbind max clients)
handles that. Waiting further until we're 10% below the limit saves
some stop/start accepting events, which has a marginal positive effect
on performance (save some system calls in case of epoll) and is easier
on the log file (since hitting the limit generates a log). It looked
to me that this didn't justify a new parameter.
One other point is that hitting the maximum is to be avoided (hence it
generates a level-0 log) because it makes clients reopen connections
all the time, and therefore the user is expected to fine-tune the max
number of client connections (and possibly max number of domain
connections) in order to prevent the limit from being reached, and not
to fine-tune the system behavior when the limit is reached.

If you remain unconvinced, I can add a parameter.

Thanks,
Uri.



On Wed, Jun 3, 2015 at 9:01 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Tue, Jun 2, 2015 at 11:12 PM, Uri Simchoni <urisimchoni at gmail.com> wrote:
>> This patch handles a case we've encountered in which winbindd opened
>> client connections up to the process limit on open file descriptors.
>>
>> It actually happened in the field with a samba 3.3.16-based NAS
>> appliance serving 200-300 SMB clients. Other factors that caused this
>> were:
>> - winbindd is contacting the DC for each session-setup (Bug 11259)
>> - serving the requests was slow because winbindd was reopening the
>> ldap connection for each request (Bug 11267 - already fixed)
>> - DNS misconfiguration on site made serving the requests even slower
>>
>> However, the basic behavior is that the winbindd client limit is not a
>> hard limit and I've been able to reproduce it with latest master using
>> a specially-crafted program which opened multiple requests to
>> winbindd.
>>
>> This patchset is divided into two parts:
>> - parts 1-4 modify winbindd to make the client limit a hard limit -
>> stop accepting new connections when the limit is reached and resume
>> accepting when possible.
>> - part 5 modifies the client side, removing the policy to retry up to
>> 10 times if winbindd doesn't answer within 30 seconds (after
>> connection has been opened and request sent). This change prevent a
>> vicious cycle of piling more and more requests on winbindd if it is
>> already too busy. Instead the client timeout is increased to 300
>> seconds (30 seconds x 10), relying on winbindd to respond earlier with
>> a failure code according to "winbind request timeout".
>
> One quick comment. Here:
>
> +static void resume_accepting_if_needed(void)
> +{
> +       if (winbindd_num_clients() <= lp_winbind_max_clients() * 9 / 10) {
> +               DEBUG(5,("winbindd: Resuming accept of connections "
> +                        "at %d client connections\n",
> +                        winbindd_num_clients()));
> +
> +               winbindd_resume_accepting();
> +       }
> +}
> +
>  /* Remove a client connection from client connection list */
>
> You are applying a hard rule to when we can restart accepting
> connections, but maybe this should be a user settable parameter?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂?唯有杜康。--曹操)


More information about the samba-technical mailing list