Nginx with big geo maps affects whole system performance on reload

Maxim Dounin mdounin at mdounin.ru
Tue Aug 3 17:47:15 UTC 2021


Hello!

On Tue, Aug 03, 2021 at 01:00:50PM -0400, SannisDev wrote:

> Thanks for your quick answer!
> 
> >> I'm running Nginx 1.20.1 on CentOS 8.4.2105 with a quite large geo maps,
> >> including country/isp/connection for both IPv4 and IPv6, with raw size
> about
> >> 80Mb.
> >> Hardware is: 2x Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz, 64Gb RAM
> >>
> >> On nginx testconf or reload I'm experiencing increase of running nginx
> >> latency, 99th percentile growth from 10ms to seconds.
> 
> [...]
> 
> > Loading large geo map can be quite expensive, that's expected:
> > nginx has to parse all the records provided in text and build
> > corresponding radix tree. Make sure you have enough spare CPU and
> > free memory to actually do the work without affecting other tasks
> > on the server. In particular, in my practice it is a good idea to
> > make sure the number of nginx worker processes is less than number
> > of available cores, or you'll risk getting high latencies when
> > doing CPU-intensive tasks like parsing geo maps or compressing
> > logs.
> 
> I followed this path but did not reach the end.
> Currently I set workers processes twice less than physical cores number,
> but this does not affect situation. Next step should be start nginx under
> taskset
> and set workers affinity to other cores but this sounds hacky for me.

The worker_cpu_affinity directive can be used to control which 
cores are used by nginx (http://nginx.org/r/worker_cpu_affinity).

But if you are still seeing latency spikes on configuration 
testing with nginx workers using only half of the available CPU 
cores (cores, not threads, correct?) this might indicate there is 
something wrong with scheduler configuration and it may need 
tuning.

> > Also it might be a good idea to switch to using ranges and a
> > separate include file, so nginx will be able to cache parsing
> > results in a binary file.
> 
> According to [1] ranges does not support IPv6 for now.
> Is there a chance to request this via feature request?

It's always a good idea to express the interest if there is one.  
Existing feature request is here:

https://trac.nginx.org/nginx/ticket/1306

-- 
Maxim Dounin
http://mdounin.ru/


More information about the nginx mailing list