The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Управление ресурсами с помощью cgroups
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 реализуются различные
правила для этих пакетов.
 
Ключи: cgroups, linux, limit
Раздел:    Корень / Администратору / Система / Linux специфика / Оптимизация и тюнинг в Linux

Обсуждение [ RSS ]
  • 1.1, Анонимко (?), 17:19, 12/06/2011 [ответить]  
  • +/
    А что предлагают почитатели FHS?
    Можно ли запихнуть это куда-либо в /sys/ или /proc/
    или, накрайняк, в /var/run/?
     
     
  • 2.2, Crazy Alex (??), 18:09, 12/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Мне встречалось /sys/fs/cgroups
    В /mnt этому и правда делать нечего
     
     
  • 3.3, Funt (?), 01:42, 13/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Мне это тоже удивило vfs в /mnt это слишком неправильно
     
     
  • 4.4, Ivan Pogudin (?), 16:09, 13/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В описании cgroups монтируются в /mnt только потому, что это настройка по умолчанию для Debian 6. И это сделано умышленно, чтобы не путать новичков. В принципе меня это тоже возмущало. На это поведение даже завели баг-репорт http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604635.
    Но в чём заключается "слишком неправильно"?
     
     
  • 5.6, Funt (?), 11:54, 14/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    ну для vfs есть свои каталоги и все об этом прекрасно знают, чем они их не устроили непонятно
     

  • 1.5, lol (??), 05:31, 14/06/2011 [ответить]  
  • +/
    Хорошая заметка. Спасибо.
     
  • 1.7, coder (?), 19:53, 24/07/2011 [ответить]  
  • +/
    Почему в конфигурации групп group daemons/*
    gid определен как root?
                    task {
                            uid = root;
                            gid = root;
                    }
    Это имеет принципиальное значение?
     
     
  • 2.8, another_anoymous (?), 17:31, 26/08/2011 [^] [^^] [^^^] [ответить]  
  • +/

    Это определяет uid создаваемых в cgoups файлов.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру