0

/etc/cgconfig.conf

...

group memlimit {
    memory {
        memory.limit_in_bytes = 8589934592;
    }
}

group cpulimit {
    cpu {
        cpu.shares = 1024;
    }
}

/etc/cgrules.conf:

@gatewayer  memory  memlimit/
@gatewayer  cpu cpulimit/

And I've restarted services via commands:

service cgconfig restart
service cgred restart

After I execute my python script from user who belongs to group gatewayer, I could see the PID when executing cat /cgroup/memory/memlimit/cgroup.procs and the limit have been applied on the running process. However, limit on cpu does not take effect, and cat /cgroup/cpu/cpulimit/cgroup.procs doesn't print the PID as expected.

I tried to check on the process, and it turns out to be the same result, that memory is limited by cgroups whereas cpu is not:

$ cat /proc/18113/cgroup 
174:blkio:/
173:net_cls:/
172:freezer:/
171:devices:/
170:memory:/memlimit
169:cpuacct:/
168:cpu:/
167:cpuset:/

Could anyone give me some help? Many thanks.

Judking
  • 6,111
  • 11
  • 55
  • 84
  • `cpu.shares` is not a "limit" on CPU usage, if there's no contention for the CPU. If the CPU is otherwise idle, any process can use the entire CPU, regardless of its `cpu.shares` value. When there is contention for the CPU, however, the `cpu.shares` value is used to determine the percentage of the CPU time that process is given ("this process `cpu.shares`" / "sum of all `cpu.shares`"). – twalberg May 29 '15 at 17:15
  • The key problem is that my process **does not** share cpu proportionally as expected with the other processes. I run two same python scripts on different user, one should be guarded by cgroups, the other one is root. cpu.shares is 100 and 1024 respectively. But the processes virtually share cpu equally. @twalberg – Judking May 30 '15 at 04:08

1 Answers1

1

It seems the cgroups setting cpu.shares should be correctly applied.

Modern computer usually have a multi-core cpu. The python script used for testing can only use 100% of one core. So if there are still idle cpu cores, the other script could also use 100% from that core.

The better way to test cpu.shares is to run a number of processes more than the number of the cpu cores.

cat /proc/cpuinfo to indicate the number of cpu cores.

Shuangistan
  • 1,053
  • 8
  • 20