Is my cgroup overloaded?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Suppose I limited the cores a set of processes is permitted to use with cgroup/cpuset option.
I need to know if I have too many threads allocated to that cgroup, if the threads are experiencing excessive competition for the available cores.
How can I do that?
Without cgropups, I'd simply use load average in top
with the rule of thumb that load average should be less than the number of cores. Is there something similart that takes cgroup/cpuset into account?
cgroups cpu-usage
add a comment |Â
up vote
2
down vote
favorite
Suppose I limited the cores a set of processes is permitted to use with cgroup/cpuset option.
I need to know if I have too many threads allocated to that cgroup, if the threads are experiencing excessive competition for the available cores.
How can I do that?
Without cgropups, I'd simply use load average in top
with the rule of thumb that load average should be less than the number of cores. Is there something similart that takes cgroup/cpuset into account?
cgroups cpu-usage
If you have cgroups integrated with systemd, you can use systemd-cgtop
â Raman Sailopal
Apr 18 at 14:09
@RamanSailopal Not available on my machine (RHEL 6), and I am not even an admin. Thank you for the suggestion, though, it may work in more modern environment
â Arkadiy
Apr 18 at 14:18
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Suppose I limited the cores a set of processes is permitted to use with cgroup/cpuset option.
I need to know if I have too many threads allocated to that cgroup, if the threads are experiencing excessive competition for the available cores.
How can I do that?
Without cgropups, I'd simply use load average in top
with the rule of thumb that load average should be less than the number of cores. Is there something similart that takes cgroup/cpuset into account?
cgroups cpu-usage
Suppose I limited the cores a set of processes is permitted to use with cgroup/cpuset option.
I need to know if I have too many threads allocated to that cgroup, if the threads are experiencing excessive competition for the available cores.
How can I do that?
Without cgropups, I'd simply use load average in top
with the rule of thumb that load average should be less than the number of cores. Is there something similart that takes cgroup/cpuset into account?
cgroups cpu-usage
asked Apr 18 at 14:02
Arkadiy
1213
1213
If you have cgroups integrated with systemd, you can use systemd-cgtop
â Raman Sailopal
Apr 18 at 14:09
@RamanSailopal Not available on my machine (RHEL 6), and I am not even an admin. Thank you for the suggestion, though, it may work in more modern environment
â Arkadiy
Apr 18 at 14:18
add a comment |Â
If you have cgroups integrated with systemd, you can use systemd-cgtop
â Raman Sailopal
Apr 18 at 14:09
@RamanSailopal Not available on my machine (RHEL 6), and I am not even an admin. Thank you for the suggestion, though, it may work in more modern environment
â Arkadiy
Apr 18 at 14:18
If you have cgroups integrated with systemd, you can use systemd-cgtop
â Raman Sailopal
Apr 18 at 14:09
If you have cgroups integrated with systemd, you can use systemd-cgtop
â Raman Sailopal
Apr 18 at 14:09
@RamanSailopal Not available on my machine (RHEL 6), and I am not even an admin. Thank you for the suggestion, though, it may work in more modern environment
â Arkadiy
Apr 18 at 14:18
@RamanSailopal Not available on my machine (RHEL 6), and I am not even an admin. Thank you for the suggestion, though, it may work in more modern environment
â Arkadiy
Apr 18 at 14:18
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
Depending on what exactly you care about, there are two options:
If you care about how many threads/processes are in the cgroup, but not the 'load average':
Simply count the lines in the tasks
file for the cgroup. This file will automatically update whenever a thread or process is created or removed in the cgroup.
If you care about actual utilization:
This is a bit trickier. You can get a list of processes/threads in the cgroup from the above mentioned tasks
file, and then check usage for each PID using /proc
, but that approach has so many race conditions you could monetize it as a competitive sport. Alternatively, if you're using version 2 cgroups, you can check the cpu.stat
file in the cgroup. This file will have a couple of lines counting microseconds of CPU time consumed by the cgroup, so you can get a rough estimate of usage by checking it two times one second apart and dividing the difference by 10 to get a utilization percentage (100% for full utilization of one core, 20o% for full utilization of two, etc). A similar approach can be done with version one cgroups with the cpuacct controller (create a cgroup under that controller mirroring the one you created under the cpuset controller).
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Depending on what exactly you care about, there are two options:
If you care about how many threads/processes are in the cgroup, but not the 'load average':
Simply count the lines in the tasks
file for the cgroup. This file will automatically update whenever a thread or process is created or removed in the cgroup.
If you care about actual utilization:
This is a bit trickier. You can get a list of processes/threads in the cgroup from the above mentioned tasks
file, and then check usage for each PID using /proc
, but that approach has so many race conditions you could monetize it as a competitive sport. Alternatively, if you're using version 2 cgroups, you can check the cpu.stat
file in the cgroup. This file will have a couple of lines counting microseconds of CPU time consumed by the cgroup, so you can get a rough estimate of usage by checking it two times one second apart and dividing the difference by 10 to get a utilization percentage (100% for full utilization of one core, 20o% for full utilization of two, etc). A similar approach can be done with version one cgroups with the cpuacct controller (create a cgroup under that controller mirroring the one you created under the cpuset controller).
add a comment |Â
up vote
1
down vote
Depending on what exactly you care about, there are two options:
If you care about how many threads/processes are in the cgroup, but not the 'load average':
Simply count the lines in the tasks
file for the cgroup. This file will automatically update whenever a thread or process is created or removed in the cgroup.
If you care about actual utilization:
This is a bit trickier. You can get a list of processes/threads in the cgroup from the above mentioned tasks
file, and then check usage for each PID using /proc
, but that approach has so many race conditions you could monetize it as a competitive sport. Alternatively, if you're using version 2 cgroups, you can check the cpu.stat
file in the cgroup. This file will have a couple of lines counting microseconds of CPU time consumed by the cgroup, so you can get a rough estimate of usage by checking it two times one second apart and dividing the difference by 10 to get a utilization percentage (100% for full utilization of one core, 20o% for full utilization of two, etc). A similar approach can be done with version one cgroups with the cpuacct controller (create a cgroup under that controller mirroring the one you created under the cpuset controller).
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Depending on what exactly you care about, there are two options:
If you care about how many threads/processes are in the cgroup, but not the 'load average':
Simply count the lines in the tasks
file for the cgroup. This file will automatically update whenever a thread or process is created or removed in the cgroup.
If you care about actual utilization:
This is a bit trickier. You can get a list of processes/threads in the cgroup from the above mentioned tasks
file, and then check usage for each PID using /proc
, but that approach has so many race conditions you could monetize it as a competitive sport. Alternatively, if you're using version 2 cgroups, you can check the cpu.stat
file in the cgroup. This file will have a couple of lines counting microseconds of CPU time consumed by the cgroup, so you can get a rough estimate of usage by checking it two times one second apart and dividing the difference by 10 to get a utilization percentage (100% for full utilization of one core, 20o% for full utilization of two, etc). A similar approach can be done with version one cgroups with the cpuacct controller (create a cgroup under that controller mirroring the one you created under the cpuset controller).
Depending on what exactly you care about, there are two options:
If you care about how many threads/processes are in the cgroup, but not the 'load average':
Simply count the lines in the tasks
file for the cgroup. This file will automatically update whenever a thread or process is created or removed in the cgroup.
If you care about actual utilization:
This is a bit trickier. You can get a list of processes/threads in the cgroup from the above mentioned tasks
file, and then check usage for each PID using /proc
, but that approach has so many race conditions you could monetize it as a competitive sport. Alternatively, if you're using version 2 cgroups, you can check the cpu.stat
file in the cgroup. This file will have a couple of lines counting microseconds of CPU time consumed by the cgroup, so you can get a rough estimate of usage by checking it two times one second apart and dividing the difference by 10 to get a utilization percentage (100% for full utilization of one core, 20o% for full utilization of two, etc). A similar approach can be done with version one cgroups with the cpuacct controller (create a cgroup under that controller mirroring the one you created under the cpuset controller).
answered Apr 18 at 19:56
Austin Hemmelgarn
5,104915
5,104915
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f438511%2fis-my-cgroup-overloaded%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
If you have cgroups integrated with systemd, you can use systemd-cgtop
â Raman Sailopal
Apr 18 at 14:09
@RamanSailopal Not available on my machine (RHEL 6), and I am not even an admin. Thank you for the suggestion, though, it may work in more modern environment
â Arkadiy
Apr 18 at 14:18