rcvbuf option

[atarob]

Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
> 
> On Tue, Feb 18, 2014 at 05:16:18PM -0500, atarob wrote:
> 
> > Maxim Dounin Wrote:
> > -------------------------------------------------------
> > > Hello!
> > > 
> > > On Tue, Feb 18, 2014 at 02:58:05PM -0500, atarob wrote:
> > > 
> > > > The config listen option rcvbuf which maps to the TCP SO_RCVBUF,
> is
> > > applied
> > > > to the listening socket, and not inherited by the accept()ed
> > > connections. So
> > > > if you have a high load application where the legitimate request
> is
> > > bound to
> > > > be no more than 4K, for instance, you could save a lot of RAM by
> > > dropping
> > > > the default here  without changing it at the system level.
> > > > 
> > > > I straced nginx and it does not seem to actually apply the
> settings
> > > through
> > > > a subsequent setsockopt to the accepted socket. Is this
> intentional
> > > or an
> > > > oversight?
> > > 
> > > What makes you think that SO_RCVBUF is not inherited by accepted 
> > > connections?
> > 
> > http://stackoverflow.com/a/12864681
> > 
> > I didn't run it myself, because testing it on one platform isn't
> enough to
> > assume either way. But why do you think that it is inherited in
> general?
> 
> This is how it works in BSD since BSD sockets introduction.
> While I don't think it's guaranteed by any standard, there should be 
> really good reasons to behave differently.
> 
> If you think there are OSes which behave differently and they are 
> popular enough to care - feel free to name them.

You are right. I tested it on my linux as well and it does inherit. I guess
the confusion was that getsockopt() is not returning what we set with
setsockopt() due to OS inflating it. But it is accepted socket does return
the same as the listening socket.
 
> 
> > Also, these are inherently different settings. Even if it were
> inherited, to
> > reduce the 10,000 connections on which I expect 2KB of upload, I
> have to
> > drop the listening socket's buffer size? Isn't that used by the OS
> for
> > clients that are trying to connect to the listening socket? If so, I
> > wouldn't want to drop that. In fact, since there is only one (or a
> few)
> > listening sockets, I might want to increase that while dropping the
> accepted
> > sockets' buffer size.
> 
> Listening socket's buffer size isn't something used for 
> anything.  Listening queue size aka backlog is what matters for 
> listening sockets (see listen(2)), and there is a separate 
> parameter of the "listen" directive to control it.

I was aware of backlog for listen(), but I was not comfortable to assume
that 'Listening socket's buffer size isn't something used for anything'.
Doing a bit more reading, it would appear you are right about this also.

Thanks again.

Ata Roboubi.

> 
> -- 
> Maxim Dounin
> http://nginx.org/
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,247705,247761#msg-247761