nice и renice: как понизить приоритет процесса и не мешать остальным

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

В Linux значения лежат в диапазоне от -20 до 19, и процессы обычно стартуют с нулём. Отрицательные значения повышают приоритет, положительные понижают. Для macOS поведение близкое, но пределы и тонкости стоит уточнить в man nice и man renice на вашей системе.

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

Для нового процесса используется утилита nice. Она запускает указанную команду с изменённым значением. Синтаксис: nice -n 10 команда аргументы. Число после -n прибавляется к текущему значению. Если ключ не указан, nice по умолчанию прибавляет 10, но явная запись понятнее.

Типичные примеры, где это уместно: сборка проекта на рабочем компьютере, архивирование большого каталога, перекодирование видео, запуск индексатора. Пример: nice -n 15 tar -czf архив.tar.gz каталог. Имена файлов подставьте свои.

Что нужно помнить:

• Повысить приоритет, то есть указать отрицательное значение, обычно может только администратор, например через sudo.
• Значение наследуется дочерними процессами, поэтому команда, запущенная из nice-сеанса, будет работать с тем же значением.
• Для работы с диском есть отдельная утилита ionice в Linux, она влияет на приоритет ввода-вывода, а не процессора. В macOS её нет.
• Если процесс нагружает диск, а не процессор, один nice положение не исправит.

Если программа уже запущена и мешает, переключать её не нужно: приоритет можно изменить на ходу утилитой renice. Нужен номер процесса, его находят через pgrep или ps aux. Пример в Linux: renice -n 10 -p 1234, где 1234 вы заменяете на реальный PID.

Тут есть различие, о котором стоит знать. В справке renice из Linux (util-linux) указанное число задаёт новое значение nice, а в справке BSD-версии, которая используется в macOS, у ключа -n смысл приращения к текущему значению. Если процесс стартовал с нуля, результат совпадёт, но в остальных случаях он будет разным. Документация вашей системы (man renice) отвечает на этот вопрос точно. Надёжный подход: выполнить команду, а затем проверить результат, не полагаясь на память.

Для безопасной тренировки запустите безобидный процесс: sleep 302 &, затем renice -n 5 -p $! (переменная $! хранит номер последнего фонового процесса) и проверьте ps -o pid,ni,comm -p $!. Завершить тестовый sleep можно командой kill с этим же номером. Не применяйте renice к системным и чужим процессам ради опыта.

Проверка выполняется командой ps -o pid,ni,comm -p 1234. Столбец ni показывает текущее значение nice. В Linux в top этот параметр виден в столбце NI, рядом с PR, где отображается приоритет планировщика, и числа в этих двух столбцах не совпадают по смыслу. Набор столбцов top в macOS другой.

Обычный пользователь может изменять только свои процессы и, как правило, только в сторону увеличения nice. Вернуть значение обратно к меньшему без прав администратора обычно нельзя (в Linux это зависит ещё и от лимита RLIMIT_NICE), и это защита от того, чтобы один пользователь забирал ресурсы.

Допустим, на ноутбуке запущена долгая сборка, из-за которой браузер и редактор подтормаживают. Алгоритм действий простой.

1. Найдите процесс: pgrep -l имя_сборщика. Запишите PID главного процесса.
2. Понизьте приоритет: renice -n 10 -p PID. Для сборки с множеством дочерних процессов повторите команду для детей или запустите сборку заново под nice.
3. Проверьте: ps -o pid,ni,comm -p PID. Значение должно измениться.
4. Откройте top и убедитесь, что интерфейс отзывается лучше, а сборка продолжает идти.

В следующий раз запускайте сборку сразу как nice -n 10 команда. Этот способ проще, чем исправлять потом.

Если не помогло, значит, узкое место не в процессоре. Проверьте память командой vmstat 1 и диск командой iostat. Нехватка памяти с активной подкачкой или перегруженный накопитель делают систему вялой независимо от значения nice. А если нагрузка исходит от службы, управляйте её приоритетом через настройки самой службы, а не вручную через renice, иначе после перезапуска изменение пропадёт.

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

Второе: «nice защищает от нехватки памяти». Он влияет только на процессорное время, оперативную память и диск не регулирует. Для памяти существуют лимиты контрольных групп, которыми пользуются службы и контейнеры.

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

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

Для оценки общей нагрузки заглядывайте в uptime и load average: рост очереди процессов подсказывает, когда приоритеты вообще имеют смысл.

Подведём практические выводы без лишних подробностей.

• Nice влияет на очерёдность процессора, а не на память и диск.
• Для нового процесса используйте nice -n, для запущенного renice.
• Обычный пользователь, как правило, только увеличивает значение, уменьшает администратор.
• Результат проверяйте командой ps -o pid,ni,comm -p PID.
• Для ввода-вывода в Linux есть ionice, он работает отдельно.

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