[GE users] Resource Reservation behaves strange under 6.2u2

reuti reuti at staff.uni-marburg.de
Wed Nov 25 10:56:32 GMT 2009

Am 25.11.2009 um 10:57 schrieb jdobler:

> It finally turned out that the problem was not related to resource  
> reservation but the way mem_free was requested. I think it was  
> related to requesting
> (installed memory)/(number of cores)
> instead of
> (installed memory)/(number of cores) - (some delta)

The delta also sometimes depends on the version of the BIOS. We have  
identical machines but due to some replacements some BIOSes are newer:

$ qhost
HOSTNAME                ARCH         NCPU  LOAD  MEMTOT  MEMUSE   
node006                 lx24-amd64      4  1.67   15.3G    4.2G     
3.8G    6.8M
node007                 lx24-amd64      4  0.63   15.4G  361.2M     
3.8G    9.2M

Both have 16 GB but differ slightly (as it shows up also in `free`).

> but still do not fully understand it.
> I also do not understand why "qalter -w [p|v] ..." reported that it  
> found a possible assignment, but then the job could not be started.

mem_free is not a conumable but a measured load, hence its value can  
change over time. You can make mem_free or (virtual_free) a  
consumable in `qconf -mc` which makes it more intuitional. I would  
prefer virtual_free and give each node the amount of real installed  
memory in `qconf -me <exechost>`. The scheduler will then take the  
computed complex *and* measured load into account - whatever is  
lower. Using virtual_free has the advantage, that you can define the  
real installed memory and oversubscribing it by 100 MB won't generate  
so much swapping (hence you can neglect the (delta)) (assuming you  
have a swap space defined).

> Is it possible that qalter just checks the complex values while the  
> scheduler (?)

Both qalter option? The difference should just be, that "v" assumes  
an empty cluster, but "p" honors the actual load.

-- Reuti

> checks at start time the actual load values?
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=229219
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].


To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

More information about the gridengine-users mailing list