[Patch] SO_REUSEPORT support from master process
yingqi.lu at intel.com
Fri Sep 19 17:34:10 UTC 2014
I just tested the exact case you mentioned and you are right! There is a connection drop, but it got recovered really quickly. The new connections will only go to the remaining listen sockets on a round robin fashion after the reload.
I will change the check of "active cpu" to "all cpu". This will make the number of listen sockets a constant as long as the system remain active. Thank you very much for your hint!
I will also check the coding style again and resend the patch.
From: nginx-devel-bounces at nginx.org [mailto:nginx-devel-bounces at nginx.org] On Behalf Of Valentin V. Bartenev
Sent: Friday, September 19, 2014 9:48 AM
To: nginx-devel at nginx.org
Subject: Re: [Patch] SO_REUSEPORT support from master process
On Friday 19 September 2014 15:52:35 Lu, Yingqi wrote:
> Hi Valentin,
> Thanks very much for your email.
> Regarding to your first question, I did following test:
> 1. Start Nginx
> 2. Offline half of the CPU threads by "echo 0 >
> 3. Reload Nginx and check the worker process, the number of listen
> sockets is actually reduced to half.
> 4. Then, I put back the offlined CPU threads back online, and reload the Nginx again.
> 5. The new worker process now has 2X listen sockets as the CPU threads
> doubled since the previous reload.
> Every time Nginx reloads, my understanding is it will run Ngx_init_cycle. CPU_num_check is > there. Is above testing the correct way to check if reload works? Please let me know if I > missed anything.
What happens if you shutdown half of your cpus again, and try to reload nginx under high load?
As I understand right, with your patch it will close half of listen sockets, and all the connections that have been waiting to be accepted on these sockets will be lost.
wbr, Valentin V. Bartenev
nginx-devel mailing list
nginx-devel at nginx.org
More information about the nginx-devel