Помогите с cgroups

Никто не пользовался cgroups?

У меня тоже такая же проблема, возможно это баг в libcgroup, т.к. всё вроде по инструкциям делается. А вот через sudo cgexec без проблем работает.

Возможно, через systemd или вручную оно заработает, но я не проверял.

от судо работает - но правила не работают. т.е. загрузка процессора на 100%

Да, действительно. Видимо cpu.shares считаются не так, а может вообще не работают. Ограничить память у меня тоже как-то не вышло.

cgroups != libcgroup

а руками слабо сделать?

sudo -- mkdir /sys/fs/cgroups/cpu/foo
sudo -- echo 10 > /sys/fs/cgroups/cpu/foo/cpu.share
stress ; sudo -- echo $? > /sys/fs/cgroups/cpu/foo/tasks

не слабо.

пробуй отписывайся о результате. Только учти, что я мог пару очепяток допустить, cpu контроллер должен быть примонтирован в /sys/fs/cgroups/cpu заранее, я не знаю как с этим в убунтах.

1. Во-первых, нужно обозначить cpuset.mems и cpus

Для одного ядра:

echo "0" > /sys/fs/cgroup/cpu/ipeacocks/cpuset.mems
echo "0" > /sys/fs/cgroup/cpu/ipeacocks/cpuset.cpus

2. Во-вторых нужно запускать два stress, чтобы увидеть результат в top. Один stress там где cpu.shares=1024, а другой там, где cpu.shares=100

Но сначала рекомендую разобраться как оно вообще в принципе работает.

Ну вот. или может я не так понял:

root@homepc:~# echo 4981 > /sys/fs/cgroup/cpu/foo/tasks
root@homepc:~# ps aux | grep stress
root      4980  0.0  0.0   7312   428 pts/2    S+   13:17   0:00 stress --cpu 1
root      4981 99.9  0.0   7312   100 pts/2    R+   13:17   3:38 stress --cpu 1
root      5152  0.0  0.0  18068   952 pts/3    S+   13:21   0:00 grep --color=auto stress
root@homepc:~# 

линк на документцию, говорящую, что пунт 1 нужен, пожалуйста.

примонтирован же:

root@homepc:~# ls /sys/fs/cgroup/cpu
cgroup.clone_children  cgroup.procs       cpu.cfs_quota_us  cpu.rt_runtime_us  cpu.stat  ipeacocks          release_agent
cgroup.event_control   cpu.cfs_period_us  cpu.rt_period_us  cpu.shares         foo       notify_on_release  tasks
root@homepc:~# 

echo «0» > /sys/fs/cgroup/cpu/ipeacocks/cpuset.mems

оно на самом деле уже имеет значения 1024.

там значение, которое унаследовано из родительской категории.

С пустыми значениями в этих переменных ничего работать не будет. И симптомы будут 1-в-1 такими же как у ТС. Это факт, можешь проверить.

Вот сслыки, где люди страдают:

http://comments.gmane.org/gmane.linux.kernel.cgroups/6513

http://forum.russianfedora.ru/viewtopic.php?f=16&t=5029&start=0

А вот что находилось в этих переменных у ТС заранее неясно. И значение 1024 выглядит очень удивительно...

Ты не путаешь, действительно 1024 ?

это немного другой случай, другая задача и другой контроллер.

по ссылкам люди хотели cpuset ограничить, для этого выставить:

To start a new job that is to be contained within a cpuset, the steps are:

 1) mkdir /sys/fs/cgroup/cpuset
 2) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
 3) Create the new cpuset by doing mkdir's and write's (or echo's) in
    the /sys/fs/cgroup/cpuset virtual file system.
 4) Start a task that will be the "founding father" of the new job.
 5) Attach that task to the new cpuset by writing its pid to the
    /sys/fs/cgroup/cpuset tasks file for that cpuset.
 6) fork, exec or clone the job tasks from this founding father task.

For example, the following sequence of commands will setup a cpuset
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
and then start a subshell 'sh' in that cpuset:

  mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
  cd /sys/fs/cgroup/cpuset
  mkdir Charlie
  cd Charlie
  /bin/echo 2-3 > cpuset.cpus
  /bin/echo 1 > cpuset.mems
  /bin/echo $$ > tasks
  sh
  # The subshell 'sh' is now running in cpuset Charlie
  # The next line should display '/Charlie'
  cat /proc/self/cpuset

все-таки путаешь. я про cpuset говорил

да неважно какая задача и контроллер. Суть в том, что ты не сможешь вписать pid в таск, если не выставлены cpuset.cpus и cpuset.mems

это откровенная ложь.

мдя... ну смотри:

# cd /cgroup
# mkdir test
# cd test
# echo "" > cpuset.cpus
# echo "" > cpuset.mems
# echo $$ > tasks
bash: echo: write error: No space left on device
# echo 0 > cpuset.cpus
# echo 0 > cpuset.mems
# echo $$ > tasks

facepalm... а с какого черта у тебя контроллеры все вместе? небось федора?

То, что я написал, справедливо, как минимум, в Ubuntu10 и RHEL6 b и Centos6

то, что ты написал справедливо там, где контроллеры собраны вместе и там где ты вручную/или какой кривой прогой записал «» в cpuset.cpus (по умолчанию там 0-кол-во процов), а в toplevel этот файл readonly. Данная проблема никак не относится к проблеме ТС.

ага, все-таки кое-где справедливо. уже лучше. про разделенные контроллеры мне, увы, негде посмотреть. поэтому жду пруфов

попробую cgroup на центоси используя официальный мануал. может это убунту-специфик проблема.

на раздельных:

thinkpad cpuset # cd /sys/fs/cgroup/cpu/
thinkpad cpu # mkdir 2
thinkpad cpu # ls 2/
cgroup.clone_children  cgroup.event_control  cgroup.procs  cpu.shares  notify_on_release  tasks
thinkpad cpu # echo 30016 > 2/tasks 

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