На довольно загруженном прокси-сервере наблюдается большое количество «сброшенных сокетов SYN для LISTEN».
Я узнал, что одной из причин может быть слишком малый размер backlog. Но в этом случае значение "числа раз, когда очередь прослушивания сокета переполнена" должно быть равным (но это не так).
Так что же может быть причиной такого поведения? Может быть, сломанная сетка?
У нас есть 5 прокси-серверов, в 2 из которых эти два числа не равны, поэтому эта проблема, по-видимому, возникает именно там.
Вот вывод netstat:
$ netstat -s | grep -i list
238627 times the listen queue of a socket overflowed
8610307 SYNs to LISTEN sockets dropped
на серверах есть трафик ipv4 и ipv6, может это поможет?
решение1
Эти счетчики в конечном итоге исходят из ядра и отображаются в счетчиках LINUX_MIB_LISTENOVERFLOWSи LINUX_MIB_LISTENDROPS. Вы можете видеть из источникаnet/ipv4/tcp_ipv4.c(tcp_v4_syn_recv_sock)около строки #1392, которая при LINUX_MIB_LISTENOVERFLOWSувеличении LINUX_MIB_LISTENDROPSтакже будет увеличена, но существуют условия выхода, при которых может быть увеличено только последнее, так что их несоответствие не является ошибкой.
В этом же файле вы можете увидеть такой код:
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 }
Таким образом, вы можете видеть, что по крайней мере одной из причин является SYN-запрос на широковещательный или многоадресный адрес.
решение2
Обычно wmem и rmem по умолчанию 212992 байта. Видимо недостаточно на загруженном сервере. Увеличил до 8 МБ и проблема исчезла.
sysctl -w net.core.wmem_default=8388608
sysctl -w net.core.rmem_default=8388608