Un servidor proxy bastante ocupado tiene muchos "sockets SYN para ESCUCHAR caídos".
Aprendí que una causa podría ser un tamaño de trabajo pendiente demasiado pequeño. Pero en ese caso el valor "veces que la cola de escucha de un socket se desbordó" debería ser igual (que no lo es).
Entonces, ¿cuál podría ser la causa de este comportamiento? ¿Quizás un NIC roto?
Tenemos 5 representantes, en 2 de los cuales los dos números no son iguales, por lo que este problema parece estar sucediendo allí.
Aquí el resultado de netstat:
$ netstat -s | grep -i list
238627 times the listen queue of a socket overflowed
8610307 SYNs to LISTEN sockets dropped
los servidores tienen tráfico ipv4 e ipv6, ¿quizás eso ayude?
Respuesta1
Estos contadores, en última instancia, provienen del núcleo y se asignan a los contadores LINUX_MIB_LISTENOVERFLOWSy LINUX_MIB_LISTENDROPS. Puedes ver desde la fuente denet/ipv4/tcp_ipv4.c(tcp_v4_syn_recv_sock)alrededor de la línea #1392 que cuando LINUX_MIB_LISTENOVERFLOWSse incrementa, LINUX_MIB_LISTENDROPStambién se incrementará, pero hay condiciones de salida en las que solo se puede incrementar esta última, por lo que no es un error que no coincidan.
En el mismo archivo puedes ver que hay 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 }
Entonces puede ver que al menos una causa es un SYN a una dirección de transmisión o multidifusión.
Respuesta2
Por lo general, los valores predeterminados de wmem y rmem son 212992 bytes. Aparentemente no es suficiente en un servidor ocupado. Se elevó a 8 MB y el problema desapareció.
sysctl -w net.core.wmem_default=8388608
sysctl -w net.core.rmem_default=8388608