점검 직후 수만 명이 동시에 접속하면, 커널의 접속 대기열(backlog)이 넘쳐 접속 시도가 버려집니다.
왜 점검 종료와 동시에 게임 서버가 accept로 접속을 처리하는 속도보다 빨리 몰림 → 그러면 커널의 접속 대기열(backlog. 서버 코드가 listen에 준 값과 커널 상한 중 작은 쪽)이 가득 → 화면에서는 접속 시도가 버려지고 재시도가 반복되어 접속 불가·무한 로딩
서버: 코드에서 주는 listen 값 늘리기, 접속을 받는 스레드가 다른 일로 멈추지 않게, 로그인 대기열 시스템. 클라이언트: 재시도 간격 늘리기(무작위로 분산).
인프라팀 할 일
커널 somaxconn 늘리기(서버 코드의 listen 값과 둘 다 올려야 효과), SYN 쿠키 켜 두기, 넘침 횟수 감시(nstat의 TcpExtListenOverflows).
수치 감각
리눅스 커널 상한(somaxconn)은 5.4부터 기본 4,096(그 전 128)이지만, 서버 코드가 listen에 더 작은 값을 주면 그 값이 한도입니다. 리눅스는 대기열이 차면 접속 요청을 오류 없이 조용히 버립니다. 클라이언트 OS가 1초 뒤부터 몇 차례 다시 보내므로, 플레이어에게는 “연결 실패”보다 긴 로딩으로 보입니다. 윈도우 서버는 거절 응답을 돌려보내 클라이언트가 곧바로 “연결 실패”를 봅니다.
그래프에서는
접속·점검 직후 폭증 · 접속 대기열 넘침 수(ListenOverflows), 접속 시도 수
확인할 곳
nstat -az의 TcpExtListenOverflows·TcpExtListenDrops 증가량을 보고, ss -ltn으로 리슨 소켓의 Recv-Q(accept를 기다리는 접속 수)와 Send-Q(backlog 한도)를 비교
ListenOverflows가 그대로면 이 원인이 아님. 연결은 맺어졌는데 로딩이 안 끝나면 “로그인 폭주와 N+1 쿼리”, 정확히 일정 인원에서 막히면 “파일 디스크립터 한도”
확인 수단
인프라 도구로 확인(게임 코드 불필요)
출처
listen(2) — Linux manual pageLinux man-pages listen의 backlog는 somaxconn을 넘으면 조용히 잘림, somaxconn 기본 4,096(5.4부터, 전에는 128), 대기열이 차면 요청을 무시해 클라이언트 재시도에 맡길 수 있음
IP SysctlLinux kernel tcp_syn_retries: 접속 요청(SYN)을 첫 재전송 대기 1초로 여러 번 다시 보냄, tcp_abort_on_overflow 기본 꺼짐(넘쳐도 거절 응답 없음), tcp_syncookies 기본 켜짐