[PATCH] Avoid multiple bind for the same address during config test
Maxim Dounin
mdounin at mdounin.ru
Fri Apr 12 16:09:07 UTC 2019
Hello!
On Fri, Apr 12, 2019 at 01:36:09PM +0000, i at morfi.ru wrote:
> # HG changeset patch
> # User Andrey Kolyshkin <a.kolyshkin at corp.vk.com>
> # Date 1555075759 -10800
> # Fri Apr 12 16:29:19 2019 +0300
> # Node ID 549f07c848d82ef152ed54f31b25dcfe89452a66
> # Parent 5155d0296a5ef9841f035920527ffdb771076b44
> Avoid multiple bind for the same address during config test
>
> If reuseport is specified in the config, then during config test nginx makes multiple calls to the bind function for the same address.
> It causes a problem when large number of connections goes to the server and bind (inet_csk_bind_conflict) loads cpu multiple times.
> After fixing, bind is called only 1 time per address while testing of the config.
>
> diff -r 5155d0296a5e -r 549f07c848d8 src/core/ngx_connection.c
> --- a/src/core/ngx_connection.c Tue Apr 09 16:00:30 2019 +0300
> +++ b/src/core/ngx_connection.c Fri Apr 12 16:29:19 2019 +0300
> @@ -104,7 +104,7 @@
> ngx_core_conf_t *ccf;
> ngx_listening_t ols;
>
> - if (!ls->reuseport || ls->worker != 0) {
> + if (!ls->reuseport || ls->worker != 0 || ngx_test_config) {
> return NGX_OK;
> }
>
Thank you for the patch.
Configuration testing is expected to do the same thing as normal
process of applying configuration, except when it is not possible
to do so due to external limitations. Trying to optimize various
places when testing configuration to minimize resource consumption
looks like a wrong way to go, as a) you'll anyway end up with the
resource usage in question when actually applying the
configuration, and b) doing so makes configuration testing less
likely to catch various problems.
If you have problems due to resource usage during configuration
testing, consider re-evaluating your configuration to reduce
resource usage, and/or consider calling configuration testing less
often or on dedicated servers.
--
Maxim Dounin
http://mdounin.ru/
More information about the nginx-devel
mailing list