Status of shared memory zones

[Maxim Dounin]

Hello!

On Thu, Aug 21, 2025 at 09:38:16AM +0200, Jaume Sabater wrote:

> Related to the information provided by NGINX via stub_status, I would like
> to suggest implementing ways to get feedback on the upstream servers, so
> one could figure out when they are done with requests and updates on the
> upstream node can start again.
> 
> For example, let's say I have an upstream "myapp" with two servers, "
> myapp1.domain.com" and "myapp2.domain.com". I add the "down" option to the
> first one and reload. Then I have to wait for the server to finish off
> processing requests to that first server before deploying the new version
> of the "myapp" application. Once completed, I need to remove the "down"
> option, add it to the other server, then reload. Not sure if this is the
> expected way to do things, of course, but right now I need to play with
> console tools to check for connections, which is not as reliable as having
> NGINX inform about, say, they number of active requests with "
> myapp1.domain.com".

Thanks for the input.

With reloads, I don't think implementing this would be trivial and 
can be done efficiently, as this information needs to be collected 
and updated in shared memory.  Even when using upstream shared 
memory zones, since these are recreated on configuration reloads, 
so the new worker processes don't have access to data of old 
upstream servers.

Just in case, the most simple approach for the particular use case 
would be to monitor old worker processes - and when they are all 
done, you can be sure the upstream server in question is no longer 
used.  This should work even if the same server is used elsewhere, 
and you cannot rely on checking connections and/or status of the 
upstream server itself.

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