Um servidor proxy bastante ocupado tem muitos "soquetes SYNs para LISTEN descartados".
Aprendi que uma das causas pode ser o tamanho muito pequeno do backlog. Mas, nesse caso, o valor "vezes que a fila de escuta de um soquete estourou" deve ser igual (o que não é).
Então, o que poderia ser a causa desse comportamento? Talvez um nic quebrado?
Temos 5 proxies, em 2 dos quais os dois números não são iguais, então esse problema parece estar acontecendo aí.
Aqui a saída do netstat:
$ netstat -s | grep -i list
238627 times the listen queue of a socket overflowed
8610307 SYNs to LISTEN sockets dropped
os servidores têm tráfego ipv4 e ipv6, talvez isso ajude?
Responder1
Em última análise, esses contadores vêm do kernel e são mapeados para os contadores LINUX_MIB_LISTENOVERFLOWSe LINUX_MIB_LISTENDROPS. Você pode ver na fonte denet/ipv4/tcp_ipv4.c(tcp_v4_syn_recv_sock)em torno da linha # 1392 que quando LINUX_MIB_LISTENOVERFLOWSfor incrementado, LINUX_MIB_LISTENDROPStambém será incrementado, mas existem condições de saída onde apenas o último pode ser incrementado, portanto não é um bug que eles não correspondam.
No mesmo arquivo você pode ver que há este código:
1291 int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
1292 {
1293 /* Never answer to SYNs send to broadcast or multicast */
1294 if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
1295 goto drop;
1296
1297 return tcp_conn_request(&tcp_request_sock_ops,
1298 &tcp_request_sock_ipv4_ops, sk, skb);
1299
1300 drop:
1301 NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
1302 return 0;
1303 }
Portanto, você pode ver que pelo menos uma causa é um SYN para um endereço de broadcast ou multicast.
Responder2
Normalmente, os padrões wmem e rmem são 212.992 bytes. Aparentemente não é suficiente em um servidor ocupado. Aumentei para 8 MB e o problema desapareceu.
sysctl -w net.core.wmem_default=8388608
sysctl -w net.core.rmem_default=8388608