On Fri, 18 Mar 2011, Reuti wrote:
...
Am I wildly off here? What do others set usage_weight_list to?
We use a fair share functional policy only regarding the slots, hence
the default works. Most of the time the slot count is the limiting
factor, not the memory (exceptions apply).
Ah, you're lucky :)
Unfortunately, we have some large memory users who are dominating the
cluster with the default policy - so I have to do something :(
...
Whether the user requests 1G, 100M or 2G - the job is blocking a
complete node with 12 slots (why should it be more expensive when you
use even more memory than 1G?) and should be charged in the same way as
a single job requesting 24 G. Maybe a reverse approach would do: check
what's left for other jobs, this will reduce the charge from the maximum
value: if 23 G by 0 slots is left, you have to pay the full price, like
0G left by 11 slots.
Unfortunately, I'm stuck with what the scheduler can do today. I agree
that the current configuration options do not do exactly what I need, but
to be honest I'm not sure what improvements we can make that also maintain
Grid Engine's flexibility (e.g. multiple queues per host, slot does not
necessarily mean cpu, etc.). In fact, I'm even unsure how to make my own
model of usage more accurate without having to run a simulation, of the
cluster, on the cluster :)
Perhaps we could extend the config so that the administrator can define
the usage calculation? This might be a good start - being able to use
something other than a straight line would be useful - while not shackling
us to specific assumptions. This would allow Grid Engine to adopt an
organisation's definition of "fair", rather than the other way around...
To be honest though, I still need to see how influential this option would
be on scheduling decisions in practice: with many workloads, there may be
enough "noise" in the system to get away with the present options.
* 6slot 2G/slot (half a node) = 6*(0.51 + 0.49*2) = 8.94 usage per sec
(1G is our default memory allotment)
I'm not wildly happy that the half node case is being over-charged
(going to have to think about that),
Yep, this was the thing I mentioned with that you can run twice of them.
Throwing a few numbers around, I have come to the conclusion that this is
acceptable in our environment.
With the default policy, the example 12slot host and the worst-case job
(1slot + all memory in box), the usage calculation is a factor of 12 out.
Bringing memory into the policy, the usage calculation can be at worst a
factor of 2 out.
As long as enough large-memory jobs are being submitted, I think this can
be a reasonable trade-off.
Mark
--
-----------------------------------------------------------------
Mark Dixon Email : [email protected]
HPC/Grid Systems Support Tel (int): 35429
Information Systems Services Tel (ext): +44(0)113 343 5429
University of Leeds, LS2 9JT, UK
-----------------------------------------------------------------
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
