Status of shared memory zones

[Jaume Sabater]

Hi, Maxim, and thanks for the feedback.

My approach is to monitor the downstream NGINX server, whereas I think that
your approach points at monitoring the upstream Gunicorn, isn't it? If so,
then yes, that's another way to do it. I have never checked whether
Gunicorn (in my particular case) offers that information, but it would
definitely be one way to do it.

Anyhow, I still would love to be able to query NGINX for much more
information about active requests and upstreams but, unfortunately, I
cannot be of much help with the internals of NGINX.

Thanks.


On Thu, Aug 21, 2025 at 4:05 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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/
>


-- 
Jaume Sabater
"Ubi sapientas ibi libertas"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20250821/ddb25de7/attachment.htm>