1 |
thegeezer <thegeezer <at> thegeezer.net> writes: |
2 |
|
3 |
|
4 |
> there is a little more here |
5 |
> http://gentoo-en.vfose.ru/wiki/Improve_responsiveness_with_cgroups |
6 |
> which will allow you to script creating a cgroup with the processID of |
7 |
> an interactive shell, that you can start from to help save hunting down |
8 |
> all the threads spawned by chrome. |
9 |
> you can then do fun stuff with echo $$ > |
10 |
> /sys/fs/cgroup/cpu/high_priority/tasks |
11 |
|
12 |
Yea this is cool. But when it's a cluster, with thousands of processes |
13 |
this seem to be limited by the manual parsing and CLI actions that |
14 |
are necessary for large/busy environments. (We shall see). |
15 |
|
16 |
> hopefully this will give you a bit more control over all of that though |
17 |
|
18 |
|
19 |
Gmane mandates that the previous lines be culled. That said; you have given |
20 |
me much to think about, test and refine. |
21 |
|
22 |
In /sys/fs/cgroup/cpu I have: |
23 |
|
24 |
cgroup.clone_children cgroup.procs cpu.shares release_agent |
25 |
cgroup.event_control cgroup.sane_behavior notify_on_release tasks |
26 |
|
27 |
So I'll have to research creating and priotizing dirs like "high_priority" |
28 |
|
29 |
|
30 |
I certainly appreciate your lucid and direct explanations. |
31 |
Let me play with this a bit and I'll post back when I munge things |
32 |
up..... Are there any "graphical tools" for adjusting and managing |
33 |
cgroups? Surely when I apply this to the myriad of things running |
34 |
on my mesos+spark cluster I'm going to need a well thoughout tool |
35 |
for cgroup management, particularly on memory resources organization |
36 |
and allocations as spark is an "in_memory" environment that seems |
37 |
sensitive to OOM issues of all sorts. |
38 |
|
39 |
thx, |
40 |
James |