[GE users] limits on real memory

reuti reuti at staff.uni-marburg.de
Fri Nov 13 16:12:12 GMT 2009


Am 13.11.2009 um 16:24 schrieb goncalo:

> But, in my opinion, this should not work like that... I should be able
> to discriminate between the two. For example, there are applications
> which use 2GB of RAM memory and also write to SWAP some stuff which  
> they

are you really speaking of the swap space or any scratch space on the  
disk? I'm not aware, that an application (which gets the illusion of  
a contiguous block of memory) can access the swap space directly.  
This is usually the kernel's duty to move pages from memory to swap  
when they are unused and move them back again.

What will happen with your application, when it's running on a system  
without any swap at all (or disabled with `swapoff -a`).

-- Reuti

> fetch from time to time.  Setting a h_vmem=2.0G will kill this kind of
> applications, and setting h_vmem=3.0G (for example) will not prevent
> other different aplication from using 3.0G of RAM memory (which is
> exactly what I want to prevent).
> Is there a workaround in this context?
> Cheers
> Goncalo
> On 11/13/2009 01:56 PM, reuti wrote:
>> Hi,
>> Am 13.11.2009 um 12:51 schrieb goncalo:
>>> Is it possible to set up a limit on real (not virtual) memory on a
>>> job?
>>> I only found the h(s)_vmem syntax in the queues...
>> when you specify h(s)_vmem, it will also set data (ulimit -d) and
>> memory (ulimit -m) in addition to the virtual memory (ulimit -v).
>> -- Reuti
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do? 
>> dsForumId=38&dsMessageId=226667
>> To unsubscribe from this discussion, e-mail: [users- 
>> unsubscribe at gridengine.sunsource.net].
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=226695
> 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