Ночные пакетные задачи против дневных клиентов: кто кому мешает

MAATRIX

Генерация ночных отчётов, синхронизация с внешними системами, полный бэкап базы — всё это спланировано на «тихие часы», когда пользователей почти нет. План работает ровно до первого раза, когда пакетная задача не укладывается в отведённое окно и продолжает грузить диск и процессор ровно тогда, когда сервер уже нужен живым клиентам. Дальше — что конкретно ломается при таком столкновении, как посчитать окно с реальным запасом, а не впритык, и какими средствами ограничить фоновую задачу так, чтобы её опоздание не превращалось в инцидент.

Где именно сталкиваются ночная задача и дневной трафик

«Мешают друг другу» — слишком общая формулировка, чтобы с ней что-то делать. На практике конфликт всегда идёт по одному из нескольких конкретных ресурсов, и симптомы для каждого свои.

Диск. Генерация отчёта читает большие объёмы из базы, бэкап пишет архив на том же томе, где лежат рабочие данные — оба процесса упираются в одну очередь ввода-вывода. Пока трафика нет, длинные последовательные операции идут на полной скорости. Как только утром стартуют короткие случайные чтения и записи пользователей, они встают в ту же очередь позади уже идущих крупных операций. Результат: сайт «подтормаживает», а htop показывает свободные ядра CPU, потому что узкое место не в процессоре.

CPU. Агрегация большого объёма данных, шифрование или сжатие бэкапа, пересчёт индексов — всё это может занять ядро целиком на минуты. На сервере с запасом ядер это растворяется в общей нагрузке, но на бюджетном тарифе с 1-2 vCPU тяжёлая фоновая задача способна ощутимо просесть отклик у обычных запросов, которые делят с ней те же ядра.

Память. Пакетная обработка часто собирает промежуточный результат в оперативной памяти — экспорт большой выборки, построение отчёта целиком перед записью на диск. Если задача выедает память, которую обычно использует кэш файловой системы, кэш начинает вытесняться, и даже посторонние для этой задачи операции чтения с диска замедляются.

Блокировки и соединения в базе данных. Длинная транзакция экспорта может держать блокировку на таблице или строках, которые в этот момент нужны обычным запросам. В отличие от конкуренции за CPU или диск, где трафик просто «подождёт своей очереди», блокировка в базе может привести к прямым ошибкам записи или таймаутам. Отдельная головная боль — пул соединений: если у фоновой задачи открыто много подключений, к утру может не остаться свободных слотов для приложения.

Прежде чем настраивать любые ограничения, определите, в какой именно ресурс упирается конкретная задача — иначе легко потратить время на ionice, когда реальная проблема в блокировках базы, которые ionice никак не решает.

Что происходит, когда задача случайно затягивается

Смоделируем сценарий. Ночная синхронизация с внешним API обычно занимает 40 минут и стартует в 3:00 — с запасом до утреннего трафика, который начинает расти примерно к 7:00. Однажды внешний API отвечает медленнее обычного, часть запросов приходится повторять. Задача растягивается на четыре часа и заканчивается в 7:00 вместо 3:40 — ровно когда начинает расти дневной трафик.

Что при этом происходит по нарастающей:

• Планировщик не знает, что задача ещё не закончилась. Cron не проверяет состояние предыдущего запуска — если следующий запуск той же или смежной задачи стоит в 6:00, он стартует поверх ещё не завершившейся, и на диск с CPU давят уже два процесса, каждый работает медленнее, чем поодиночке.
• Утренний трафик застаёт сервер уже занятым. Первые пользователи дня получают не «чистую» систему, а систему, которая всё ещё дорабатывает вчерашнюю ночную нагрузку поверх сегодняшней новой — оба потока конкурируют за ресурсы одновременно, а не последовательно, как было задумано.
• Алерты срабатывают в неудачное время. Мониторинг реагирует на рост нагрузки уже посреди рабочего утра, когда на инцидент смотрят реальные пользователи, а не в 3 часа ночи, когда его можно было бы спокойно разобрать без давления времени.
• Ответственный узнаёт о проблеме последним. Если задача не мониторится отдельно, первым сигналом часто становится жалоба на «медленный сайт по утрам», а не алерт о самой задаче — расследование начинается с симптома, а не с причины.

Затягивание редко бывает разовой случайностью: если объём данных, который обрабатывает задача, растёт вместе с бизнесом, трение с утренним трафиком будет повторяться всё чаще, пока не станет постоянным состоянием. О том, как посчитать запас до систематического исчерпания окна, — в статье про бэкап, который перестал влезать в ночное окно; та же логика переносится на отчёты и синхронизацию.

Как спланировать окно с реальным запасом

Первая и самая частая ошибка — рассчитывать окно впритык к типичной длительности задачи. Если синхронизация обычно занимает 40 минут, а окно тишины длится с 2:00 до 7:00, ставить старт на 6:00 «с запасом в час» — это не запас, а гарантия столкновения при первом же аномальном запуске.

Рабочий порядок расчёта окна для конкретной задачи:

1. Соберите историю длительности за несколько недель, а не полагайтесь на «обычно занимает N минут» из памяти. Обёртка вокруг задачи, которая пишет время старта и длительность в лог или CSV, даёт материал для анализа тренда, а не догадки.
2. Возьмите не среднюю, а максимальную зафиксированную длительность как точку отсчёта — средняя скрывает как раз те аномальные запуски, которые приводят к столкновению с трафиком.
3. Заложите множитель поверх максимума, а не фиксированную добавку в минутах. Ориентир, который стоит проверить на своих данных: ×1.5–2 от зафиксированного максимума — так остаётся запас не только на «немного медленнее», но и на сценарий вроде деградации внешнего API из примера выше.
4. Зафиксируйте, во сколько реально начинает расти дневной трафик, а не ориентируйтесь на условное «день начинается в 9:00» — рост у многих сервисов стартует раньше из-за интеграций партнёров и ранних пользователей. Методика поиска этой границы, включая часовые пояса аудитории, разобрана в статье как выбрать окно для работ и не попасть на пик трафика — она про работы с даунтаймом, но методика та же.
5. Сравните запас по времени с запасом по трафику. Если задача заканчивается в 6:30, а трафик заметно растёт уже с 6:15 — формального «окна» не осталось, хотя на бумаге оно выглядит достаточным.
6. Пересчитывайте регулярно, а не один раз при настройке — окно, безопасное полгода назад, может незаметно сузиться без явного инцидента.

Если даже с запасом задача не укладывается в окно — это сигнал не «раздвинуть окно», а поменять саму задачу: перейти с полной синхронизации на инкрементальную, разбить отчёт на несколько меньших с разным временем запуска, или вынести тяжёлую обработку на отдельный сервер.

Жёсткий потолок по времени: не полагаться только на расчёт

Даже аккуратный расчёт окна не гарантирует, что задача не выйдет за его границы — расчёт снижает вероятность, но не отменяет её. Вторая линия защиты — принудительный потолок по времени, который останавливает задачу при выходе за разумный предел вместо того, чтобы позволить ей ползти в утро бесконтрольно.

Для задачи из cron — обернуть команду в timeout:

0 3 * * * timeout --signal=TERM --kill-after=5m 3h /opt/scripts/nightly_sync.sh >> /var/log/nightly_sync.log 2>&1

Здесь 3h — жёсткий потолок длительности, --signal=TERM даёт скрипту шанс завершиться корректно (закрыть файлы, снять блокировку), а --kill-after=5m — подстраховка: если процесс не отреагировал за пять минут, timeout добивает его через SIGKILL.

Для задач под systemd тот же потолок задаётся декларативно в юните — надёжнее, чем полагаться на то, что скрипт сам вызовет timeout:

# /etc/systemd/system/nightly-report.service
[Unit]
Description=Nightly report generation

[Service]
Type=oneshot
ExecStart=/opt/scripts/generate_report.sh
TimeoutStartSec=0
RuntimeMaxSec=10800

RuntimeMaxSec=10800 (3 часа) останавливает юнит, если он не уложился в этот срок, независимо от того, что происходит внутри скрипта. TimeoutStartSec=0 важен отдельно: по умолчанию systemd может считать сам запуск (ExecStart) зависшим и убить его по своему таймауту старта, если тот меньше времени, которое реально нужно задаче — эту настройку стоит явно отключить или увеличить для длительных пакетных задач.

Важная оговорка: жёсткий потолок безопасен только для задач, умеющих корректно прерываться на середине. Для скрипта, который копирует файлы, SIGTERM — в худшем случае неполный результат, который можно перезапустить. А для длинной транзакции в базе резкое прерывание может оставить её в подвешенном состоянии или потребовать отката — дополнительная нагрузка именно на границе с трафиком. Для таких задач правильнее проектировать контрольные точки: разбить обработку на пакеты с фиксацией промежуточного результата, чтобы остановка теряла максимум один пакет, а не всю работу.

Отдельно полезен мягкий сигнал раньше жёсткого потолка — предупреждение в мониторинг, если задача работает дольше типичной длительности, но ещё не дошла до RuntimeMaxSec. Это даёт шанс среагировать до принудительного прерывания.

Изоляция ресурсов: лимиты CPU и IO для фоновых задач

Расчёт окна и жёсткий потолок ограничивают время, но не саму интенсивность давления на ресурсы. Третья линия защиты — изоляция: даже продолжая работать во время утреннего трафика, задача не должна иметь возможность забрать себе диск или процессор целиком.

Для диска базовый инструмент — ionice с классом idle, при котором фоновый процесс получает доступ к диску только тогда, когда его не забирает никто другой. Подробный разбор классов приоритета, того, почему ionice реально работает не на любом I/O-планировщике, и как это сочетать с nice для CPU-части той же задачи, — в статье приоритет ввода-вывода и почему ночной бэкап душит сайт. Главное отличие для сценария затягивания: если задача завершится вовремя, класс idle почти не заметен — диск ночью и так свободен. Но именно когда задача случайно ползёт в утро, этот класс автоматически отдаёт приоритет живому трафику, ничего не пересчитывая вручную.

Более надёжный уровень изоляции — не приоритет отдельного процесса, а жёсткий лимит на уровне cgroups v2, который работает даже если задача состоит из нескольких дочерних процессов. Для systemd-юнита это задаётся прямо в секции [Service]:

[Service]
ExecStart=/opt/scripts/generate_report.sh
CPUQuota=50%
IOWeight=50
MemoryHigh=2G

CPUQuota=50% ограничивает потребление CPU задачей половиной одного ядра независимо от того, сколько ядер простаивает — это физический потолок, а не приоритет. IOWeight=50 задаёт относительный вес при конкуренции за диск в диапазоне 1-10000 (по умолчанию — 100): задача получит меньшую долю пропускной способности, но не будет заблокирована полностью, в отличие от класса idle. MemoryHigh=2G — мягкий потолок по памяти: при превышении ядро начинает вытеснять страницы процесса, но не даёт ему вытеснить из памяти файловый кэш, важный для трафика.

Конкретные цифры — иллюстрация синтаксиса, а не рекомендованные значения: лимит зависит от числа ядер и памяти на конкретном сервере, а также от того, насколько критично время выполнения задачи — слишком жёсткий CPUQuota может растянуть отчёт настолько, что он перестанет укладываться в окно, и изоляция начнёт противоречить расчёту из предыдущего раздела. Подбирать значения стоит итеративно: консервативный лимит, замер фактической длительности, затем корректировка.

Для задач, которые упираются не в CPU или диск, а в базу данных, изоляция на уровне ОС бессильна — нужны механизмы СУБД: ограничение размера пакета вместо одной гигантской транзакции, statement_timeout как последний рубеж, и, если доступно, выполнение тяжёлых выборок на реплике для чтения, а не на основной базе.

Когда фоновых задач несколько и они мешают друг другу

Реальный сервер редко запускает одну пакетную задачу за ночь — обычно это бэкап, синхронизация с внешними сервисами и генерация отчётов, каждая со своим расписанием, добавленным в разное время разными людьми. Расписания почти никогда не координируются осознанно — каждая задача ставится на «удобное» круглое время, и через несколько месяцев несколько тяжёлых задач оказываются собраны в одном интервале, конкурируя за ресурсы ещё до столкновения с дневным трафиком. Как считать реальный предел сервера по суммарной нагрузке в пиковую минуту и разводить расписания через flock или защиту от наложения в systemd timers — в статье тысяча cron-задач: где начинается наложение.

Применительно к сценарию «ночь против утра» добавляются два практических правила поверх общей защиты от наложения:

• Выстраивайте задачи в очередь по приоритету, а не запускайте параллельно. Если бэкап и синхронизация стартуют одновременно, они конкурируют за диск ещё до того, как у обеих останется время добраться до утра. Последовательный запуск снижает пиковую нагрузку и делает суммарную длительность цепочки предсказуемой.
• Ставьте самую рискованную по длительности задачу первой, а не последней. Если синхронизация с внешним API — самая непредсказуемая (зависит от чужого сервиса), запуск её первой означает, что даже при затягивании остальные стартуют позже расчётного времени, но по расписанию, а не накладываются случайно. Непредсказуемая задача последней в цепочке означает, что любое её опоздание автоматически становится опозданием всей цепочки к трафику.

Для видимости всей цепочки полезна одна метрика на дашборде: время завершения последней ночной задачи по логу, сопоставленное с моментом начала заметного роста запросов. Если разрыв между ними стабильно сокращается неделя за неделей — это ранний сигнал, который стоит поймать до первого реального столкновения.

Частые вопросы