Manage control groups

Manage control groups

Control groups, or cgroups, enable you to efficiently allocate a specific amount of system resources, including CPU and memory, to particular resource groups. Using control groups you can assign a specific amount of resources to particular OpenStack services, as well as to the underlying middleware components, such as RabbitMQ, MySQL, and others. Rational assignment may significantly improve the performance of your system.

Fuel implementation of control groups enables you to create one group for one process and then create a hierarchy of groups. By default, Fuel enables cgroups, however, Fuel does not configure any limits. You can configure cgroups using the settings.yaml file before you deploy an OpenStack environment or after deployment.

Note

Fuel supports control groups only for Ubuntu 14.04. If you have integrated nodes with any other Linux distributions in your OpenStack environment, control groups will not work.

Fuel supports all standard Linux cgroups resource controllers, or subsystems. However, to optimize the performance of your system you will mostly use the resource controllers and limits described in the following table.

Resource controllers and limits
Parameter Description
blkio

Controls input and output operations on block devices. You can specify the following limits:

blkio.weight
Defines a proportion of disk I/O available to the control group on all devices. Apply to Cinder and Glance back ends for better performance.
memory

Controls the use of memory.

You can specify the following limits:

memory.soft_limit_in_bytes
Enables soft limit on memory which means that the group can temporarily go beyond the soft limit to accommodate the workload and will be automatically reduced back to the soft limit when the system is low on memory.
memory.limit_in_bytes
The maximum amount of memory that the control group can use. Specify a value in bytes.
memory.swappiness
Controls swap priority. Determines whether kernel can claim memory from the control group. Set this value to 0 for high memory consuming processes, such as MySQL, MongoDB, RabbitMQ.
cpu

Controls the use of CPU.

You can specify the following limits:

cpu.cfs_quota_us

Defines the time during which all tasks in the control group can run in one period. After the quota expires the tasks are throlled and not allowed to run until the next period starts. The default value of cpu.cfs_quota_us` for all control groups is 100_000. Which means 100% usage. To restrict the use of CPU, modify this setting. For example, to use 30% of CPU, change the value of cpu.cfs_quota_us` to 30000. Controlling the use of the CPU resources through the cpu.cfs_quota_us and cpu.cfs_period_us parameters provides more accurate resource allocation compared to using cpu.shares.

You can set the following CPU limits:

  • beam.smp - for RabbitMQ up to 40%.
  • pangine - for Pacemaker up to 10%.
  • nova-api - for Nova 20 - 45%.
  • nova-conductor - for Nova up to 20%.
  • mysqld - for MySQL up to 10%.
  • neutron-server - for Neutron - 10%.
cpu.shares
Defines a share of CPU resources available to each control group. The default value is 1024. For example, if you assign 1024 to one process and 512 to the other process, kernel proportionally allocates more CPU for the first process and less for the second. Using the cpu.shares parameter to control CPU usage may not result in accurate CPU resource allocation.
cpuset Controls the use of memory and processor processes.
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

Contents