Приоритеты выполнения процессов [103.6]

Рейтинг: 64.6% · 12 голосов
Полный курс LPIC-1 (экзамены 101-500 и 102-500): архитектура, загрузка, пакеты, команды и текст, ФС и права, шелл-скрипты, пользователи, сервисы, сеть, безопасность. Debian и RHEL.
Ответить
Аватара пользователя
Sergey_Sysadmin
Сообщения: 134
Зарегистрирован: 11 май 2026, 05:31

Приоритеты выполнения процессов [103.6]

Сообщение Sergey_Sysadmin »

Оглавление курса (41)
  1. Введение в LPIC-1 и как устроен путь администратора
  2. Железо, устройства и модули ядра [101.1]
  3. Загрузка системы: от BIOS до systemd [101.2]
  4. systemd, цели и уровни выполнения [101.3]
  5. План разметки диска и swap [102.1]
  6. Загрузчик GRUB 2 [102.2]
  7. Разделяемые библиотеки [102.3]
  8. Управление пакетами в Debian: dpkg и apt [102.4]
  9. Управление пакетами RPM, DNF и Zypper [102.5]
  10. Linux как гость виртуализации [102.6]
  11. Командная строка Bash [103.1]
  12. Обработка текста фильтрами [103.2]
  13. Базовое управление файлами [103.3]
  14. Потоки, конвейеры и перенаправление [103.4]
  15. Процессы: создание, мониторинг, сигналы [103.5]
  16. Приоритеты выполнения процессов [103.6] (вы здесь)
  17. Регулярные выражения [103.7]
  18. Редактор vi и vim [103.8]
  19. Разделы и создание файловых систем [104.1]
  20. Целостность и обслуживание ФС [104.2]
  21. Монтирование файловых систем [104.3]
  22. Урок 21. Права доступа и владение: rwx, chmod, umask и специальные биты
  23. Жёсткие и символические ссылки
  24. FHS и поиск файлов в системе [104.7]
  25. Окружение и кастомизация оболочки [105.1]
  26. Урок 25. Написание простых bash-скриптов [105.2]
  27. Графика, рабочие столы и доступность
  28. Учётные записи пользователей и групп
  29. Автоматизация задач: cron, at, таймеры [107.2]
  30. Локализация и интернационализация [107.3]
  31. Системное время и синхронизация [108.1]
  32. Системное логирование [108.2]
  33. Основы почтового агента (MTA) [108.3]
  34. Печать и CUPS [108.4]
  35. Основы интернет-протоколов [109.1]
  36. Постоянная конфигурация сети [109.2]
  37. Диагностика сети [109.3]
  38. DNS на стороне клиента [109.4]
  39. Задачи администрирования безопасности [110.1]
  40. Настройка безопасности хоста [110.2]
  41. Шифрование данных: SSH и GnuPG [110.3]
Урок 15. Приоритеты выполнения процессов [103.6]

Когда процессов больше, чем ядер, кто-то всегда ждёт. Планировщик ядра решает, кому из готовых к работе процессов отдать CPU прямо сейчас, а кому подождать. Администратор может вмешаться в это решение и сказать: вот эта задача важная, дай ей побольше времени, а вот этот бэкап пусть копается в фоне и не мешает базе данных. В этом уроке разберём, что такое значение nice и приоритет ядра, как запустить процесс с нужным приоритетом, как поменять его на лету через renice и top, и - что важнее - когда это реально помогает, а когда вы просто крутите ручку без эффекта.

Изображение

Как это работает

В Linux есть два разных, но связанных числа. Первое - nice (любезность процесса), диапазон от -20 до 19. Это ваша подсказка планировщику: насколько процесс готов уступить остальным. Значение 19 - максимально вежливый, отдаёт CPU всем подряд. Значение -20 - максимально наглый, требует время в первую очередь. По умолчанию у процесса nice равен 0. Логика в названии: высокий nice значит хороший к соседям, то есть низкий приоритет себе.

Второе число - приоритет ядра, его видно в top как колонка PR. Для обычных задач он жёстко связан с nice формулой PR = 20 + nice. То есть nice 0 даёт PR 20, nice -20 даёт PR 0 (самый высокий), nice 19 даёт PR 39. Это не два независимых рычага - PR просто перевод nice на язык ядра. Отдельно стоят процессы реального времени: у них PR показывается как rt или отрицательное число, и они вытесняют вообще всё обычное. Их nice не трогает.

Теперь главное - что nice делает физически. Современный планировщик (CFS, а с ядра 6.6 его наследник EEVDF) не выдаёт жёстких слотов вроде дай 80 процентов. Он делит процессорное время пропорционально весу, а nice как раз меняет вес. Разница в одну единицу nice - это примерно множитель 1.25 в весе. Поэтому процесс с nice -5 получит ощутимо больше времени, чем сосед с nice 0, но только если они оба реально дерутся за CPU.

И вот ключевой момент, который путают чаще всего. Если CPU простаивает, nice не значит ничего. Один активный процесс получит все 100 процентов хоть с nice 19, хоть с nice -20 - делить-то не с кем. nice влияет только на конкуренцию: он распределяет дефицит, а не создаёт мощность. Если ваша задача тормозит из-за диска или сети, renice её не ускорит вообще.

Понизить свой nice (сделать процесс приоритетнее, то есть значение меньше 0) обычному пользователю нельзя - это требует root. Повысить, наоборот, может кто угодно. Так ядро не даёт юзерам наперегонки выбивать себе приоритет за счёт чужих задач.

Команды и примеры

Запуск с заданным nice - команда nice. Без аргументов она печатает текущее значение, с ключом -n задаёт его перед запуском программы.

Код: Выделить всё

nice                       # покажет текущий nice оболочки, обычно 0
nice -n 10 tar czf b.tgz /var/log   # запустить бэкап вежливо, nice 10
nice -n 19 ./crunch.sh     # фоновый счёт, не мешать никому

# понизить nice (приоритетнее) можно только под root
sudo nice -n -5 ./latency_test
Обратите внимание на синтаксис ключа: nice -n -5 - первый -n это флаг, -5 это значение. Старый стиль nice --5 тоже работает, но читается хуже.

Поменять nice уже работающему процессу - renice. Тут значение задаётся абсолютное (не прибавляется), и нужен PID или другой селектор.

Код: Выделить всё

renice -n 5 -p 12345       # выставить процессу 12345 nice = 5
renice -n 15 -u anna       # всем процессам пользователя anna nice = 15
renice -n -10 -p 12345     # приоритетнее обычного - нужен root
sudo renice -n -10 -p 12345
Селекторы: -p процесс по PID, -u все процессы пользователя, -g по группе процессов. Это удобно, когда надо притушить сразу весь воркер-пул одного юзера.

Через top это делается интерактивно и без запоминания PID. Запускаете top, жмёте клавишу r (renice), вводите PID, затем новое значение nice. В колонках NI вы видите текущий nice, PR - приоритет ядра. По умолчанию список сортируется по %CPU, так что прожорливый процесс сразу наверху.

Код: Выделить всё

top
#  r       -> renice, спросит PID и новое значение nice
#  колонка NI - значение nice, PR - приоритет ядра (20 + NI)
#  q       -> выход
Инструменты одинаковы в Debian, Ubuntu, RHEL и Fedora - это часть util-linux и procps, ставится с базовой системой. Если top кажется бедным, в репозиториях есть htop, где renice вешается на клавишу F7/F8, а процессы видно деревом.

Код: Выделить всё

# Debian 13 / Ubuntu 24.04
sudo apt install htop

# RHEL 10 / Fedora 41+
sudo dnf install htop
Отдельно держите в голове: для задач, которые упираются в диск, а не в CPU, существует ionice - он крутит приоритет ввода-вывода, и для фоновых бэкапов он часто важнее nice.

Частые грабли
  • Крутят nice на простаивающей системе и ждут ускорения. Пока за CPU нет драки, nice не делает ничего. Сначала убедитесь по top, что процесс реально конкурент за процессор.
  • Путают знак: думают, что -20 это медленно. Наоборот, минус значит приоритетнее. Запомните: высокий nice = вежливый = уступает.
  • Пытаются понизить nice без root и получают отказ или молчаливое игнорирование. Отрицательные значения и приоритет реального времени требуют прав.
  • renice по имени процесса. У renice нет селектора по имени - только PID, пользователь или группа. Имя сначала превратите в PID через pgrep.
  • Лечат приоритетом то, что упирается в диск или сеть. Если узкое место - I/O, смотрите в сторону ionice, а не nice.
  • Ставят базе или важному демону жёсткий приоритет реального времени через chrt, не понимая последствий. RT-процесс способен забить ядро так, что система перестанет отвечать. Для веб- и БД-нагрузки почти всегда хватает обычного nice.
Мини-лаба
  • Создайте нагрузку: yes > /dev/null & запомните выведенный PID. Это бесконечный счёт, грузящий одно ядро.
  • Посмотрите его в top: найдите строку yes, отметьте колонки NI и PR (должны быть 0 и 20).
  • Запустите второй такой же: yes > /dev/null & - теперь на одном ядре два конкурента, оба делят CPU примерно поровну.
  • Сделайте один из них вежливым: renice -n 19 -p PERVYJ_PID и снова посмотрите в top, как изменилось распределение %CPU между ними.
  • Через top нажмите r, введите PID второго и верните ему nice 0, понаблюдайте.
  • Попробуйте без sudo выставить renice -n -5 -p любому процессу и прочитайте сообщение об отказе.
  • Уберите за собой: kill оба PID процессов yes.
Контрольные вопросы
  • Какой диапазон у значения nice и какое значение означает самый высокий приоритет?
  • Как связаны колонки NI и PR в выводе top для обычного процесса?
  • Почему изменение nice не ускоряет процесс на полностью свободной системе?
  • Чем отличается синтаксис задания приоритета у nice и у renice?
  • Какие действия с приоритетом доступны обычному пользователю, а какие требуют root и почему?
  • Когда вместо nice стоит подумать про ionice?
👍3 ❤️2 🔥 😄 🤔1
Аватара пользователя
lloydss
Сообщения: 2
Зарегистрирован: 20 май 2026, 06:32

Re: Приоритеты выполнения процессов [103.6]

Сообщение lloydss »

Получается если у меня сервер почти всегда недогружен, то renice на крон-бэкап вообще ничего не даст? Только когда нагрузка близка к 100% по всем ядрам начнёт работать?
👍 ❤️1 🔥 😄 🤔
Аватара пользователя
clickhousewizard
Сообщения: 1
Зарегистрирован: 20 май 2026, 15:28

Re: Приоритеты выполнения процессов [103.6]

Сообщение clickhousewizard »

Запустил два yes, сделал одному nice 19 - и правда в top один забрал ~75% а вежливый ~25%, а не пополам. Наглядно, спасибо.
👍 ❤️ 🔥 😄 🤔
Ответить
← Предыдущая глава
Процессы: создание, мониторинг, сигналы [103.5]
Следующая глава →
Регулярные выражения [103.7]

Все главы курса «LPIC-1: администратор Linux (101 + 102)»

Поделиться темой: ✈ Telegram VK
  • Похожие темы

Вернуться в «LPIC-1: администратор Linux»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость