매우 바쁜 프록시 서버에는 "LISTEN 소켓이 삭제된 SYN"이 많이 있습니다.
한 가지 원인은 백로그 크기가 너무 작을 수 있다는 것을 알게 되었습니다. 그러나 이 경우 "소켓의 청취 큐가 오버플로된 횟수" 값은 동일해야 합니다(그렇지 않습니다).
그렇다면 이러한 행동의 원인은 무엇일까요? 어쩌면 깨진 NIC일까요?
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)LINUX_MIB_LISTENOVERFLOWS라인 #1392 주변에는 가 증가할 때 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바이트입니다. 바쁜 서버에서는 충분하지 않은 것 같습니다. 8MB로 올렸더니 문제가 사라졌습니다.
sysctl -w net.core.wmem_default=8388608
sysctl -w net.core.rmem_default=8388608