Bug 1683528

I'm a bit stuck on this, on setting CPUQuota. Lack of enough documentation is blocking me.

https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#CPUQuota=
<snip>

CPUQuota=

    Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with "%". The percentage specifies how much CPU time the unit shall get at maximum, relative to the total CPU time available on one CPU. Use values > 100% for allotting CPU time on more than one CPU. This controls the "cpu.max" attribute on the unified control group hierarchy and "cpu.cfs_quota_us" on legacy. For details about these control group attributes, see cgroup-v2.txt and sched-bwc.txt.

    Example: CPUQuota=20% ensures that the executed processes will never get more than 20% CPU time on one CPU.

</snip>

So, how do we calculate the CPUQuota for servers with N processors? I don't know yet.
It is not straight forward like N * (% of CPU to be reserved) as per the example above. It has be > 100% for allotting CPU time on more than one CPU. If there are two cores and we set 2*33 = 66% then as per above documentation it'd be 66% per processor.

@sas, @sahina, @gobinda any ideas?

(In reply to Sachidananda Urs from comment #3)
> I'm a bit stuck on this, on setting CPUQuota. Lack of enough documentation
> is blocking me.
> 
> https://www.freedesktop.org/software/systemd/man/systemd.resource-control.
> html#CPUQuota=
> <snip>
> 
> CPUQuota=
> 
>     Assign the specified CPU time quota to the processes executed. Takes a
> percentage value, suffixed with "%". The percentage specifies how much CPU
> time the unit shall get at maximum, relative to the total CPU time available
> on one CPU. Use values > 100% for allotting CPU time on more than one CPU.
> This controls the "cpu.max" attribute on the unified control group hierarchy
> and "cpu.cfs_quota_us" on legacy. For details about these control group
> attributes, see cgroup-v2.txt and sched-bwc.txt.
> 
>     Example: CPUQuota=20% ensures that the executed processes will never get
> more than 20% CPU time on one CPU.
> 
> </snip>
> 
> So, how do we calculate the CPUQuota for servers with N processors? I don't
> know yet.
> It is not straight forward like N * (% of CPU to be reserved) as per the
> example above. It has be > 100% for allotting CPU time on more than one CPU.
> If there are two cores and we set 2*33 = 66% then as per above documentation
> it'd be 66% per processor.
> 
> @sas, @sahina, @gobinda any ideas?

Will this work - https://github.com/oVirt/ovirt-engine/blob/master/packaging/playbooks/roles/hc-gluster-cgroups/tasks/main.yml
This is what was implemented in ovirt-engine for nodes added to engine post the 3 node deployment

(In reply to Sahina Bose from comment #4)
> (In reply to Sachidananda Urs from comment #3)
> > I'm a bit stuck on this, on setting CPUQuota. Lack of enough documentation
> > is blocking me.
> > 
> > https://www.freedesktop.org/software/systemd/man/systemd.resource-control.
> > html#CPUQuota=
> > <snip>
> > 
> > CPUQuota=
> > 
> >     Assign the specified CPU time quota to the processes executed. Takes a
> > percentage value, suffixed with "%". The percentage specifies how much CPU
> > time the unit shall get at maximum, relative to the total CPU time available
> > on one CPU. Use values > 100% for allotting CPU time on more than one CPU.
> > This controls the "cpu.max" attribute on the unified control group hierarchy
> > and "cpu.cfs_quota_us" on legacy. For details about these control group
> > attributes, see cgroup-v2.txt and sched-bwc.txt.
> > 
> >     Example: CPUQuota=20% ensures that the executed processes will never get
> > more than 20% CPU time on one CPU.
> > 
> > </snip>
> > 
> > So, how do we calculate the CPUQuota for servers with N processors? I don't
> > know yet.
> > It is not straight forward like N * (% of CPU to be reserved) as per the
> > example above. It has be > 100% for allotting CPU time on more than one CPU.
> > If there are two cores and we set 2*33 = 66% then as per above documentation
> > it'd be 66% per processor.
> > 
> > @sas, @sahina, @gobinda any ideas?
> 
> Will this work -
> https://github.com/oVirt/ovirt-engine/blob/master/packaging/playbooks/roles/
> hc-gluster-cgroups/tasks/main.yml
> This is what was implemented in ovirt-engine for nodes added to engine post
> the 3 node deployment

Sahina, thank you. That definitely helped.

https://github.com/gluster/gluster-ansible-features/pull/22 fixes the issue.

Note that the calculation for 1/3 of the cores is done as follows:

ceil(processor_vcpus/3)*100

So if there are 4 processors, the CPUQuota will be 4/3 = 1.333 and ceil(1.333) = 2 * 100 = 200%
Due to ceil, it would be 50% in this case than 33%. It is not a bug but for smaller number of processors that is how it is.

Tested with gluster-ansible-features-1.0.4-5

Glusterfs slice is now available

[root@ ~]# systemctl status glusterd
● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/glusterd.service.d
           └─99-cpu.conf
   Active: active (running) since Wed 2019-03-06 13:53:36 IST; 3h 30min ago
 Main PID: 5365 (glusterd)
   CGroup: /system.slice/glusterd.service
           ├─ 5365 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level IN...
           ├─ 9863 /usr/sbin/glusterfsd -s dhcp37-161.lab.eng.blr.redhat.com ...
           ├─10355 /usr/sbin/glusterfsd -s dhcp37-161.lab.eng.blr.redhat.com ...
           └─10377 /usr/sbin/glusterfs -s localhost --volfile-id gluster/glus...

Mar 06 13:53:31 dhcp37-161.lab.eng.blr.redhat.com systemd[1]: Starting Gluste...
Mar 06 13:53:36 dhcp37-161.lab.eng.blr.redhat.com systemd[1]: Started Gluster...
Mar 06 14:29:28 dhcp37-161.lab.eng.blr.redhat.com glusterd[5365]: [2019-03-06...
Mar 06 14:29:40 dhcp37-161.lab.eng.blr.redhat.com glusterd[5365]: [2019-03-06...

[root@ ~]# cat /etc/systemd/system/glusterfs.slice 
[Slice]
CPUQuota=200%

[root@ ~]# nproc
4

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0661