Límite de descriptores de archivo File descriptor limit (ulimit)
ID de la causa so-fd · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Cada conexión necesita un descriptor de archivo (fd, el número que el SO asigna a cada archivo o socket abierto), y el número de fd que puede abrir un proceso es limitado.
Por qué Los jugadores conectados a la vez alcanzan el límite de descriptores de archivo del proceso → Efecto El servidor no puede aceptar conexiones nuevas (Too many open files). También falla la apertura de logs y de conexiones a la BD → En pantalla A partir de un número exacto de jugadores ya nadie puede entrar: el juego no conecta o se queda en carga infinita
Al conectar o tras un mantenimiento, Cuando se junta mucha gente
Responsable
Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Cerrar siempre el socket al terminar una conexión (para evitar fugas de fd); si accept falla con EMFILE (sin fd libres), dejar de aceptar conexiones un momento, o aceptar con un fd de reserva guardado de antemano y cerrar la conexión enseguida (para no gastar CPU procesando una y otra vez el mismo aviso de conexión).
Tareas (Equipo de infraestructura)
Revisar ulimit y la configuración del servicio (LimitNOFILE de systemd), alertar cuando se acerque al límite.
Cifras de referencia
En Linux, si no se configura el servicio aparte, el límite sigue siendo 1,024 en muchos casos. Los servidores de juegos suelen subirlo a decenas o cientos de miles. Windows no tiene un límite predeterminado tan bajo.
En el gráfico
Topa con el límite · Número de fd abiertos del proceso, jugadores conectados a la vez
Dónde mirar
fd-nr (descriptores de archivo abiertos) del proceso del servidor del juego con pidstat -v, el límite de archivos abiertos en /proc/PID/limits y fallos de accept (EMFILE, Too many open files) en los logs del servidor
Se confirma si
El número de fd se aplana en el valor del límite y, desde ese momento, accept falla con EMFILE
Se descarta si
Si el número de fd queda muy por debajo del límite, no es esta causa. Si el kernel descarta las solicitudes de conexión: “Desbordamiento de la cola de conexiones pendientes (backlog)”; si el problema está en el seguimiento de conexiones: “Tabla conntrack del servidor llena”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Las conexiones que no se aceptan se quedan en la cola de conexiones pendientes (backlog) del kernel, así que, según cómo esté escrito el código del servidor, este puede seguir recibiendo avisos de “conexión nueva” y gastar CPU en ellos.