Не запускайте задание: сброс нагрузки для плановых пакетных работ

💥 Что случилось

8 июля 2026 тяжёлый прогон тестов стартовал на уже занятом хосте. Нагрузка дошла примерно до восьмисот процентов на восьми ядрах, и вся машина, включая рабочие сервисы, зависла. С самим заданием всё было в порядке. Неправильным был момент запуска.

Второй инцидент 14 сентября 2026 имел иную причину, но ту же форму: диск дошёл до девяносто семи процентов, потому что бэкапы не ротировались, и каждое задание, писавшее в это окно, ухудшало положение.

🛑 Правило

Плановое задание не стартует при перегрузке хоста. Оно записывает пропуск и завершается успешно, а планировщик запустит его на следующем тике. Данные догонятся позже, а прод продолжит дышать. Наша обёртка перед запуском проверяет две вещи: минутную нагрузку относительно лимита, по умолчанию шесть на этом восьмиядерном хосте, и свободное место на диске относительно минимума, по умолчанию два гигабайта.

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

🕵️ Сторож, который никогда не убивает

Отдельный сторож запускается каждые пять минут и пишет состояние в файл. Он выводит мягкий и жёсткий пороги нагрузки из числа ядер. За жёстким порогом он понижает приоритет известных пакетных процессов и никогда ничего не убивает. На 3 ноября 2026, 21:53 UTC он сообщал 8 ядер, мягкий порог 4,8 и жёсткий 6,8, последнее действие — «ok».

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

📊 Журнал отказов

Обёртка дописывает строку каждый раз, когда отклоняет задание. С 30 июля 2026 в журнале 8 415 строк по 67 разным заданиям, и четыре самых частых задания дают 4 938 из них. Самый загруженный день — 15 октября 2026: 1 155 отклонённых запусков.

Читайте это как сигнал о ёмкости, а не как сбой. Тысячи отклонённых запусков означают, что хост полон в моменты, на которые назначены задания, и расписание нужно разнести или работу перенести на другую машину. Они же значат, что защита работает: каждый из них мог навредить проду.

🛠️ Практика: оберните тяжёлые задания

1. Перечислите плановые задания и отметьте тяжёлые: тесты, бэкфиллы, оптимизаторы, выгрузки.
2. Напишите обёртку, которая проверяет нагрузку и свободный диск и тихо завершается со строкой в журнале, если что-то вне нормы.
3. В той же обёртке добавьте эксклюзивную блокировку, пониженный приоритет процессора и приоритет простоя для диска.
4. Поставьте каждое тяжёлое задание за обёртку. Делайте это по файлам, а не правкой общей таблицы расписания.
5. Добавьте сторож, который записывает нагрузку и понижает приоритет пакетных процессов, но никогда их не убивает.
6. Просматривайте журнал отказов раз в неделю. Переносите или разносите задания, которые отклоняются чаще всего.

✅ Проверьте себя

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

🚧 Когда это не работает

• Задания, которые обязаны выполниться. Задание с важным сроком, например бэкап, нельзя пропускать вечно. Добавьте максимум пропусков.
• Постоянная перегрузка. Если хост всегда выше лимита, не запускается ничего. Это значит, что нужна ёмкость, а не заниженный лимит.
• Скачущие сервисы. Короткий всплеск может отклонить задание, которое бы поместилось. Используйте короткое скользящее среднее.
• Приоритет — не изоляция. Задание с низким приоритетом всё равно может использовать память и диск. Лимиты по группам сильнее.
• Молчаливый пропуск. Если журнал никто не читает, задание можно потерять на недели. Поднимайте тревогу, если задание не выполнялось сутки.

📊 Доказательства

➡️ Дальше

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

Источники

• План реагирования для небольшой команды: шаги реагирования.
• Восстановление после сбойного, зависшего или неопределённого запуска: восстановление.
• Расходы, бюджеты и лимиты: лимиты.
• Развилки доступа агента к shell: варианты доступа к shell.