한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

게임 렉 백서 › 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) 넘침”)
확인 수단
인프라 도구로 확인(게임 코드 불필요)

출처

  1. socket(7) — Linux manual page Linux man-pages
    SO_REUSEPORT로 여러 소켓이 같은 주소에 bind해 TCP 접속과 UDP 패킷을 나눠 받음
  2. net/core/sock_reuseport.c (Linux v6.12) Linux kernel
    BPF 프로그램이 없으면 패킷 해시 값을 그룹의 소켓 수에 맞춰 나눠 담당 소켓을 고름
  3. Why does one NGINX worker take all the load? Cloudflare
    SO_REUSEPORT는 간단한 해시로 워커마다 큐를 나누므로, 워커 하나가 막히면 그 큐에 쌓인 접속이 모두 멈춤
  4. net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
    ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트

함께 보면 좋은 원인

같은 층: L8 소켓과 프로토콜

같은 증상(접속 불가·무한 로딩)의 다른 층 원인

그림과 실험이 있는 원본 카드 보기