Si todos los hilos de trabajo que procesan tareas quedan atados a trabajos lentos, las solicitudes nuevas esperan indefinidamente.
Por qué Los hilos de trabajo quedan atados esperando respuestas de API externas o de la BD → Efecto No quedan hilos libres para asignar a las solicitudes nuevas → En pantalla Carga infinita en funciones concretas, como el inicio de sesión o la tienda
Cuando se junta mucha gente, Al conectar o tras un mantenimiento
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Poner timeouts a las llamadas lentas, separar pools de hilos por función, pasar a asíncrono.
En el gráfico
Topa con el límite · Hilos del pool y longitud de su cola, tiempo de procesamiento de solicitudes
Dónde mirar
En .NET, número de hilos del pool y longitud de la cola en dotnet-counters monitor (dotnet.thread_pool.thread.count y dotnet.thread_pool.queue.length desde .NET 9; ThreadPool Thread Count y ThreadPool Queue Length en la 8 y anteriores), y dónde esperan los hilos de trabajo con dotnet-stack. En la JVM y en servidores nativos, lo mismo con un volcado de hilos
Se confirma si
El uso de CPU está muy por debajo del 100%, pero el número de hilos crece despacio sin parar o se queda en el tope, la cola se acumula y la mayoría de los workers esperan la respuesta de la misma llamada externa (BD, HTTP)
Se descarta si
Si la cola está vacía y aun así va lento, el lento es el propio destino de las llamadas: apunta a “Fallo en cascada” o a “Dependencia de servicios externos”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Si la recepción de paquetes y la lógica del juego comparten el mismo pool de hilos de trabajo, en cuanto unas pocas tareas lentas ocupan todos los workers, se detiene el procesamiento de paquetes de todo el servidor.
Debug ThreadPool StarvationMicrosoft Si no quedan hilos en el pool y las tareas nuevas esperan, las respuestas se vuelven lentas; la causa es código bloqueante que retiene hilos. En dotnet-counters, si la CPU está muy por debajo del 100% y dotnet.thread_pool.thread.count crece despacio sin parar, es señal de agotamiento (dotnet.thread_pool.queue.length también suele ser grande); con dotnet-stack se ve dónde esperan los hilos
Avoiding insurmountable queue backlogsAWS Concurrencia = tasa de llegada × latencia (ley de Little). Con 100 solicitudes por segundo, si la latencia pasa de 100 ms a 10 segundos, los hilos necesarios pasan de 10 a 1,000 y el pool se agota
Bulkhead PatternMicrosoft Azure Si cada destino de llamadas tiene su propio pool de conexiones e hilos, el fallo de un destino solo bloquea ese pool
.NET runtime metrics.NET dotnet.thread_pool.thread.count (hilos del pool) y dotnet.thread_pool.queue.length (tareas en espera) existen desde .NET 9
Well-known EventCounters in .NETMicrosoft ThreadPool Thread Count (threadpool-thread-count) y ThreadPool Queue Length (threadpool-queue-length) en .NET 8 y anteriores