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

Libro blanco del lag en juegos › L12 Base de datos

Procesos batch masivos Batch jobs during service

ID de la causa db-batch · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)

Abrir la ficha interactiva con gráficos y simulaciones →

Calcular rankings, enviar correo del juego en masa o limpiar datos antiguos con el servicio en marcha acapara bloqueos y disco.

Por qué Se lanzan tareas masivas en horario de servicio → Efecto Bloqueos de rangos amplios, disco y CPU ocupados → En pantalla Fallos en intercambios y guardados a ciertas horas, cargas lentas

Síntomas
Input lag, Acción perdida / rollback
Factores
Latencia, Detención
A quién afecta
Solo una función, Todo el servidor
Cuándo
A intervalos regulares
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Dividir el trabajo en lotes pequeños y avanzar poco a poco, hacer las agregaciones en una réplica.
Tareas (Equipo de infraestructura)
Ofrecer una réplica para agregaciones, programar los procesos batch en horas tranquilas, vigilar el escalado de bloqueos y las esperas por gap locks.
En el gráfico
Picos periódicos · Latencia de las consultas a la BD, esperas por bloqueo
Dónde mirar
Buscar las consultas largas que se ejecutaban a la hora del lag: en MySQL, el slow query log; en PostgreSQL, query_start y query de pg_stat_activity; y cotejarlas con las métricas de espera por bloqueo de esa hora y con el calendario de procesos batch (cron, programador de eventos de la BD). En SQL Server, registrar el escalado de bloqueos con el evento extendido lock_escalation
Se confirma si
Siempre a la misma hora se ejecutan UPDATE, DELETE o consultas de agregación masivas, y mientras tanto suben a la vez las esperas por bloqueo y la utilización del disco
Se descarta si
Si a esa hora no hay consultas largas, apunta a un checkpoint (db-checkpoint) o a una copia de seguridad del servidor (dk-backup)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
SQL Server convierte los bloqueos de fila en un bloqueo de tabla cuando una sola sentencia retiene más de unos 5,000 (escalado de bloqueos). En ese momento se detienen todas las solicitudes que usan esa tabla. MySQL, con la configuración por defecto, también bloquea los huecos entre filas (gap lock) cuando se modifica con una condición de rango, y eso impide insertar filas nuevas.

Fuentes

  1. Transaction Locking and Row Versioning Guide Microsoft SQL Server
    Si una sentencia retiene 5,000 bloqueos o más en una tabla (o un índice), se produce el escalado de bloqueos; se registra con el evento extendido lock_escalation
  2. InnoDB Locking MySQL
    Con REPEATABLE READ, el nivel de aislamiento por defecto de InnoDB, las búsquedas y los escaneos usan bloqueos next-key, y el gap lock impide insertar filas nuevas en ese hueco
  3. The Slow Query Log MySQL
    Registra las consultas que superan long_query_time con su tiempo de ejecución (Query_time), su tiempo de bloqueo (Lock_time) y las filas leídas
  4. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    pg_stat_activity: la consulta que cada sesión está ejecutando (query) y su hora de inicio (query_start)

Ver también

Misma capa: L12 Base de datos

Causas de otras capas con el mismo síntoma (Input lag)

Ver la ficha interactiva con gráficos y simulaciones