Тяжёлые пакетные задания Batch jobs during service

ID причины db-batch · Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Инфраструктура БД

Открыть карточку в основной версии с иллюстрациями и экспериментами →

Если подсчёт рейтингов, массовую рассылку почты или чистку старых данных запускать во время работы сервиса, они занимают блокировки и диск.

Почему Массовая операция запускается в рабочие часы сервиса → Следствие Блокировки на широкий диапазон, заняты диск и CPU → На экране В определённые часы срываются обмены и сохранения, медленно идёт загрузка

Симптомы: Задержка ввода, Съеденные действия / роллбэк
Факторы: Задержка, Остановка
У кого: Только одна функция, Весь сервер
Когда: С постоянным периодом
Ответственные: Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Инфраструктура БД
Команда разработки: задачи: Дробить работу на мелкие порции, агрегацию выполнять на реплике.
Команда инфраструктуры: задачи: Выделить реплику для агрегации, планировать пакетные задания на часы низкой нагрузки, следить за эскалацией блокировок и ожиданиями gap-блокировок.
На графике: Всплески с постоянным периодом · задержка запросов к БД, ожидания блокировок
Где смотреть: Найти долгие запросы, которые выполнялись в момент лагов. Для MySQL смотреть slow query log, для PostgreSQL query_start и query в pg_stat_activity и сверять с метриками ожидания блокировок за то же время и с расписанием пакетных заданий (cron, планировщик событий БД). В SQL Server записывать эскалацию блокировок расширенным событием lock_escalation
Подтверждает: Каждый раз в одно и то же время идут массовые UPDATE, DELETE или агрегирующие запросы, и в это время вместе растут ожидания блокировок и утилизация диска
Опровергает: Если в это время долгих запросов нет, это контрольная точка (db-checkpoint) или бэкап сервера (dk-backup)
Чем проверить: Инструменты инфраструктуры (игровой код не нужен)
Подробнее: SQL Server, когда один оператор захватывает больше примерно 5 000 блокировок строк, заменяет их блокировкой таблицы (эскалация блокировок). В этот момент останавливаются все запросы к этой таблице. MySQL в настройках по умолчанию при изменении по условию диапазона тоже блокирует промежутки между строками (gap-блокировка) и не даёт добавлять новые строки.

Источники

Transaction Locking and Row Versioning Guide Microsoft SQL Server
Если один оператор захватывает 5 000 и больше блокировок в одной таблице (или индексе), происходит эскалация блокировок, её записывает расширенное событие lock_escalation
InnoDB Locking MySQL
При уровне изоляции InnoDB по умолчанию REPEATABLE READ поиск и сканирование используют next-key-блокировки, и gap-блокировка не даёт добавлять новые строки в этот промежуток
The Slow Query Log MySQL
Записывает запросы дольше long_query_time вместе с временем выполнения (Query_time), временем блокировки (Lock_time) и числом прочитанных строк
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: для каждой сессии выполняемый сейчас запрос (query) и время его начала (query_start)

Смотрите также

Тот же слой: L12 База данных

Причины с тем же симптомом (Задержка ввода) на других слоях

Нагрузка на рендеринг при большом скоплении игроков L1 Процесс игрового клиента
Узкое место: обработка пакетов в главном потоке L1 Процесс игрового клиента
V-Sync и очередь рендеринга L1 Процесс игрового клиента
Энергосбережение и тепловой троттлинг L2 ОС и устройство клиента
Другие приложения на устройстве забирают пропускную способность L2 ОС и устройство клиента
Задержка дисплея, устройств ввода и генерации кадров L2 ОС и устройство клиента
Перегруженный радиоканал Wi-Fi L3 Домашняя сеть
Bufferbloat (очередь в роутере) L3 Домашняя сеть

Карточка в основной версии с иллюстрациями и экспериментами