RHEL 7 Interesting CGroup behaviour.

Share this link

The other day I was looking at some Systemd service properties with the systemctl show command. One of them, CPUShares, got my interest.

Caution: The following tutorial shouldn’t be run on a production server! The CPU will be used at 100%!

To better understand how all this works, I created a basic Systemd unit file called /etc/systemd/system/testSpeed.service:

Description=Test Speed

ExecStart=/usr/bin/openssl speed 
ExecStop=/bin/kill -WINCH ${MAINPID}


Then, I created another copy of this file and updated the Systemd configuration:

# cd /etc/systemd/system; cp testSpeed.service testSpeed2.service
# systemctl daemon-reload

I started both new services on a fresh standard install of Centos 7 on a VM with 1 vCPU:

# systemctl start testSpeed && systemctl start testSpeed2

Each of the two new services were using almost 50% of the CPU:

  PID USER      PR  NI S %CPU %MEM     TIME+ COMMAND      
24598 root      20   0 R 49.8  0.3   0:08.42 openssl      
24601 root      20   0 R 49.8  0.3   0:08.40 openssl      

I checked the default CPUShares of the new services:

# systemctl show testSpeed | grep CPUShares

At this point, I asked myself: Is RHEL 7 really different from RHEL 6 and all the Unix systems in general? Is RHEL 7 limiting any new service by default? After some time, I came to the conclusion that everything was exactly as before: there is no CPU limit (or any other limit) on your service by default.

Because I wanted to learn how CGroups were working, I decided to apply a CPU constraint:

# systemctl set-property testSpeed CPUShares=512
# systemctl daemon-reload

Note1: The daemon-reload option is only there to avoid a warning message but doesn’t change anything.
Note2: You don’t need to restart any service.

Now, the testSpeed service gets 33.3% of the CPU and the testSpeed2 gets 66.7%:

  PID USER      PR  NI S %CPU %MEM     TIME+ COMMAND      
24601 root      20   0 R 66.7  0.3   1:23.58 openssl      
24598 root      20   0 R 33.3  0.3   1:22.20 openssl      

What exactly happened?

By default, Systemd services are part of the system.slice hierarchy. When you set a CPU constraint on one service, you not only assign a CPU resource controller to this service but also to all the services in the system.slice hierarchy. It is not possible to apply a CPU constraint on one service without affecting all the others.

The CPUShares concept represents more a CPU priority than a limit.

Concerning the CPU usage, this is the result of a computation:

  • testSpeed gets 33.3% because 512/(512+1024)=1/3
  • testSpeed2 gets 66.7% because 1024/(512+1024)=2/3

It is better to know this behaviour because otherwise you would perhaps be very surprised at the worst moment!

I would like to thank Radoslaw Kujawa for helping me understand what I was suspecting.

Look at my CGroups page to get some other tips on this topic.

Posted in RHEL7

Leave a Reply

Be the First to Comment!

Notify of

RHCSA7: Task of the day

Allowed time: 3 minutes.
Check that you've got no SELinux policy violations.

RHCE7: Task of the day

Allowed time: 8 minutes.
Set up an iScsi target based on a fileio backstore of 100MB called /opt/shareddata with CHAP authentication (username=usr/password=pwd), xfs filesystem and standard firewall configuration.

Poll for favorite RHEL 7 book

What is your favorite RHEL 7 book to prepare RHCSA & RHCE exams?

View Results

Loading ... Loading ...

Poll for most difficult RHCSA 7 topic

What do you think is the most difficult RHCSA 7 topic?

View Results

Loading ... Loading ...

Poll for most difficult RHCE 7 topic

What do you think is the most difficult RHCE 7 topic?

View Results

Loading ... Loading ...