Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I got into an argument on the net.core.somaxconn parameter: I was told that it will not make any difference if we change the default 128.

I believed this might be enough proof:

"If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it is silently truncated to that value" http://linux.die.net/man/2/listen

but it's not.

Does anyone know a method to testify this with two machines, sitting on a Gbit network? The best would be against MySQL, LVS, apache2 ( 2.2 ), memcached.

share|improve this question
up vote 7 down vote accepted

Setting net.core.somaxconn to values higher than default is only needed on very-very loaded servers where connection rate is so high/bursty that having 128 (even more in BSD's: 128 backlog + 64 half-open) concurrent connections is not considered abnormal. Or when you need to delegate definition of what is normal to people running applications on that server.

Some administrators use high net.core.somaxconn to hide problems with their services, so from user's point of view process it'll look like a latency spike instead of connection interrupted/timeout (controlled by net.ipv4.tcp_abort_on_overflow in Linux).

Real cause is either slow processing rate (e.g. a single threaded blocking server) or insufficient number of worker threads/processes (e.g. multi- process/threaded blocking software like apache)

PS. Also as listen(2) manual says - net.core.somaxconn acts only upper boundary for an application which is free to choose something smaller (usually set in app's config). Though some apps just use listen(fd, -1) which means set backlog to the max value allowed by system.

PPS. Sometimes it's preferable to fail fast and let the load-balancer to do it's job than to make user wait - for that purpose we set net.core.somaxconn any value, and limit application backlog to e.g. 10 and set net.ipv4.tcp_abort_on_overflow to 1.

PPPS. Old versions of Linux kernel have nasty bug of truncating somaxcon value to it's 16 lower bits (i.e. casting value to uint16_t), so raising that value to more than 65535 can even be dangerous. For more information see: http://patchwork.ozlabs.org/patch/255460/

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.