基本介绍

  CGroups 是一种对进程资源管理和控制的统一框架,它提供的是一种机制,而具体的策略(Policy)是通过子系统(subsystem)来完成的。子系统是CGroups对进程组进行资源控制的具体行为。

机制和策略是Linux操作系统中一种经典的设计思想,所谓机制就是“我要提供哪种功能”,而策略则是“我要怎样来实现这种功能”。

RHEL提供了9个CGroups子系统。CGroups中每个子系统都代表一种类型的资源,详见子系统。

在RHEL6中有Namespaces,在RHEL7中,通过lssubsys未列出。Namespaces 命名空间子系统。

在RHEL7中增了 perf_event, hugetlb 两个子系统。

安装

#yum install libcgroup-tools.x86_64 0:0.41-8.el7

专有名词:

  层级 - hierarchies:

配置文件

  /etc/cgconfig.conf         libcgroup的缺省配置文件 default libcgroup configuration file

/etc/cgconfig.d/          libcgroup的缺省配置目录 default libcgroup configuration files directory 
  /etc/cgrules.conf
  /etc/cgsnapshot_blacklist.conf
  /etc/sysconfig/cgred

命令工具

  /usr/bin/cgclassify

  /usr/bin/cgcreate         创建CGroup群组

  /usr/bin/cgdelete           删除CGroup群组
  /usr/bin/cgexec
  /usr/bin/cgget
  /usr/bin/cgset
  /usr/bin/cgsnapshot
  /usr/bin/lscgroup
  /usr/bin/lssubsys

  /usr/sbin/cgclear
  /usr/sbin/cgconfigparser
  /usr/sbin/cgrulesengd

服务

  /usr/lib/systemd/system/cgconfig.service         提供创建层级的简单方法,并在层级中附加子系统,且在那些层级中管理CGroups。根据配置文件/etc/cgconfig.conf 的内容,可创建层级、挂载所需文件系统、创建CGroups及为每个组群设定子系统参数。
  /usr/lib/systemd/system/cgred.service

  

配置文件

 1.1. /etc/cgconfig.conf

  描述 DESCRIPTION

libcgroup配置文件,定义控制组(control groups)、他们的参数及挂载点。文件由mount、group、default三个sections组成。这些section可以构成层级,所有的都是可选的。以#开始的行都是注释行。

为每个子系统创建并挂载独立层级,并在这些层级中附加子系统。停止cgconfig服务,则会卸载它挂载的所有层级。文件包括两个主要类型的条目:mountgroup。挂载条目生成并挂载层级,将其作为虚拟文件系统,同时将子系统附加到那些层级中。挂载(mount)条目使用以下语法定义:

mount section:

    mount {
    <controller> = <path>;
    ...
   }

controller  内核子系统(kernel subsystem)的名字。内核支持的子系统列表在/proc/cgroups文件中;

subsys_name  hierarchy  num_cgroups  enabled
cpuset  10 1 1
cpu  4 1 1
cpuacct  4 1 1
memory  3 1 1
devices  2 1 1
freezer  5 1 1
net_cls  7 1 1
blkio  8 1 1
perf_event  6 1 1
hugetlb  9 1 1

命名的层次结构(named hierarchy)可以被作为contoller "name=<somename>", controller的名字需要用双引号(double quotes). 详见 Sample 2

libcgroup可以合并所有的子系统挂载到同一个目录,,被挂载的目录仅仅被挂载一次。详见Sample 1

 Path    被挂载的目录,此目录用于给定地控制器(controller)关联组层次结构(group hierarchy)。此目录在cgconfig服务启动的时候如果不存在,将被cgconfig服务自动创建,cgconfig服务停止的时候,被删除。

 mount section 如果没有,即没有控制器(controller)被挂载。

group section:

         group <name> {
[permissions]
<controller> {
<param name> = <param value>;
...
}
...
}

name:    控制组(control group)的名字,只能是字符,允许是路径名。这些组形成一个树,如,一个控制组中包含零个或多个子组(subgroups), 子组能用'/'做分隔符。

根控制组(root control group)在所有的层次结构中一直自动被创建,它是组层级结构(group hierarchy)的基础。可以在cgconfig.conf文件中,显示的以'.'作为根控制组的名字。这个                                         可以用作设置它的权限,详见 Sample 6.

当一个子组没有指定父组的时候,父组被自动创建。

    permissions:   在被挂载的文件系统(mounted filesystem)中,给定控制组的权限。root对控制组可以作任何事情。权限的语法如下:

           perm {
    task {
uid = <task user>;
gid = <task group>;
fperm = <file permissions>
  }
    admin {
uid = <admin name>;
gid = <admin group>;
dperm = <directory permissions>
fperm = <file permissions>
}
          }  

      task user/group   用户和组的名字, 他们拥有控制组的任务文件(tasks file).  给定的fperm指定文件权限。需要注意的是,fperm设置的值不使用作为指定权限。相反,当前文件的所有者权限被用作"umask" 组用户和其他用户权限。例如,如果fperm=777, 那么group用户和others用户与文件所有者的权限相同。              

      task user/group Name of the user and the group, which own the tasks file of the control group. Given fperm then specify the file permissions. Please note that the given value is not used as was specified. Instead, current file owner permissions are used as a "umask" for group and others permissions. For example if fperm = 777 then both group and others will get the same permissions as the file owner.

      admin user/group  用户和用户组的名字,他们拥有控制组的其余文件。给定的fpermdperm控制文件和路径的权限。同样,fperm和dperm给定的值,用于masked当前文件/路径所有者的权限。dperm为路径,fperm为文件。

      admin user/group Name of the user and the group which own the rest of control group's files. Given fperm and dperm control file and directory permissions. Again, the given value is masked by the file/directory owner permissions.

      权限仅仅被应用到圈定的控制组,且不被子组继承。在控制组定义中,如果没有perm部分,root:root是所有文件的拥有者,同样,如果fperm和dperm没有设置,缺省文件的权限被保留。

      Permissions are only apply to the enclosing control group and are not inherited by subgroups. If there is no perm section in the control group definition, root:root is the owner of all files and default file permissions are preserved if fperm resp. dperm are not specified.

    controller 内核子系统(the kernel subsystem)的名字。这部分可以为空,在这个情况下缺省的内核参数将被用。通过指定控制器(controller),控制组和它所有的父级被特定的子系统。一个控制组能被多个子系统控制,即使子系统被挂载不同的目录。一个控制组必须至少被一个子系统控制,因此libcgroup知道在哪个层级中创建控制组。

      Name of the kernel subsystem. The section can be empty, default kernel parameters will be used in this case. By specifying controller the control group and all its parents are controlled by the specific subsystem. One control group can be controlled by multiple subsystems, even if the subsystems are mounted on different directories. Each control group must be controlled by at least one subsystem, so that libcgroup knows in which hierarchies the control group should be created.

      给定的控制器的参数可以在后面的方括号部分被修改。      

      The parameters of the given controller can be modified in the following section enclosed in brackets.

      param name  设置的文件名称。每个控制器可以有零个或多个参数。
              Name of the file to set. Each controller can have zero or more parameters.

      param value  当控制被创建的时候,值被写到文件中。如果有空格和其他特殊字符,此值应用双引号引起来。
               Value which should be written to the file when the control group is created. If it is enclosed in double quotes `"', it can contain spaces and other special characters.

      如果没有group部分设定,没有group被创建。

      If no group section is specified, no groups are created.

    default section has this form:

         default {
      perm {
task {
uid = <task user>;
gid = <task group>;
fperm = <file permissions>
}
admin {
uid = <admin name>;
gid = <admin group>;
dperm = <directory permissions>
fperm = <file permissions>
}
}
}

      perm部分的内容与group部分中的形式相同。这里定义的权限指定了所有者,组用户和所有组用户文件的权限,这个没有明确在组部分制定他们的权限。即没有在组部分设定权限,这里的设置才有效。

      Content of the perm section has the same form as in group section. The permissions defined here specify owner and permissions of groups and files of all groups, which do not have explicitly specified their permissions in their group section.

  template section  与组部分有相同的结构。模板名用相同的模板字符串作为cgrules.conf 定义的tag(参考 cgrules.conf). 模板定义被用作控制组定义规则在cgrules.conf用相同的定义名。模板不用default部分设置。即缺省部分的设置对模板部分没有作用。

  template section has the same structure as group section. Template name uses the same templates string as cgrules.conf destination tag (see (cgrules.conf (5)). Template definition is used as a control group definition for rules in cgrules.conf (5) with the same destination name. Templates does not use default section settings.

  

     /etc/cgconfig.d/ 目录被用来保存附加的配置文件。cgrulesengds 搜索这个目录为附件的模板。

  /etc/cgconfig.d/ directory can be used for additional configuration files. cgrulesengd searches this directory for additional templates.

命令: cgconfigparser

服务: cgconfig

关系,服务cgconfig启动命令cgconfigparse,命令使用配置文件cgconfig.conf(缺省的配置文件)

  Examples:

    Example 1

      The configuration file:

         mount {
          cpu = /mnt/cgroups/cpu;
          cpuacct = /mnt/cgroups/cpu;
        }

      creates the hierarchy controlled by two subsystems with no groups inside. It corresponds to the following operations:

         mkdir /mnt/cgroups/cpu
        mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

    修改/etc/cgconfig.conf, 添加 mount {}后,重新启动cgconfig(#service cgconfig restart)失败,查看(#service cgconfig status)权限错误:

        11月 16 19:45:09 localhost.localdomain cgconfigparser[3403]: Error: cannot mount cpu,cpuacct to /mnt/cgroups/cpu: Permission denied

    Example 2

      The configuration file:

         mount {
          cpu = /mnt/cgroups/cpu;
          "name=scheduler" = /mnt/cgroups/cpu;
          "name=noctrl" = /mnt/cgroups/noctrl;
        }         group daemons {
          cpu {
            cpu.shares = "";
          }
        }
        group test {
          "name=noctrl" {
          }
        }

      创建两个层次结构。一个层次结构命名为scheduler,控制cpu子系统,在组守护进行内部。另一个命名为noctrl层级结构,不带任何控制器,带有test组。相应的操作如下:

      creates two hierarchies. One hierarchy named scheduler controlled by cpu subsystem, with group daemons inside. Second hierarchy is named noctrl without any controller, with group test. It corresponds to following operations:

          #mkdir /mnt/cgroups/cpu
          #mount -t cgroup -o cpu,name=scheduler cpu /mnt/cgroups/cpu
          #mount -t cgroup -o none,name=noctrl none /mnt/cgroups/noctrl           #mkdir /mnt/cgroups/cpu/daemons
          #echo > /mnt/cgroups/cpu/daemons/www/cpu.shares           #mkdir /mnt/cgroups/noctrl/tests

      守护进行组(daemons group)在它的第一个子组(subgroup)被创建的时候,自动被创建。它的所有参数有缺省值,仅仅root才能访问组的文件。

由于cpuacctcpu子系统都被挂载到相同目录,所有组也被cpuacct隐式控制,即使在任何组中没有cpuacct部分。

      The daemons group is created automatically when its first subgroup is created. All its parameters have the default value and only root can access group's files.

      Since both cpuacct and cpu subsystems are mounted to the same directory, all groups are implicitly controlled also by cpuacct subsystem, even if there is no cpuacct section in any of the groups.

    Example 3
      The configuration file:    

       mount {
        cpu = /mnt/cgroups/cpu;
        cpuacct = /mnt/cgroups/cpu;
      }       group daemons/www {
        perm {
          task {
            uid = root;
            gid = webmaster;
            fperm = ;
          }
          admin {
            uid = root;
            gid = root;
            dperm = ;
            fperm = ;
          }
        }
        cpu {
          cpu.shares = "";
        }
      }       group daemons/ftp {
        perm {
          task {
            uid = root;
            gid = ftpmaster;
            fperm = ;
          }
          admin {
            uid = root;
            gid = root;
            dperm = ;
            fperm = ;
          }
        }
        cpu {
          cpu.shares = "";
        }
      }

      创建了由两个子系统控制的层级,内带一个组和两个子组,设置了一个参数。相应如下操作(除了文件权限的小技巧模仿通过通过修改文件权限):

      creates the hierarchy controlled by two subsystems with one group and two subgroups inside, setting one parameter. It corresponds to the following operations (except for file permissions which are little bit trickier to emulate via chmod):

       mkdir /mnt/cgroups/cpu
      mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu       mkdir /mnt/cgroups/cpu/daemons       mkdir /mnt/cgroups/cpu/daemons/www
      chown root:root /mnt/cgroups/cpu/daemons/www/*
      chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks
      echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares       # + chmod the files so the result looks like:
      # ls -la /mnt/cgroups/cpu/daemons/www/
      # admin.dperm = 755:
      # drwxr-xr-x. 2 root webmaster 0 Jun 16 11:51 .
      #
      # admin.fperm = 744:
      # --w-------. 1 root webmaster 0 Jun 16 11:51 cgroup.event_control
      # -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cgroup.procs
      # -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.stat
      # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.usage
      # -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.usage_percpu
      # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.rt_period_us
      # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.rt_runtime_us
      # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.shares
      # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 notify_on_release
      #
      # tasks.fperm = 770
      # -rw-rw----. 1 root webmaster 0 Jun 16 11:51 tasks       mkdir /mnt/cgroups/cpu/daemons/ftp
      chown root:root /mnt/cgroups/cpu/daemons/ftp/*
      chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks
      echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares       # + chmod the files so the result looks like:
      # ls -la /mnt/cgroups/cpu/daemons/ftp/
      # admin.dperm = 755:
      # drwxr-xr-x. 2 root ftpmaster 0 Jun 16 11:51 .
      #
      # admin.fperm = 700:
      # --w-------. 1 root ftpmaster 0 Jun 16 11:51 cgroup.event_control
      # -r--------. 1 root ftpmaster 0 Jun 16 11:51 cgroup.procs
      # -r--------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.stat
      # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.usage
      # -r--------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.usage_percpu
      # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.rt_period_us
      # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.rt_runtime_us
      # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.shares
      # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 notify_on_release
      #
      # tasks.fperm = 774:
      # -rw-rw-r--. 1 root ftpmaster 0 Jun 16 11:51 tasks

      守护进行组(daemons group)在它的第一个子组(subgroup)被创建的时候,自动被创建。它的所有参数有缺省值,仅仅root才能访问组的文件。

由于cpuacctcpu子系统都被挂载到相同目录,所有组也被cpuacct隐式控制,即使在任何组中没有cpuacct部分。

      The daemons group is created automatically when its first subgroup is created. All its parameters have the default value and only root can access the group's files.

      Since both cpuacct and cpu subsystems are mounted to the same directory, all groups are implicitly also controlled by the cpuacct subsystem, even if there is no cpuacct section in any of the groups.

    

    Example 4
      The configuration file:

       mount {
        cpu = /mnt/cgroups/cpu;
        cpuacct = /mnt/cgroups/cpuacct;
      }       group daemons {
        cpuacct{
        }
        cpu {
        }
      }

      创建两个层级,一个普通组包括两个层级。对应如下操作:

      creates two hierarchies and one common group in both of them. It corresponds to the following operations:

       mkdir /mnt/cgroups/cpu
      mkdir /mnt/cgroups/cpuacct
      mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
      mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct       mkdir /mnt/cgroups/cpu/daemons
      mkdir /mnt/cgroups/cpuacct/daemons

      实际上创建了两个组。一个组在 cpuacct 层级, 另一个组在 cpu 层级。这两个组通常没有任何东西,能够包括不同的子组和不同的任务。

      In fact there are two groups created. One in the cpuacct hierarchy, the second in the cpu hierarchy. These two groups have nothing in common and can contain different subgroups and different tasks.

    Example 5
      The configuration file:

       mount {
        cpu = /mnt/cgroups/cpu;
        cpuacct = /mnt/cgroups/cpuacct;
      }       group daemons {
        cpuacct{
        }
      }       group daemons/www {
        cpu {
          cpu.shares = "";
        }
      }       group daemons/ftp {
        cpu {
          cpu.shares = "";
        }
      }

      创建两个层级,内部包括几个组。每个组被创建在两个层级中。对应的操作如下:

      creates two hierarchies with few groups inside. One of the groups is created in both hierarchies. It corresponds to the following operations:

       mkdir /mnt/cgroups/cpu
      mkdir /mnt/cgroups/cpuacct
      mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
      mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct       mkdir /mnt/cgroups/cpuacct/daemons
      mkdir /mnt/cgroups/cpu/daemons
8       mkdir /mnt/cgroups/cpu/daemons/www
      echo > /mnt/cgroups/cpu/daemons/www/cpu.shares
      mkdir /mnt/cgroups/cpu/daemons/ftp
      echo > /mnt/cgroups/cpu/daemons/ftp/cpu.shares

      组守护进程被创建在两个层级。 在 cpuacct 层级,配置文件中显示定义组。在 cpu 层级中,当 www 被创建时,组被隐式创建。这两个组通常没有任何东西,如他们没有共享进程和子组。 组 www 和 ftp 被创建仅仅在 cpu 层级,不被 cpuacct 子系统控制。

      Group daemons is created in both hierarchies. In the cpuacct hierarchy the group is explicitly mentioned in the configuration file. In the cpu hierarchy the group is created implicitly when www is created there. These two groups have nothing in common, for example they do not share processes and subgroups. Groups www and ftp are created only in the cpu hierarchy and are not controlled by the cpuacct subsystem.

    Example 6
      The configuration file:

       mount {
        cpu = /mnt/cgroups/cpu;
        cpuacct = /mnt/cgroups/cpu;
      }       group . {
        perm {
          task {
            uid = root;
            gid = operator;
          }
          admin {
            uid = root;
            gid = operator;
          }
16         }
        cpu {
        }
      }       group daemons {
        perm {
          task {
            uid = root;
            gid = daemonmaster;
          }
          admin {
            uid = root;
            gid = operator;
          }
        }
        cpu {
        }
      }

       创建了被两个子系统控制、带有一个组的层级,在组中明确了一下权限。相应的操作如下:

      creates the hierarchy controlled by two subsystems with one group having some special permissions. It corresponds to the following operations:

 mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu chown root:operator /mnt/cgroups/cpu/*
chown root:operator /mnt/cgroups/cpu/tasks mkdir /mnt/cgroups/cpu/daemons
chown root:operator /mnt/cgroups/cpu/daemons/*
chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks

      操作组(operator group)中的用户被允许去管理这些控制组(control groups), 例如,没有root权限,创建新的控制组和在组中移动进程。

      daemonmaster 组的成员能够移动进程到 daemons 进程组,但不能从组中移出进程。仅仅 operator 或 root 能够做。

      Users which are members of the operator group are allowed to administer the control groups, i.e. create new control groups and move processes between these groups without having root privileges.

      Members of the daemonmaster group can move processes to the daemons control group, but they can not move the process out of the group. Only the operator or root can do that.

    Example 7
      The configuration file:

        mount {
          cpu = /mnt/cgroups/cpu;
          cpuacct = /mnt/cgroups/cpuacct;
        }         group students {
          cpuacct{
            }
          cpu {
             }
        }         template students/%u {
          cpuacct{
              }
          cpu {
            }
        }
       #mkdir /mnt/cgroups/cpu/daemons
      #mkdir /mnt/cgroups/cpuacct/daemons

      这个情况与Example 4相似。唯一不同是模板,模板用于作为一个目标,如果一些规则适用"/students/%u".

      The situation is the similar as in Example 4. The only difference is template, which is used if some rule uses "/students/%u" as a destination.

  注意 RECOMMENDATIONS   

    保持层级独立 Keep hierarchies separated

      存在多个层级是非常有效和能在各种场景使用。保持事情的清楚,不要在多个层级中创建一个组。Exampls 4 和 5 显得不宜阅读和可能有点混淆,特别其他人阅读配置文件时。

      Having multiple hierarchies is perfectly valid and can be useful in various scenarios. To keeps things clean, do not create one group in multiple hierarchies. Examples 4 and 5 show how unreadable and confusing it can be, especially when reading somebody elses configuration file.

    显式好于隐式 Explicit is better than implicit

      libcgroup 能够隐式创建组,组为可配置子组的创建需要(即libcgroup在创建子组时,隐式创建组)。在简单场景下,这可能是有用的和节省一下键盘敲击。当出现多个层级是,最好是显示的明确多个组和关于他们的所有控制区。
libcgroup can implicitly create groups which are needed for the creation of configured subgroups. This may be useful and save some typing in simple scenarios. When it comes to multiple hierarchies, it's better to explicitly specify all groups and all controllers related to them.

  FILES
    /etc/cgconfig.conf
      default libcgroup configuration file

    /etc/cgconfig.d/
      default libcgroup configuration files directory

  SEE ALSO

    cgconfigparser (8)

  BUGS

    参数值必须要不带空格的单一字符串。不支持带引号的字符串。
    Parameter values must be single strings without spaces. Parsing of quoted strings is not implemented.

  使用 #man cgconfig.conf 获取更多信息。

子系统

  #lssubsys    列出当前的子系统  list hierarchies containing given subsystem

   [root@localhost ~]# lssubsys
    cpuset : 对于多核cpu,该子系统可以设置进程组只能在指定的核上运行,并且还可以设置进程组在制定的内存节点上申请内存。
    cpu,cpuacct : CPU子系统为每个进程组设置一个使用CPU的权重值,以此管理进程组对CPU的访问。cpuacct子系统只用于生成当前进程组内的进程对CPU的使用报告。
    memory : 该子系统提供了以页面为单位对内存的访问,比如对进程组设置内存使用上限等,同时可以生成内存资源报告。
    devices : 该子系统可以限制进程组对设备的访问,即允许或禁止进程组对某设备的访问。
    freezer : 该子系统可以使得进程组中的所有进程挂起。
    net_cls : 该子系统提供对网络带宽的访问限制,比如对发送带宽和接收带宽进程限制。
    blkio : 该子系统用于限制每个块设备的输入/输出。与cpu子系统类似,该子系统通过为每个进程组设置权重来控制块设备对其的I/O时间;其次,该子系统也可以限制进程组的I/O带宽及IOPS。
    perf_event
    hugetlb

    显示子系统mount目录

   [root@localhost ~]# lssubsys -aim
  cpuset /sys/fs/cgroup/cpuset
  cpu,cpuacct /sys/fs/cgroup/cpu,cpuacct
  memory /sys/fs/cgroup/memory
  devices /sys/fs/cgroup/devices
  freezer /sys/fs/cgroup/freezer
  net_cls /sys/fs/cgroup/net_cls
  blkio /sys/fs/cgroup/blkio
  perf_event /sys/fs/cgroup/perf_event
  hugetlb /sys/fs/cgroup/hugetlb

    相关指令:

    lscgroup (1), cgcreate (1), cgdelete

  lscgroup   list all cgroups

   [root@localhost ~]# lscgroup
  devices:/
  memory:/
  cpu,cpuacct:/
  freezer:/
  perf_event:/
  net_cls:/
  blkio:/
  hugetlb:/
  cpuset:/

   相关指令: lssubsys (1), cgcreate (1), cgdelete (1), cgconfig.conf (5)

  cgcreate   创建CGroup群组

    /usr/bin/cgcreate

     

    EXAMPLES

     cgcreate -g *:student -g devices:teacher

     在所有的挂载层级创建 student 控制组,在包含devices控制器的层级

      
    create control group student in all mounted hierarchies and create control group teacher in hierarchy containing controller devices.

使用CGroups

  1.查找某个进程所属CGroups

    #ps -O cgroups

[root@localhost ~]# ps -o cgroup
CGROUP
:name=systemd:/user.slice/user-.slice/session-.scope
:name=systemd:/user.slice/user-.slice/session-.scope

FAQ:

  1. 子系统是否可以创建、删除.

centos7.2上实践cgoup的更多相关文章

  1. CentOS7 安装 RocketMQ 实践和小示例

    CentOS7 安装 RocketMQ 实践和小示例 1.通过 SSH 工具(比如 XShell)连接到 CentOS7 服务器上: 2.进入到 /usr/local 目录中: cd /usr/loc ...

  2. Centos7系统配置上的变化(三)为网络接口添加多IP

    原文 Centos7系统配置上的变化(三)为网络接口添加多IP 实验的方法有 nmtui, 编辑ifcfg-*文件,ip addr 指令,子连接配置文件.一.nmtui手工添加IP 看一下当前网络设备 ...

  3. Centos7系统配置上的变化(二)网络管理基础

    原文 Centos7系统配置上的变化(二)网络管理基础 上篇简单介绍了CentOS 7 在服务和网络方面的一点变化,先前很多烂熟于心的操作指令已经不适用了,不管是否习惯,总要接受.熟悉这些变化. 写上 ...

  4. Centos7系统配置上的变化(一)

    原文 Centos7系统配置上的变化(一) 安装后,一开始有点儿无力吐槽的感觉,变化这么大? 一.Runlevel 首先一条,原来一直用的CentOS-6.5-x86_64-minimal.iso光盘 ...

  5. 尝试在CentOS7.2上编译安装Swift

    苹果提供 Ubuntu上构建Swift 的教程,通过这个教程我尝试使用CentOS7.2上玩儿一把.目前已经成功在CentOS7.2上班成功安装 swift 4.0 https://github.co ...

  6. [AI开发]centOS7.5上基于keras/tensorflow深度学习环境搭建

    这篇文章详细介绍在centOS7.5上搭建基于keras/tensorflow的深度学习环境,该环境可用于实际生产.本人现在非常熟练linux(Ubuntu/centOS/openSUSE).wind ...

  7. (亲测成功)在centos7.5上安装kvm,通过VNC远程连接并创建多台ubuntu虚拟机(ubuntu server版本)

    在centos7.5上安装kvm,通过VNC远程连接并创建多台ubuntu虚拟机 前提:服务器端安装桌面版的centos系统 CentOS Linux release 7.5.1804 (Core) ...

  8. 20155205 《Java程序设计》0510课上实践博客

    20155205 <Java程序设计>0510课上实践博客 一.教材代码检查-p98 未提交成功原因: 一开始在iterm中运行,但是结果出错,没有时间提交了.这个提交其实很简单,没有提交 ...

  9. Kubernetes+Docker的云平台在CentOS7系统上的安装

    Kubernetes+Docker的云平台在CentOS7系统上的安装 1.运行VirtualBox5. 2.安装CentOS7系统. 注意:选择Basic Server类型 安装过程略. 3.修改计 ...

随机推荐

  1. 帝国CMS灵动标签e:loop

    头条调用方法 1 [e:loop={'selfinfo',5,13,0,'firsttitle=2'}]<a href="<?=$bqsr[titleurl]?>" ...

  2. hihoCoder-1036 (AC自动机模板题)

    题目大意:判断模式串中是否出现模板. 代码如下: # include<iostream> # include<cstdio> # include<queue> # ...

  3. JSBinding / Memory Management (GC)

    C# and JavaScript both have Garbage Collection (GC). They should not conflict with each other. Class ...

  4. Python之路,day2-Python基础1

    python2 range(20) for i in range(10): print(i) range(1,10)  ----->从1开始到9 else: #如果for循环正常结束,  就执行 ...

  5. redis 集群环境搭建-redis集群管理

    集群架构 (1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽. (2)节点的fail是通过集群中超过半数的节点检测失效时才生效. (3)客户端与redi ...

  6. 【转】浏览器内核、渲染引擎、js引擎

    [1]定义 浏览器内核分成两部分渲染引擎和js引擎,由于js引擎越来越独立,内核就倾向于只指渲染引擎 渲染引擎是一种对HTML文档进行解析并将其显示在页面上的工具[2]常见引擎 渲染引擎: firef ...

  7. PHP和Golang使用Thrift1和Thrift2访问Hbase0.96.2(ubuntu12.04)

    目录: 一.Thrift1和Thrift2的简要介绍 1) 写在前面 2) Thrift1和Thrift2的区别  二.Thrift0.9.2的安装 1) 安装依赖插件 2) Thrift0.9.2的 ...

  8. 如何解决虚拟机克隆导致"Bringing up interface eth0: Error: No suitable device found: no device found for connection 'System eth0'."

    在VMware的虚拟机中克隆CentOS,在重启网卡的时候报错: Bringing up interface eth0:  Error: No suitable device found: no de ...

  9. INNO 补丁制作技术, 打开 INNO 补丁制作方法的第一页

    INNO 补丁制作技术, 打开 INNO 补丁制作方法的第一页 作者:xin 日期:2005-09-23 字体大小: 小 中 大   VPatch 在 INNO 中的应用. VPatch 属于专为NS ...

  10. 【日期-时间】Java中Calendar的使用

    主要介绍了Calendar类的使用 输出 * 时间格式化 * 当前时间:2016-12-02 16:46:27.079 * * 转换:String-->Date-->Calendar * ...