По заявлению одного из разработчиков из компании Red Hat добиться эффекта существенного повышения отзывчивости десктоп-систем в условиях большой фоновой нагрузки можно через использование cgroup без дополнительных патчей Linux-ядра (https://www.opennet.ru/opennews/art.shtml?num=28671). Более того [[http://lkml.org/lkml/2010/11/16/392 утверждается]] что cgroup-метод работает даже лучше патча с привязкой групп планирования к TTY.Метод проверен на Linux-ядре 2.6.32.
В /etc/rc.local добавляем:
mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
В ~/.bashrc:if [ "$PS1" ] ; then
mkdir -m 0700 /dev/cgroup/cpu/user/$$
echo $$ > /dev/cgroup/cpu/user/$$/tasks
fi
URL: https://www.opennet.ru/openforum/vsluhforumID3/72547.html#208 http://lkml.org/lkml/2010/11/16/330
Обсуждается: https://www.opennet.ru/tips/info/2478.shtml
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mount: неизвестный тип файловой системы 'cgroup'
Самосборное или древнее ядро? =)
кто-нибудь может объяснить как оно работает?
дает всем право переводить процессы между группами, на каждую сессию шела создает новую группу.
> на каждую сессию шела создает новую группу.Фигу! На каждый процесс с форками из шелла создаёт новую группу.
То есть процесс и его форки будут в одной группе, а fork + exec уже в другой.
> дает всем право переводить процессы между группами,Мне кажется или это не прикольно, когда кто угодно может контейнеры перефигаривать?!
Дык, Торвальдц тому товрищу так и написал, что мол vulnerable кастылек твой парниша!!!
Есть такая вещь, как libcg. Она умеет это делать без ручных манипуляций...
В Fedora есть пакет libcgroup со скриптами в /etc/init.d, которые делают что-то похожее.
только непонятно нужно ли ещё добавлять что-то в ~/.bashrc или достаточно скриптов из libcgroup?
> В Fedora есть пакет libcgroup со скриптами в /etc/init.d, которые делают что-то
> похожее.Насколько я сужу по моей ф14 то тама это по дефаульту выключено и вообще вроде это вся борода тама для lxc ... ( который юзается через libvirtd, жаль что еще virt-manager до поддержки lxc не допилили :) ( тама это токо в роадмапе) )
>>~/.bashrcтак это только для баш субпроцессов работает чтоли?
Да. Но идея, думаю, понятна, расширить не проблема. В частности - добавить соответствующие строки во врапперы для "тяжелого" софта. А так - говорят, в systemd будет позитрее механику управления группами.
Надо еще пару действий добавить для автоматического удаления групп, в которых больше нет процессов:создать /usr/local/sbin/cgroup_clean
--cut--
#!/bin/shrmdir /dev/cgroup/$1
--cut--в rc.local добавить:
--cut--
echo "1" > /dev/cgroup/cpu/user/notify_on_release
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent
--cut--
Ошибся (у меня расположение другое). Если монтируется в /dev/cgroup/cpu, то в /usr/local/sbin/cgroup_clean, соответственно, и кладёмrmdir /dev/cgroup/cpu/$1
Кто-нибудь заметил повышение отзывчивости с использованием cgroup?
Да.
На Федоре 14 make -j40, Файрфокс работает гладко, окна двигаются с незначительными застряганиями, даже не верится, что процессор на 80-100% два ядра загружены.Но! Без нагрузки заметны застрягания при работе с окнами в KDE-4. Иногда система не отзывается до 20 секунд. При перемещении окон, при скроле в консолях наблюдаются рывки, что вызывает дискомфорт.
-------------На SUSE сказало, что неизвестная файловая система cgroup (перекомпилировать ядро не стал). Ну и естественно make -j40 полностью парализовал работу.
А если попробовать консольке из которой будут зваться "тяжелые" процессы nice поднять?
При чем тут nice, я попробовал данный метод и ответил, ниже написал поправку и все.
> При чем тут nice, я попробовал данный метод и ответил, ниже написал
> поправку и все.Мне интересно поведение Вашей системы в том же тесте в сравнении с nice, так как сам не пробовал. Ничего другого своим вопросом не хотел сказать.
Ok. Проверю.
Ну вот: собираем inkscape-0.48.0Включаем cgroup
# make -j40
Все красиво ютубе без рывков и застряганий, файрфокс при скролинге немного равками идет. Время сборки 7 минут, около 10 секунд отнесем на "люфт".
Отключаем cgroup
# make clean
# reboot
# nice --adjustment=19 make -j40
Сиcтема ведет себя, так, как будто вовсе никакой компиляции нет.
Время сборки 6 минут и пару секунд.Пусть даже была погрешность в 1 минуту, то и тогда, помойму, нет смысла в cgroup.
# uname -sro
> Linux 2.6.35.6-48.fc14.x86_64 GNU/Linux
Спасибо. Вы подтвердили моё предположение, что cgroup один из многих элементов влияния на шедулер Linux'а для небольшого количества пользователей, которым влом (или пока не умеют) использовать nice и подобное.
Имеет смысл включать cgroup в предустановленных системах. Например в нетбуках.
> Спасибо. Вы подтвердили моё предположение, что cgroup один из многих элементов влияния
> на шедулер Linux'а для небольшого количества пользователей, которым влом (или пока
> не умеют) использовать nice и подобное.
> Имеет смысл включать cgroup в предустановленных системах. Например в нетбуках.cgroups могут ограничить гораздо больше, чем только процессорное время... То есть игры с cgroups сейчас в самом начале, а вот из найса уже ничего не выжать
на какой сусе? у меня 11.2 и все заработало...
OpenSUSE 11.3
2.6.34.7-0.5-desktop
> OpenSUSE 11.3
> 2.6.34.7-0.5-desktopблин, а я ее себе на новую машину поставил ((
>> OpenSUSE 11.3
>> 2.6.34.7-0.5-desktop
> блин, а я ее себе на новую машину поставил ((Ну и что? Система хорошая, практически все работает. А за ядром не угнаться, либо сам пересобирай.
Десктопное ядро там без cgroups. Если оно вам надо ставьте ядро -default.
*** Монтировать нужно в /sys/fs/cgroup ***
*** Это избавит от застряганий и рывков ***в rc.local пишем:
mount -t cgroup cgroup /sys/fs/cgroup -o cpu
mkdir -m 0777 /sys/fs/cgroup/userecho "1" > /sys/fs/cgroup/user/notify_on_release
echo "/usr/local/sbin/cgroup_clean" > /sys/fs/cgroup/release_agent
---------------------в ~/bashrc пишем:
if [ "$PS1" ] ; then
mkdir -m 0700 /sys/fs/cgroup/user/$$
echo $$ > /sys/fs/cgroup/user/$$/tasks
fi
---------------------в /usr/local/sbin/cgroup_clean пишем:
#!/bin/sh
rmdir /sys/fs/cgroup/$1
----------------------Работает без проблем. При монтировании в /dev/ у меня на Fedora 14, после интенсивной нагрузки система дергалась, а при монтировании в /sys/fs/ все OK!
Возможно.. На самом деле, рекомендацию монтировать в /dev/cgroup я взял из документации ядра (Documentation/cgroups/cgroups.txt), там показано использование именно /dev/cgroup. Но с sys вполне работает.
Да это пофигу куда монтировать. Это ж VFS.Хотя, самым оптимальным будет каталог в корне, из одной буквы,
то есть mount -t cgroup cgroup /a -o cpu.Угадайте почему? :)
> Да это пофигу куда монтировать. Это ж VFS.
> Хотя, самым оптимальным будет каталог в корне, из одной буквы,
> то есть mount -t cgroup cgroup /a -o cpu.
> Угадайте почему? :)Возможно, пока в эту суть не вникал.
>> Да это пофигу куда монтировать. Это ж VFS.
>> Хотя, самым оптимальным будет каталог в корне, из одной буквы,
>> то есть mount -t cgroup cgroup /a -o cpu.
>> Угадайте почему? :)
> Возможно, пока в эту суть не вникал.строка для open и подобных короче :)
open("/a", ....) или
open("/dev/cgroup/cpu/user/", ....)нанасекунды решают всё :)
>>> Да это пофигу куда монтировать. Это ж VFS.
>>> Хотя, самым оптимальным будет каталог в корне, из одной буквы,
>>> то есть mount -t cgroup cgroup /a -o cpu.
>>> Угадайте почему? :)
>> Возможно, пока в эту суть не вникал.
> строка для open и подобных короче :)
> open("/a", ....) или
> open("/dev/cgroup/cpu/user/", ....)
> нанасекунды решают всё :)Заинтриговал. Сейчас попробую :)
Смонтировал в /0/u
Собираю inkscape
Вроде немного плавнее скролинг в файрфоксе.
Время сборки 00:08:46 :(
> Смонтировал в /0/u
> Собираю inkscape
> Вроде немного плавнее скролинг в файрфоксе.
> Время сборки 00:08:46 :(Блин, я ж пошутил, там действительно разница в пару микросекунд. :)
Зато:
без прибамбасов make -j40 --- 00:06:26 и никакого кино
c nice --adjustment=19 make -j40 --- 00:08:14 с кино, картинками и гладкой работойКонечно -j40, это неоптимально для скорости компиляции и с меншим значением толку будет больше, но эммитацию загруженности мы получили и nice оказался лучше.
Осталось потестить патч к ядру :)
м. б. как-то так:# yum -y install libcgroup libcgroup-pam
#echo "vlad cpu users/vlad/" >> /etc/cgrules.conf
# cat >> /etc/cgconfig.conf << EOF
group users/vlad {
perm {
task {
uid = vlad;
gid = vlad;
}
admin {
uid = root;
gid = vlad;
}
}
cpu {
cpu.shares = 2048;
notify_on_release =1;
}
}
EOF# echo "session optional pam_cgroup.so" >> /etc/pam.d/su
# chkconfig cgconfig on
# chkconfig cgred on
# service cgconfig start
# servive cgreg start
> # echo "session optional pam_cgroup.so" >> /etc/pam.d/suпочему в su?
в смысле?
> в смысле?А тупо, каким образом модуль в su поможет пользователю?
Оно не грузится при логоне, открытии новой сессии...
Или я что-то не допонял, хотелось бы допонять, так как этот вариант мне больше импонирует нежели чем "ручной".
это был пример использования pam-модуля.
в данном случаи идея в том, чтобы использовать те же правила для пользователя, если он выполняет нечто через su
> это был пример использования pam-модуля.
> в данном случаи идея в том, чтобы использовать те же правила для
> пользователя, если он выполняет нечто через suНу я думал предполагалась альтернатива шапке, кстати у меня оно как то не заработало, разбираться не стал, из шапки работает как нужно.
До кучи нарылась проблема, толи wine толи NV libGL к такому оказались не готовы... эххх.
на fedora 14 работает, проверял.
про "пример использования pam-модуля" имелись в виду именно изменения в /etc/pam.d/su
остальное - настройки libcgroup, точнее - cgconfig и cgreg
У меня также получилось, но вот вопрос: как работает cpu.shares = 512 ?, я запустил от пользователя burnMMX - но всеравно в top я вижу что 99% процессора использует burnMMX.
Как лимитировать процессор?
меж тем, появился второй вариант патчаhttp://groups.google.com/group/linux.kernel/msg/4346cbca04f9...
4-й вариант
http://groups.google.com/group/linux.kernel/browse_frm/threa...