freeing buffers after sending them

[George .]

Hi Valentin,

Than you for your fast and correct reply.

Yes, you are right, it was oversight that r->out->buf if taken from
pipe->pool, which is actually  r->pool.
What if we pfree this bufs from  r->pool? Who holds the reference after
sending these buffers (except may be in NGX_THREADS version)?


On Wed, Oct 12, 2016 at 2:30 PM, Valentin V. Bartenev <vbart at nginx.com>
wrote:

> On Wednesday 12 October 2016 13:22:08 George . wrote:
> > Hi all,
> >
> > What do you think about freeing buffers after being sent by send_chain?
> > Because we have a special case were we use 4 megabyte buffer instead of
> > nginx default 8 * 8 K and we found that these buffers are actually freed
> > after request had been finished, so if there hundreds of slow downstream
> > connection nginx will eat a lot of RAM.
> >
> > I'm just curious if I explicitly return already consumed buffer with
> > ngx_pfree  will affect something (our bunch of tests shows at least there
> > is not crash or unexpected behaviour)
> >
>
>
> Buffers are not allocated from "c->pool", so
> the code below does nothing except wasting CPU.
>
> And this is the only reason, why the patch doesn't
> break everything.
>
>   wbr, Valentin V. Bartenev
>
>
>
> >
> > @@ -284,6 +284,13 @@ ngx_http_write_filter(ngx_http_request_t *r,
> > ngx_chain_t *in)
> >
> >      chain = c->send_chain(c, r->out, limit);
> >
> > +    /* free buffs that are already sent */
> > +    for (cl = r->out; cl; /* void */) {
> > +        ln = cl;
> > +        cl = cl->next;
> > +        ngx_pfree(c->pool, ln->buf);
> > +    }
> > +
> >      ngx_log_debug1(NGX_LOG_DEBUG_HTTP, c->log, 0,
> >                     "http write filter %p", chain)
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20161012/45cfb203/attachment.html>