> If I set the ram value my job needs to the maximum amount of ram
> the machines on our farm have, does that prevent the OS from
> having enough ram left over for the operating system to do its work?
No, that's not an issue.
The ram value you supply to Rush when you submit your job
does not actually constrain the amount of ram your render
actually uses, nor reserves it from the OS. Rush doesn't even
monitor your job's actual ram use.
The ram numbers you supply to Rush are comparative, used only
for decision making in whether to start a render running
on a machine or not.
When Rush wants to start a render running on an idle machine,
rush looks at the ram value for that machine from your rush hosts file
and compares that to the ram value your job is requesting.
As long as the value your job is requesting isn't more than the
machine has available, rush will start your render on that box.
If there's not enough ram on the box, rush won't start the frame
on the machine, and indicates this in the "NOTES" field of the
irush 'Cpus' report for your job, eg:
CPUSPEC[HOST] STATE [..] NOTES
+any=20@100[tahoe] CpuPass2 [..] Ram unavailable on tahoe (4000>512)
+any=20@100[meade] CpuPass2 [..] Ram unavailable on meade (4000>512)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In this case hosts 'tahoe' and 'meade' only have 512M of ram available,
but the job is requesting 4000M, so the job is turned away on those
processors.
ANALOGY
Think of the machine as a container for blocks, and your job's
frames as the blocks.
Rush needs to put as many blocks as it can in the container.
Rush is told the size of the container (ram value configured
in the rush hosts file) and the size of the blocks (the job's ram value).
Based on priority, rush will put the blocks (frames) into the container
until either there's no room for more, or until there's no more blocks.
Rush is further constrained by not allowing more than so many blocks (cpus)
in at a time, even though there might be enough room (ram) for more.
Rush keeps a tally of the container size and blocks, and based on that
tally determines if any more blocks can fit. Rush doesn't actually
measure the container or the blocks (because they're volatile), it goes
entirely by the values you tell it.
EXAMPLE
An example from the HOW-TO on 'Threaded Rendering':
http://www.seriss.com/rush-current/rush/rush-techniques.html#Threading
* * *
If you have a farm of dual proc machines that all have a gig of ram
configured in rush (eg. 'rush -lah' shows 1024 in the Ram column),
and you submit a job with the 'ram' value set to '1024', then you
will effectively secure both processors from rush. This is because
when rush starts your render on a machine, it will subtract the ram
value your job requests from the configured ram value for that machine,
leaving zero available for other jobs to use.
Also, you will only be able to start rendering on machines that
have 1024 available, which means both processors must be unused
by rush, otherwise rush will think less than 1024 is available,
preventing your job from running on those machines.
If you want to allow other renders to still be able to use the
other processors, then submit with your Ram value set just a
little bit lower, eg. 1023. You can then submit other renders
to these machines by requesting a Ram value of 1, and they'll be able
to get on because of the 1MB your job leaves behind; 1024-1023=1MB available.
* * *
The ram and cpu numbers are completely configurable; you can request more
or less ram than your job actually needs, the sysadmin can configure
the ram (and cpus) each machine has to be more or less than what the
machine actually has available. The numbers are comparative only,
and are just used for the decision making process of whether to run
a render or not. Once the render kicks in, it can do whatever it wants.
|