[gridengine users] Changing usage_weight_list cpu=1.000000, mem=0.000000, io=0.000000

[Mark Dixon]

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    : m.c.dixon at leeds.ac.uk
HPC/Grid Systems Support         Tel (int): 35429
Information Systems Services     Tel (ext): +44(0)113 343 5429
University of Leeds, LS2 9JT, UK
-----------------------------------------------------------------