Использование и понимание параметров планирования systemd в контексте рабочего стола


14

В служебных файлах systemd можно установить следующие параметры, относящиеся к планированию (на systemd.execстранице руководства исправьте меня, если я ошибаюсь):

Nice Устанавливает уровень Nice по умолчанию (приоритет планирования) для выполняемых процессов. Принимает целое число от -20 (самый высокий приоритет) до 19 (самый низкий приоритет). Смотрите setpriority (2) для деталей.

Какой знакомый хороший уровень. Кажется, что его эффект несколько «подорван» из-за функции «автогруппы» в последних ядрах Linux. Таким образом, параметры, приведенные ниже, могут быть тем, что я действительно хочу установить, чтобы процессы работали хорошо для моего рабочего стола.

CPUSchedulingPolicy Устанавливает политику планирования ЦП для выполняемых процессов. Принимает одно из другого, пакетное, простаивающее, fifo или рр. Смотрите sched_setscheduler (2) для подробностей.

CPUSchedulingPriority Устанавливает приоритет планирования ЦП для выполняемых процессов. Доступный диапазон приоритетов зависит от выбранной политики планирования ЦП (см. Выше). Для политик планирования в реальном времени может использоваться целое число от 1 (самый низкий приоритет) до 99 (самый высокий приоритет). Смотрите sched_setscheduler (2) для подробностей.

CPUSchedulingResetOnFork Принимает логический аргумент. Если это правда, повышенные приоритеты и политики планирования ЦП будут сброшены, когда выполненные процессы разветвляются, и, следовательно, не могут проникнуть в дочерние процессы. Смотрите sched_setscheduler (2) для подробностей. По умолчанию false.

Я понимаю последний вариант. Из объяснения первых двух я понял, что могу выбрать политику планирования, а затем, учитывая эту политику, приоритет. Мне не совсем ясно, что я должен выбрать для каких задач. Например, безопасно ли выбирать «простаивающий» для задач резервного копирования (относительно интенсивно использующий процессор, потому что дедупликация), или другой вариант лучше подходит?

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

Рядом с планированием ЦП есть планирование ввода-вывода. Я думаю, это соответствует ionice(поправьте меня, если я ошибаюсь).

IOSchedulingClass Устанавливает класс планирования ввода / вывода для выполняемых процессов. Принимает целое число от 0 до 3 или одну из строк none, в режиме реального времени, с максимальным усилием или в режиме ожидания. Смотрите ioprio_set (2) для подробностей.

IOSchedulingPriority Устанавливает приоритет планирования ввода-вывода для выполняемых процессов. Принимает целое число от 0 (самый высокий приоритет) до 7 (самый низкий приоритет). Доступные приоритеты зависят от выбранного класса планирования ввода / вывода (см. Выше). Смотрите ioprio_set (2) для подробностей.

Здесь мы видим ту же структуру, что и при планировании процессора. Я ищу такую ​​же информацию.

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


2
Какую проблему с производительностью вы пытаетесь решить? Что-то работает слишком медленно или слишком долго для вас? Я использую Ubuntu 16.04 с systemd в качестве рабочего стола, резервные копии выполняются в фоновом режиме и не имеют проблем с производительностью, связанных с относительным приоритетом.
Марк Стосберг

@MarkStosberg Вопрос был вызван заданиями фонового резервного копирования, в то время как вычислительные задачи переднего плана в двухъядерной системе делали интерфейс не отвечающим. Затем я добавил опцию Nice в скрипт резервного копирования и в то же время увидел другие опции. Они могут иметь отношение к той проблеме, вызванной резервным копированием, или другим проблемам, с которыми я столкнусь в будущем. Поэтому я хотел бы узнать больше об этих других вариантах, не связанных с конкретной проблемой.
equaeghe

Каждый бит документации ссылается на страницу руководства, где вы можете найти больше документации, если вам интересно. Помогает ли чтение справочных man-страниц для ioprio_set (2) и sched_setscheduler (2) ответить на ваши вопросы?
Марк Стосберг

@MarkStosberg Нет, как указано в моем вопросе. Страницы справочника неплохие, но они не обязательно помогают мне решить, что делать (регулировка хороших значений остается безопасной / правильной вещью в наше время?). Ответы опытных пользователей этих опций, которые могут привести конкретные примеры и знать влияние автогруппы в таких конкретных случаях, - это то, на что я надеюсь.
Equaeghe

Я просто наткнулся на эти директивы в почти одинаковом контексте (фоновые резервные копии вызывают задержки). Я обнаружил, что man sched (7) имеет гораздо более полное описание двух других страниц руководства. (Также упоминается, когда niceприменяется значение).
Wisperwind

Ответы:


5

CPUScheduling {Политика | Приоритет}

Ссылка говорит вам, что CPUSchedulingPriorityдолжны быть установлены только для fifoили rr("в режиме реального времени") задач. Вы не хотите принудительно планировать услуги в режиме реального времени.

CPUSchedulingPolicy=other по умолчанию.

Это оставляет batchи idle. Разница между ними актуальна только в том случае, если у вас есть несколько задач с приоритетом простоя, потребляющих процессор одновременно. Теоретически batchдает более высокую пропускную способность (в обмен на более длительные задержки). Но это не большая победа, поэтому в данном случае это не очень актуально.

idleбуквально голодает, если что-то еще хочет процессор. Приоритет ЦП несколько менее значим, чем раньше, для старых систем UNIX с одним ядром. Я был бы счастлив, начиная с niceхорошего уровня 10 или 14, прежде чем прибегать к помощи idle. Смотрите следующий раздел.

Однако большинство настольных компьютеров в большинстве случаев простаивают. И когда у вас есть процессор, который может предотвратить фоновую задачу, обычно он использует только один из ваших процессоров. Имея это в виду, я не чувствовал бы себя слишком рискованным, используя idleобычный рабочий стол или ноутбук. Если только он не оснащен процессором Atom / Celeron / ARM мощностью около 15 Вт или ниже ; тогда я хотел бы посмотреть на вещи немного более тщательно.

Хороший уровень "подорван" функцией ядра "autogroup"?

Да.

Автогруппировка немного странная. Автору systemdне понравилась эвристика даже для десктопов. Если вы хотите проверить отключение автоматической группировки, вы можете установить sysctl kernel.sched_autogroup_enabled в 0. Я думаю, что лучше всего протестировать, установив sysctl в постоянной конфигурации и перезагрузившись, чтобы убедиться, что вы избавились от всех автогрупп.

Тогда вы сможете без проблем получать хорошие уровни для своих услуг. По крайней мере, в текущих версиях systemd - см. Следующий раздел.

Например, хороший уровень 10 уменьшит вес каждого потока в планировщике ЦП Linux, примерно до 10%. Хороший уровень 14 ниже 5%. (Ссылка: полная формула )

Приложение: является ли хороший уровень "подорванным" системными cgroups?

Текущий DefaultCPUAccounting= параметр по умолчанию отключен, если он не может быть включен без включения управления ЦП для каждой услуги. Так должно быть хорошо. Вы можете проверить это в вашей текущей документации:man systemd-system.conf

Имейте в виду, что управление ЦП для каждой службы также будет включено, когда любая служба устанавливает CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares.

Следующий фрагмент блога устарел (но все еще онлайн). С тех пор поведение по умолчанию изменилось, и справочная документация была соответствующим образом обновлена.

По умолчанию, если в ядре включен контроллер cpu, systemd создаст группу cgroup для каждого сервиса при запуске. Без какой-либо дальнейшей настройки это уже имеет один приятный эффект: в системе systemd каждая системная служба получает равное количество ресурсов ЦП, независимо от того, сколько процессов она состоит. Или другими словами: на вашем веб-сервере MySQL получит примерно столько же процессорных ресурсов, что и Apache, даже если последний состоит из 1000 процессов CGI-скрипта, но первый состоит только из нескольких рабочих задач. (Это поведение можно отключить, см. DefaultControllers = в /etc/systemd/system.conf.)

Помимо этого по умолчанию можно явно настроить общие ресурсы ЦП, которые служба получает с параметром CPUShares =. Значение по умолчанию - 1024. Если вы увеличите это число, вы назначите для ЦП больше ЦП, чем неизмененного на 1024, а если уменьшите, то меньше.

http://0pointer.de/blog/projects/resources.html


-3

Классический совет по настройке - «Не оптимизируй, эталон».

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

Современные настольные компьютеры часто работают очень быстро, без каких-либо настроек.


3
Извините, но это не ответ на вопрос. Все дело в том, что испытать что-либо трудно, если человек не понимает эффекта. И этот вопрос был вызван (но не о!) Проблемами с производительностью современного рабочего стола.
Equaeghe

1
Всего несколько минут, чтобы попробовать любой из вариантов. Если у вас есть базовый тест и цель по производительности, вы можете легко проверить, перемещает ли выбранный вами вариант в нужном вам направлении.
Марк Стосберг

@equaeghe, случайные ручки, не зная, что они делают, тоже не решат проблему.
vonbrand

Обширный совет, но не ответ. Это скорее комментарий. Иногда интуитивное чувство «это слишком медленно» достаточно для того, чтобы побудить к действию. Например , используя systemd-analyzeс blameи plotя был в состоянии сократить время загрузки на старом RPi более чем на минуту. Конечно, когда дело доходит до анализа проблемы, необходимо проводить измерения вместо того, чтобы преждевременно начинать «оптимизацию».
0xC0000022L
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.