hey all,
We have a request to bump up SOMAXCONN. Are there are repurcussions to
doing so? Would it be better to make it a sysctl?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[email protected]
Tim Hockin <[email protected]> writes:
> hey all,
>
> We have a request to bump up SOMAXCONN. Are there are repurcussions to
> doing so? Would it be better to make it a sysctl?
Have you checked if the requester is not satisfied with an increase
of /proc/sys/net/ipv4/tcp_max_syn_backlog? If they "know" from 2.0
that they want a SOMAXCONN increase then that's very likely the case.
In 2.2+ SOMAXCONN only applies to established sockets waiting to get
accept()ed; and when you have 128 established sockets that don't get served
by accept you have a big problem.
SYN-RECV sockets are a completely different thing and they are tuned
by the first sysctl and some other heuristics in 2.4.
You can also turn on syncookies there to handle syn-recv load spikes.
-Andi
Tim Hockin writes:
> We have a request to bump up SOMAXCONN. Are there are repurcussions to
> doing so? Would it be better to make it a sysctl?
There is a very serious repurcussion to allowing this be increased in
any form, people won't fix their code if you just give them this
bandaid.
The new connection backlog controlled by an upper limit of
SOMAXCONN is a "buffer" between the kernel and userspace.
It is _NOT_ a permanent storage area inside the kernel for new
connections. Once people writing these apps start thinking about it
as a buffer (ie. think "temporary"), the thought to increase SOMAXCONN
will occur less often in their minds.
I have never been shown a legitimate argument for increasing
SOMAXCONN.
Later,
David S. Miller
[email protected]
> We have a request to bump up SOMAXCONN. Are there are repurcussions to
> doing so? Would it be better to make it a sysctl?
Its pretty meaningless as a value. People who say they need a larger
SOMAXCONN are as a general rule simply wrong in the Linux case