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?
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?
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?
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.
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.
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.
The config listen option rcvbuf which maps to the TCP SO_RCVBUF,
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.
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.