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

Libro blanco del lag en juegos › L8 Sockets y protocolos

Reparto desigual con SO_REUSEPORT SO_REUSEPORT imbalance, stuck worker

ID de la causa sk-reuseport · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)

Abrir la ficha interactiva con gráficos y simulaciones →

Cuando varios procesos reciben en el mismo puerto, el kernel asigna cada conexión a un proceso según un hash de la dirección y no cambia esa asignación. Si ese proceso se detiene, solo esperan los jugadores asignados a él.

Por qué El gateway o el servidor de login levanta varios procesos con SO_REUSEPORT → Efecto Aunque un proceso se detenga por GC o sobrecarga, las conexiones nuevas y los paquetes UDP asignados a él no pasan a otros procesos → En pantalla Solo algunos jugadores no consiguen conectar o sufren congelamientos. En los reinicios que cambian el número de procesos, se cortan algunas sesiones UDP

Síntomas
No conecta / carga infinita, Congelamiento, Desconexión
Factores
Detención, Pérdida de paquetes
A quién afecta
Solo yo, Todo el servidor
Cuándo
Al conectar o tras un mantenimiento, De vez en cuando, al azar
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Evitar a toda costa que el hilo que recibe se detenga, implementar un procedimiento para traspasar las sesiones en los reinicios.
Tareas (Equipo de infraestructura)
Vigilar la cola de conexiones pendientes de cada proceso (Recv-Q de ss), exigir el procedimiento de traspaso de sesiones cuando un despliegue cambie el número de procesos.
En el gráfico
Alto solo en algunos · Cola de conexiones pendientes (Recv-Q) por socket de escucha
Dónde mirar
Recv-Q (conexiones esperando accept) y proceso responsable de cada socket de escucha del mismo puerto con ss -ltnp; comparar el volumen que procesa cada proceso
Se confirma si
De los varios sockets del mismo puerto, solo uno acumula Recv-Q sin parar, y su proceso está detenido o no procesa casi nada
Se descarta si
Si el Recv-Q se acumula por igual en todos los sockets, es una sobrecarga general (“Desbordamiento de la cola de conexiones pendientes (backlog)”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)

Fuentes

  1. socket(7) — Linux manual page Linux man-pages
    Con SO_REUSEPORT, varios sockets hacen bind a la misma dirección y se reparten las conexiones TCP y los paquetes UDP
  2. net/core/sock_reuseport.c (Linux v6.12) Linux kernel
    Sin un programa BPF, el socket responsable se elige repartiendo el valor de hash del paquete según el número de sockets del grupo
  3. Why does one NGINX worker take all the load? Cloudflare
    SO_REUSEPORT reparte las colas entre los workers con un hash simple, así que si un worker se bloquea, se detienen todas las conexiones acumuladas en su cola
  4. net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
    Valores Recv-Q y Send-Q de ss: en un socket de escucha, conexiones esperando accept y límite del backlog; en un socket conectado, bytes que la aplicación aún no ha leído y bytes enviados que no han recibido ACK

Ver también

Misma capa: L8 Sockets y protocolos

Causas de otras capas con el mismo síntoma (No conecta / carga infinita)

Ver la ficha interactiva con gráficos y simulaciones