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

💥 Що сталося

8 липня 2026 року на вже зайнятому хості стартував важкий тестовий прогін. Навантаження сягнуло приблизно восьмисот відсотків на восьми ядрах, і вся машина, разом із продакшен-сервісами, зависла. Із самим завданням усе було гаразд. Гаразд не було з тим, що його запустили саме тоді.

Другий інцидент, 14 вересня 2026 року, мав іншу причину з тією самою формою: диск заповнився до дев'яноста семи відсотків, бо резервні копії не ротувалися, і кожне завдання, яке писало в це вікно, робило ситуацію гіршою.

🛑 Правило

Планове завдання не стартує, коли хост перевантажений. Воно фіксує пропуск і завершується успішно, а планувальник запускає його на наступному тику. Дані наздоганяють пізніше, а продакшен продовжує дихати. Наша обгортка перевіряє дві речі перед запуском завдання: одноввилинне навантаження проти ліміту, шість за замовчуванням на цьому восьмиядерному хості, і вільне місце на диску проти мінімуму, два гігабайти за замовчуванням.

Якщо обидві перевірки пройдено, обгортка запускає завдання під ексклюзивним блокуванням, щоб дві копії не могли перекритися, зі зниженим пріоритетом CPU і з пріоритетом диска idle. Ще одне правило обгортки: якщо сам інструмент перевірки диска зламаний, перевірку диска пропускають. Зламаний інструмент не повинен зупиняти всі завдання на хості.

🕵️ Вартовий, який нікого не вбиває

Окремий вартовий запускається кожні п'ять хвилин і записує свій стан у файл. Він виводить м'який і жорсткий пороги навантаження з кількості ядер. Після жорсткої межі він знижує пріоритет відомих пакетних процесів і ніколи нічого не вбиває. 3 листопада 2026, 21:53 UTC він показав 8 ядер, м'який поріг 4,8 і жорсткий поріг 6,8, а остання дія — "ok".

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

📊 Журнал відмов

Обгортка додає рядок щоразу, коли відмовляє завданню. Від 2026-07-30 у журналі 8 415 рядків по 67 різних завданнях, і чотири найчастіші завдання дають 4 938 із них. Найзавантаженіший день — 2026-10-15 з 1 155 відмовами в старті.

Читайте це як сигнал про ємність, а не як збій. Тисячі відмов у старті означають, що хост заповнений саме в ті моменти, коли завдання заплановані, і що розклад треба рознести або роботу перенести на іншу машину. Вони також означають, що запобіжник робить свою справу: кожна відмова — це старт, який міг зашкодити продакшену.

🛠️ Практика: обгорніть свої важкі завдання

1. Перелічіть планові завдання і позначте важкі: тести, бекфіли, оптимізатори, експорти.
2. Напишіть обгортку, яка перевіряє навантаження і вільне місце на диску та тихо завершується з рядком у журналі, коли щось поза межами.
3. У тій самій обгортці додайте ексклюзивне блокування, нижчий пріоритет CPU і пріоритет диска idle.
4. Поставте кожне важке завдання за обгортку. Робіть це по файлах, а не редагуючи спільну таблицю розкладу.
5. Додайте вартового, який фіксує навантаження і знижує пріоритет пакетних процесів, але ніколи їх не вбиває.
6. Переглядайте журнал відмов щотижня. Переносьте або розносьте завдання, яким відмовляють найчастіше.

✅ Перевірте себе

• Запустіть палій CPU, а потім завдання в обгортці. Завданню відмовлено, і в журналі видно показник навантаження.
• Запустіть те саме завдання в обгортці двічі. Друга копія завершується одразу.
• Заповніть диск понад ваш мінімум на тестовому хості. Завдання, які пишуть, отримують відмову.
• Ви можете назвати, якому завданню відмовляли найчастіше минулого тижня.

🚧 Коли це не працює

• Завдання, які мусять виконатися. Завдання, де важливий дедлайн, як-от резервна копія, не повинно відкидатися вічно. Додайте максимальну кількість пропусків.
• Стійке перевантаження. Якщо хост завжди за межею, не запускається нічого. Це означає, що вам потрібно більше ємності, а не нижчий ліміт.
• Пікові сервіси. Короткий пік може відкинути завдання, яке встигло б уміститися. Використовуйте коротке ковзне середнє.
• Пріоритет — це не ізоляція. Завдання з низьким пріоритетом усе одно може займати пам'ять і диск. Ліміти на групу сильніші.
• Тихі пропуски. Якщо ніхто не читає журнал, ви можете втратити завдання на тижні. Налаштуйте оповіщення про завдання, яке не завершилося за добу.

📊 Докази

➡️ Далі

Сплануйте, що робити, коли щось таки зламається, у Пораднику з інцидентів AI для малої команди, і прочитайте Відновлення після невдалого, застряглого або невизначеного прогону.

Джерела

• Порадник з інцидентів AI для малої команди: кроки реагування.
• Відновлення після невдалого, застряглого або невизначеного прогону: відновлення.
• Витрати, бюджети та ліміти: ліміти.
• Доступ агента до shell: розвилки рішень: варіанти доступу до shell.