게임 렉 백서 › L8 소켓과 프로토콜
SO_REUSEPORT 분배 쏠림 SO_REUSEPORT imbalance, stuck worker
원인 ID sk-reuseport · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
그림과 실험이 있는 원본 카드로 열기 →
같은 포트를 여러 프로세스가 나눠 받으면, 커널은 접속마다 주소 해시로 담당 프로세스를 정해 두고 바꾸지 않습니다. 담당 프로세스 하나가 멈추면 거기에 배정된 사람만 기다립니다.
왜 게이트웨이·로그인 서버가 SO_REUSEPORT로 프로세스 여러 개를 띄움 → 그러면 한 프로세스가 GC·과부하로 멈춰도 거기에 배정된 새 접속과 UDP 패킷은 다른 프로세스로 넘어가지 않음 → 화면에서는 일부 사람만 접속 불가·멈춤. 프로세스 수가 바뀌는 재시작 때는 일부 UDP 세션이 끊김
증상 접속 불가·무한 로딩 , 멈춤 , 접속 끊김
요인 정체, 손실
누가 겪나 나만, 서버 전체
언제 접속·점검 직후, 가끔 무작위로
담당 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일 받는 스레드는 절대 멈추지 않게, 재시작 때 세션을 넘겨받는 절차 구현.
인프라팀 할 일 프로세스별 접속 대기열 감시(ss의 Recv-Q), 배포 때 프로세스 수를 바꾸면 세션 넘겨받기 절차를 따르게.
그래프에서는 일부만 높음 · 리슨 소켓별 접속 대기열(Recv-Q)
확인할 곳 ss -ltnp로 같은 포트의 리슨 소켓마다 Recv-Q(accept를 기다리는 접속 수)와 담당 프로세스를 보고, 프로세스별 처리량을 비교 이러면 맞음 같은 포트의 여러 소켓 중 하나만 Recv-Q가 계속 쌓이고 그 프로세스가 멈춰 있거나 처리량이 0에 가까움 이러면 아님 모든 소켓의 Recv-Q가 고르게 쌓이면 전체 과부하(“접속 대기열(backlog) 넘침”) 확인 수단 인프라 도구로 확인(게임 코드 불필요)
출처 socket(7) — Linux manual page Linux man-pages SO_REUSEPORT로 여러 소켓이 같은 주소에 bind해 TCP 접속과 UDP 패킷을 나눠 받음 net/core/sock_reuseport.c (Linux v6.12) Linux kernel BPF 프로그램이 없으면 패킷 해시 값을 그룹의 소켓 수에 맞춰 나눠 담당 소켓을 고름 Why does one NGINX worker take all the load? Cloudflare SO_REUSEPORT는 간단한 해시로 워커마다 큐를 나누므로, 워커 하나가 막히면 그 큐에 쌓인 접속이 모두 멈춤 net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트
함께 보면 좋은 원인
같은 층: L8 소켓과 프로토콜
같은 증상(접속 불가·무한 로딩)의 다른 층 원인
그림과 실험이 있는 원본 카드 보기