Eu finalmente encontrei a configuração que realmente limitava o número de conexões: net.ipv4.netfilter.ip_conntrack_max . Isso foi definido como 11.776 e o que eu configurei é o número de solicitações que posso atender no meu teste antes de ter que esperar tcp_fin_timeout segundos para que mais conexões fiquem disponíveis. A tabela conntrack é o que o kernel usa para rastrear o estado das conexões. Assim, quando estiver cheio, o kernel começa a eliminar pacotes e a imprimi-lo no log:
Jun 2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.
A próxima etapa foi fazer com que o kernel reciclasse todas essas conexões no estado TIME_WAIT em vez de descartar pacotes. Eu poderia fazer isso acontecer ativando tcp_tw_recycle ou aumentando ip_conntrack_max para ser maior que o número de portas locais disponibilizadas para conexões por ip_local_port_range . Eu acho que uma vez que o kernel está fora de portas locais, ele começa a reciclar conexões. Isso usa mais conexões de rastreamento de memória, mas parece ser a melhor solução do que ativar tcp_tw_recycle , já que os documentos implicam que isso é perigoso.
Com essa configuração, posso executar o dia todo ab e nunca ficar sem conexões:
net.ipv4.netfilter.ip_conntrack_max = 32768
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192
net.ipv4.ip_local_port_range = 32768 61000
A configuração tcp_max_orphans não teve nenhum efeito nos meus testes e não sei por quê. Eu acho que seria fechar as conexões em TIME_WAIT state, uma vez que havia 8192 deles, mas isso não faz isso para mim.