Фоновый расчёт мешает сервису: когда помогает nice

Ночная обработка отчётов запускается на той же машине, где днём работает сервис. Отчёт нужен, но его завершение на минуту позже допустимо; задержки ответов пользователей — нет. Если обе программы конкурируют за CPU, можно дать фоновой работе меньший приоритет, сохранив ей возможность использовать свободные ресурсы.

Сначала проверить ресурс

nice влияет на планирование CPU обычных задач. Он не ограничивает объём памяти, скорость записи и число создаваемых потоков. Если сервис ждёт перегруженный диск, увеличение nice отчёта может почти ничего не изменить. Перед вмешательством снимите потребление CPU, число активных потоков и задержку сервиса в одинаковом интервале.

ps -p 1234 -o pid,ni,cls,pcpu,etime,cmd
nice -n 10 /usr/local/bin/report --date 2026-11-02
renice -n 10 -p 1234

В первой и третьей строках PID заменяется на процесс фонового расчёта. nice запускает новую команду с изменением приоритета относительно унаследованного значения, renice задаёт значение существующему процессу. Большое положительное nice означает меньший приоритет. Обычный пользователь может понижать приоритет своей задачи; обратное повышение может потребовать дополнительных прав или подходящего лимита. Подробности — в описании приоритетов.

Почему эффект не равен фиксированному проценту

Приоритет определяет относительное распределение процессорного времени при конкуренции. На свободной машине фоновая задача по-прежнему может использовать CPU полностью. Это полезно: ресурсы не простаивают, когда сервису нечего делать. Если нужен жёсткий потолок, исследуйте отдельное ограничение группы, а не подбирайте nice в надежде получить ровно 20% CPU.

У Linux есть дополнительные уровни группировки задач и планирования. Два процесса из разных групп могут делить ресурсы иначе, чем два соседних процесса. В многопоточном приложении проверьте приоритеты потоков: Linux хранит nice на уровне task. Поэтому изменение одного главного потока не следует автоматически считать изменением всего приложения.

Сделать измерение полезным

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

Если задержки улучшились, а отчёт укладывается в окно, закрепите настройку в месте запуска. Для службы systemd можно использовать Nice=10 в секции Service и проверить фактическое значение после нового запуска. Запись команды renice в рабочем чате не заменяет воспроизводимую конфигурацию.

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

Прочитать результат небольшого опыта

Предположим, до изменения фоновой задачи её NI равен 0, отчёт выполняется 60 секунд, а высокий перцентиль задержки сервиса во время отчёта достигает 450 мс. После запуска с nice -n 10 видно NI=10, отчёт завершается за 75 секунд, задержка сервиса — 180 мс. Эти числа иллюстрируют полезный обмен: фоновая работа занимает дольше, интерактивная получает CPU своевременнее. Они не являются результатом испытания конкретной системы.

Если при тех же условиях NI стал 10, а задержки остались 450 мс, настройка применилась, но гипотеза об этой CPU-конкуренции не подтверждена. Следующий шаг — посмотреть, чего ждут потоки сервиса. Так проверка значения настройки отделяется от проверки её пользы.

Продолжить работу с процессами

В программе Linux и Bash для DevOps-инженеров управление процессами соединено с настройкой systemd и диагностикой сервиса. Откройте программу, чтобы отработать полный цикл: определить ресурс, выбрать настройку и подтвердить её эффект наблюдением.

Ещё по теме

• Пустая папка запустила обработку файла *.json: задаём политику glob в Bash
• Фоновая задача упала, скрипт зелёный: собираем статусы wait по PID