Status of shared memory zones

[Jaume Sabater]

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.

On Wed, Aug 20, 2025 at 6:15 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, Aug 20, 2025 at 01:06:33PM +0200, Eirik Øverby via nginx wrote:
>
> > Let me start with a (belated) thank you to all contributors for
> > the continued work on freenginx. We are in the process of
> > switching to it - late but hopefully good!
> >
> > In the commercial F5 nginx, there has for some time been ways to
> > monitor the status/usage of shared memory zones and (presumably)
> > some other run-time stats that remain opaque to users of the
> > community version. I'm wondering if there are any such
> > facilities in freenginx - implemented or planned? It would be
> > nice if the VTS plugin could emit some statistics, for example.
> >
> > We would be quite interested in such a feature, but realise it
> > will be a fair amount of work for a relatively narrow audience.
> > Is there any way we can "encourage" such functionality to be
> > added, e.g. through financial support or some other means? We
> > might even be able to produce code to do it, but would prefer if
> > it was done by someone who is already familiar with (free)nginx
> > and its architecture - we have no such people on-hand.
>
> Providing better status information might indeed be an interesting
> area for improvements.
>
> Right now, the only status information provided by freenginx is
> that shown by stub_status, which is quite limited and basically
> only shows connections in various states and total
> accepts/requests counters.  Everything else needs to be monitored
> either via logs or with 3rd party modules, like VTS you've
> mentioned.
>
> It would be great if you could share which stats you use/monitor,
> and how.  In particular, it would be interesting to know preferred
> data formats.
>
> It would also be interesting to know how you expect to use
> information about shared memory zones usage.
>
> As for improving the VTS module, I don't think it's specific to
> freenginx.  Information about shared memory zone usage is in the
> ngx_slab_pool_t structure since nginx 1.11.7, and it's more or
> less a question of showing this information properly.  Just in
> case, relevant commits are:
>
> changeset:   6828:99770a5ea14f
> user:        Ruslan Ermilov <ru at nginx.com>
> date:        Wed Dec 07 22:25:37 2016 +0300
> summary:     Slab: slots statistics.
>
> changeset:   6829:6e757036e588
> user:        Ruslan Ermilov <ru at nginx.com>
> date:        Wed Dec 07 22:25:37 2016 +0300
> summary:     Slab: free pages statistics.
>
> https://freenginx.org/hg/nginx/rev/99770a5ea14f
> https://freenginx.org/hg/nginx/rev/6e757036e588
>
> --
> 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/57de0d08/attachment.htm>