Использование CPUQuota в systemd
Я пытаюсь поместить жесткий предел в использование ЦП для команды dd. Я создал следующий файл единицы
[Unit]
Description=Virtual Distributed Ethernet
[Service]
ExecStart=/usr/bin/ddcommand
CPUQuota=10%
[Install]
WantedBy=multi-user.target
которые называют следующий простой сценарий
#!/bin/sh
dd if=/dev/zero of=/dev/null bs=1024k
Поскольку я видел в этом руководстве, использовании ЦП для моего dd сервис не должен превышать 10%. Но когда я работаю system-cgtop управляйте, чтобы использование составило приблизительно 70-75%.
Какие-либо идеи того, что я делаю неправильно и как я могу зафиксировать его?
Когда я выполняюсь systemctl show dd Я получаю следующие результаты относительно ЦП
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=100ms
LimitCPU=18446744073709551615
Хорошее
Ваше решение является правильным и должно быть на самом деле достаточно перспективным; используя systemd для управления настройками группы служб, например CPUQota.
[Unit]
Description=Virtual Distributed Ethernet
[Service]
ExecStart=/usr/bin/ddcommand
CPUQuota=10%
[Install]
WantedBy=multi-user.target
Смотрите man systemd. resource controll для более полезных настроек cgroup в systemd.
The Bad
Есть два предостережения, на которые я (и, возможно, несколько других) наткнулся. Эти предостережения действительно трудно отследить, так как, кажется, не так много легко найти информации об этом, что является основной причиной данного ответа.
Caveat 1:
Настройка CPUQuota доступна только начиная с systemd 213, см. https://github.com/systemd/systemd/blob/master/NEWS
* The CFS CPU quota cgroup attribute is now exposed for
services. The new CPUQuota= switch has been added for this
which takes a percentage value. Setting this will have the
result that a service may never get more CPU time than the
specified percentage, even if the machine is otherwise idle.
Это, например, проблема с Debian Jessie, которая поставляется только с systemd 208. В качестве альтернативы можно вручную сконфигурировать cpu.cfs_period_us и cpu.cfs_quota_us, используя cgcreate и cgset из пакета cgroup-bin, например, с помощью cgcreate и cgset.
sudo cgcreate -g cpu:/cpulimited
sudo cgset -r cpu.cfs_period_us=50000 cpulimited
sudo cgset -r cpu.cfs_quota_us=10000 cpulimited
sudo cgexec -g cpu:cpulimited /usr/bin/ddcommand
Caveat 2
Для того чтобы настройки cpu.cfs_period_us и cpu.cfs_quota_us были доступны, ядро должно быть скомпилировано с помощью конфигурационного флага CONFIG_CFS_BANDWIDTH. К сожалению, ядро 3.16.x для Debian Jessie по умолчанию не скомпилировано с этим флагом, см. этот запрос feature request.
Это будет доступно в Debian Stretch. Также можно использовать ядро из jessie-backports, в котором должен быть включен этот флаг.
Надеюсь, этот ответ поможет нескольким людям с такой же проблемой, как и я....
PS: Легкий способ проверить, работает ли CPUquota в вашей среде:
$ apt-get install stress
$ systemd-run -p CPUQuota=25% --slice=stress -- stress -c <your cpu count>
и посмотреть с помощью top или htop, загрузка должна быть распределена (равномерно) по всем cpus/ядрам, суммируя до 25%. В качестве альтернативного инструмента можно использовать ограничение cpu, которое должно быть доступно в большинстве дистрибутивов, например,
$ apt-get install cpulimit
$ cpulimit -l 10 -P /usr/bin/ddcommand
Он работает, посылая SIGSTOP и SIGCONT на приложенную команду для приостановки и возобновления работы.
AFAIK было трудно управлять несколькими отдельными/автономными процессами одновременно, вроде сгруппировать их вместе , но для этого может быть также найдено решение...
.У меня была аналогичная задача по ограничению использования ЦП, но вариант использования был совершенно другим. Это должно было нагрузить набор регрессионных тестов на локальном компьютере, чтобы смоделировать то, что он проходит на загруженном сервере CI (что вызывает недетерминированное или нестабильное поведение тестов). Это работало как шарм, в отличие от cpulimit и stress.
systemd-run -p CPUQuota="25%" --scope --uid=$USER --gid=$USER -- pytest ...
--scope заставил его наследовать текущую среду оболочки и вывод команды на стандартный вывод, как обычно. Единственным отличием в выводе было Работающая область как модуль run-uN.scope в качестве первой строки.
Для запуска требуются привилегии суперпользователя, и у меня есть приглашение GUI от pkttyagent. Вводить пароль каждый раз может быть обременительно, если вам нужно запускать команду несколько раз подряд, например, для настройки CPUQuota, поэтому добавьте к вышеуказанной команде префикс sudo -E env PATH =$PATH упростит задачу.
На всякий случай, потому что есть сообщения, что это не работало/не поддерживалось в старых версиях.
$ uname -r
4.15.0-51-generic
$ systemd --version | head -n 1
systemd 229