A definição de net.core.somaxconn para valores mais altos só é necessária em servidores de alta carga, onde a nova taxa de conexão é tão alta que apenas 128 (50% mais em BSD: 128 backlog + 64 half-open ) ainda não foram aceitos conexões é considerado normal. Ou quando você precisa delegar a definição de "normal" para um aplicativo em si.
Alguns administradores usam alto net.core.somaxconn para ocultar problemas com seus serviços, portanto, do ponto de vista do usuário, ele parecerá um pico de latência em vez de interrupção da conexão / tempo limite (controlado por net.ipv4.tcp_abort_on_overflow no Linux).
listen(2) manual diz - net.core.somaxconn age apenas no limite superior de um aplicativo que é livre para escolher algo menor (geralmente definido na configuração do aplicativo). Embora alguns aplicativos usem apenas listen(fd, -1) , o que significa que o backlog deve ser definido para o valor máximo permitido pelo sistema.
A causa real é uma taxa de processamento lenta (por exemplo, um único servidor de bloqueio encadeado) ou um número insuficiente de encadeamentos / processos de trabalho (por exemplo, software de bloqueio de processo múltiplo / segmentado como apache / tomcat )
PS. Às vezes, é preferível falhar rapidamente e deixar que o balanceador de carga execute sua tarefa (tente novamente) do que fazer com que o usuário espere. Para isso, definimos net.core.somaxconn de qualquer valor e limitamos o backlog do aplicativo a, por exemplo. 10 e defina net.ipv4.tcp_abort_on_overflow para 1.
PPS. Versões antigas do kernel Linux têm um erro desagradável de truncar o valor somaxcon para seus 16 bits mais baixos (ou seja, converter o valor para uint16_t ), então aumentar esse valor para mais de 65535 pode até ser perigoso. Para mais informações, consulte: link
Se você quiser entrar em mais detalhes sobre todos os aspectos internos do backlog no Linux, fique à vontade para ler: Como o backlog TCP funciona no Linux .