Cgroups (Control Groups) - обеспечивают механизм для агрегирования множества задач и их будущих потомков в иерархические группы с определенным поведением. Так начинается документация посвященная cgroups поставляемая с ядром Linux. Собственно это и есть достаточно ёмкое описание технологии. Но конечно же его не достаточно.
Небольшое отступление, необходимо привести конфигурацию программного обеспечения на которой выполнялись примеры - это ОС Debian GNU/Linux 6.0.1.Как правило новые технологии изучают либо в случае поиска инструментов необходимость в которых уже назрела, либо в качестве знакомства с инструментами и потенциальной возможности их дальнейшего применения. В первом случае ответ на вопрос "Для чего это нужно?" уже получен, во втором нет. Тем не менее я приведу ответ на этот вопрос. Cgroups - это технология обеспечивающая контроль за распределением различных ресурсов доступных операционной системе между группами процессов. Что это дает? Это дает возможность при высоких нагрузках распределять ресурсы по заранее заданным правилам между группами процессов. Плюс к этом существует возможность собирать статистику по потребленным ресурсам с помощью специальной подсистемы. Где это может применяться? В любой ситуации, где необходимо распределить ресурсы между конкурирующими процессами и в которой не хватает таких механизмов как nice и т.д.
Какое описание технологии может обойтись без терминологии.
[]Задача (task)[] - процесс ОС привязанный к определенной группе, все его потомки тоже будут наследовать привязку к группе родителя.
[]Подсистема (subsystem)[] - это модуль, который позволяет использовать некоторые услуги для группу задач. Каждая подсистема может быть прикреплена только к одной иерархии.
[]Настраиваемый параметр (tunable parameter)[] - это некая сущность(представлена файлом в виртуальной ФС cgroups) с помощью которой осуществляется взаимодействие с подсистемой.
[]Иерархия групп (hierarchy)[] - это множество групп расположенных в виде дерева, так что каждая задача в системе находится точно в одной группе в иерархии и с заданным множеством(set) подсистем. Каждая группа имеет свои настраиваемые параметры, которые соответствуют множеству подсистем специфичному для данной иерархии.
Пора переходить к практике. Как это не банально, но чтобы начать работать с cgroups необходимо установить приложения для userspace.
aptitude install cgroup-bin
Теперь всё готово, чтобы использовать cgroups. Есть несколько способов управлять cgroups: набор специфичных утилит, работа стандартными средствами с виртуальной ФС, из собственного программного обеспечения через библиотеку. Наиболее подходящий для первоначального знакомства это набор специфичных утилит. Конечно можно использовать и стандартные средства и взаимодействовать с системой через файлы в виртуальной ФС (echo, cat, mount, и т.д.)
Небольшое отступление. Для того чтобы перейти к практике необходимо определить некую "сферическую задачу в вакууме". Такая задача будет звучать так: есть система с запущенными веб-контейнером Tomcat и СУБД PostgreSQL, необходимо чтобы в момент пиковой нагрузки вычислительные ресурсы CPU распределялись по заданным правила (Tomcat - 40%, PostgreSQL - 50%, оставшаяся система 10%).
Как уже было упомянуто, есть несколько подходов в работе с cgroups. Мы будем использовать специфические утилиты. Для реализации текущей задачи необходимо построить иерархию групп, где можно будет настроить распределение вычислительных ресурсов CPU. Настройка иерархии осуществляется в файле /etc/cgconfig.conf (на самом деле её можно производить на запущенной системе, либо специфичными утилитами, либо стандартным походом с mount). Настройки из этого файла применяются при старте сервиса cgconfig. Это просто удобный способ восстанавливать иерархию cgroups после перезагрузки системы. Итак, конфигурация для текущей задачи выглядит следующим образом:
group default {
perm {
task {
uid = root;
gid = root;
}
admin {
uid = root;
gid = root;
}
}
cpu {
cpu.shares = 10;
}
}group daemons/tomcat {
perm {
task {
uid = root;
gid = root;
}
admin {
uid = root;
gid = root;
}
}
cpu {
cpu.shares = 40;
}
}group daemons/postgres {
perm {
task {
uid = root;
gid = root;
}
admin {
uid = root;
gid = root;
}
}
cpu {
cpu.shares = 50;
}
}mount {
cpu = /mnt/cgroups/cpu;
cpuacct = /mnt/cgroups/cpu;
}Секция mount описывает подключение двух подсистем cpu и cpuacct к иерархии /mnt/cgroups/cpu. Секции group настраивают конкретные группы для всей системы(sysdefault), tomcat и postgres. В данном случае задаются права для административных функций и добавления задач admin и task соответственно. Единственный настраиваемый параметр это cpu.shares из подсистемы cpu, который определяет долю вычислительных ресурсов CPU, которые достаются группе. Теперь можно перезапускать сервис cgconfig в /mnt/cgroups, должна быть следующая иерархия.
/mnt/cgroups/
└── cpu
├── cgroup.procs
├── cpuacct.stat
├── cpuacct.usage
├── cpuacct.usage_percpu
├── cpu.shares
├── daemons
│ ├── cgroup.procs
│ ├── cpuacct.stat
│ ├── cpuacct.usage
│ ├── cpuacct.usage_percpu
│ ├── cpu.shares
│ ├── notify_on_release
│ ├── postgres
│ │ ├── cgroup.procs
│ │ ├── cpuacct.stat
│ │ ├── cpuacct.usage
│ │ ├── cpuacct.usage_percpu
│ │ ├── cpu.shares
│ │ ├── notify_on_release
│ │ └── tasks
│ ├── tasks
│ └── tomcat
│ ├── cgroup.procs
│ ├── cpuacct.stat
│ ├── cpuacct.usage
│ ├── cpuacct.usage_percpu
│ ├── cpu.shares
│ ├── notify_on_release
│ └── tasks
├── notify_on_release
├── release_agent
├── default
│ ├── cgroup.procs
│ ├── cpuacct.stat
│ ├── cpuacct.usage
│ ├── cpuacct.usage_percpu
│ ├── cpu.shares
│ ├── notify_on_release
│ └── tasks
└── tasks
Теперь необходимо чтобы процессы запущенные в системе распределялись по нужным группам. Это можно сделать с помощью менеджера правил cgred, конфигурационный файл которого расположен в /etc/cgrules.conf. Конфигурация для нашей задачи представлена ниже:<user> <controllers> <destination>
*:tomcat cpu daemons/tomcat/
*:postgres cpu daemons/postgres/
* cpu default/Данные правила переносят все процессы с именем tomcat запущенных любым пользователем в группу daemons/tomcat, все процессы postgres в группу daemons/postgres и все остальные в default. Тем самым обеспечивая выполнения поставленной задачи.
Для решения задачи использовалась только одна подсистема cpu, которая отвечает за распределение вычислительных ресурсов по группам. Кроме неё в debian по умолчанию доступны следующие группы: cpuacct - для отображения потребленных ресурсов CPU; cpuset - привязывает группу к конкретному процессору; ns - обеспечивает создание именованных пространств в которых допускается взаимодействие между процессами и запрещается взаимодействие между процессами из разных пространств; devices - позволяет ограничивать доступ к устройствам; freezer - позволяет приостанавливать выполнение задач; net_cls - тегирует сетевые пакеты, и далее с помощью traffic controller реализуются различные правила для этих пакетов.
URL: http://programmersnook.blogspot.com/2011/04/cgroups.html http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6...
Обсуждается: http://www.opennet.me/tips/info/2589.shtml
А что предлагают почитатели FHS?
Можно ли запихнуть это куда-либо в /sys/ или /proc/
или, накрайняк, в /var/run/?
Мне встречалось /sys/fs/cgroups
В /mnt этому и правда делать нечего
Мне это тоже удивило vfs в /mnt это слишком неправильно
В описании cgroups монтируются в /mnt только потому, что это настройка по умолчанию для Debian 6. И это сделано умышленно, чтобы не путать новичков. В принципе меня это тоже возмущало. На это поведение даже завели баг-репорт http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604635.
Но в чём заключается "слишком неправильно"?
ну для vfs есть свои каталоги и все об этом прекрасно знают, чем они их не устроили непонятно
Хорошая заметка. Спасибо.
Почему в конфигурации групп group daemons/*
gid определен как root?
task {
uid = root;
gid = root;
}
Это имеет принципиальное значение?
Это определяет uid создаваемых в cgoups файлов.