Hi Clare, 
I don't recall what instance type we used earlier, but I think an Extra Large Instance is going to be fine. Do note that the master node is also being used to run jobs. However, if it's loaded by just the web server, SGE will typically just not schedule jobs to it. 

As far as the core/thread/slot concerns goes, SGE sees each core as a slot. Each job in Galaxy simply requires 1 slot, even if it uses multiple threads (i.e., cores). What this means is that nodes will probably get overloaded if only the same type of job is being run (BWA), but if analyses are being run that use multiple tools, jobs will get spread over the cluster to balance the overal load a bit better than by simply looking at the number of slots.

Enis


On Mon, Nov 21, 2011 at 4:34 AM, Clare Sloggett <sloc@unimelb.edu.au> wrote:
Hi Jeremy,

Also if you do remember what kind of Amazon node you used,
particularly for the cluster's master node (e.g. an 'xlarge' 4-core
15GB or perhaps one of the 'high-memory' nodes?), that would be a
reassuring sanity chech for me!

Cheers,
Clare

On Mon, Nov 21, 2011 at 10:37 AM, Clare Sloggett <sloc@unimelb.edu.au> wrote:
> Hi Jeremy, Enis,
>
> That makes sense. I know I can configure how many threads BWA uses in
> its wrapper, with bwa -t. But, is there somewhere that I need to tell
> Galaxy the corresponding information, ie that this command-line task
> will make use of up to 4 cores?
>
> Or, does this imply that there is always exactly one job per node? So
> if I have (for instance) a cluster made of 4-core nodes, and a
> single-threaded task (e.g. samtools), are the other 3 cores just going
> to waste or will the scheduler allocate multiple single-threaded jobs
> to one node?
>
> I've cc'd galaxy-dev instead of galaxy-user as I think the
> conversation has gone that way!
>
> Thanks again,
> Clare
>
>
> On Fri, Nov 18, 2011 at 2:36 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
>>
>>> On Fri, Nov 18, 2011 at 12:56 AM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
>>>
>>>> Scalability issues are more likely to arise on the back end than the front end, so you'll want to ensure that you have enough compute nodes. BWA uses four nodes by default--Enis, does the cloud config change this parameter?--so you'll want 4x50 or 200 total nodes if you want everyone to be able to run a BWA job simultaneously.
>>>>
>>>
>>> Actually, one other question - this paragraph makes me realise that I
>>> don't really understand how Galaxy is distributing jobs. I had thought
>>> that each job would only use one node, and in some cases take
>>> advantage of multiple cores within that node. I'm taking a "node" to
>>> be a set of cores with their own shared memory, so in this case a VM
>>> instance, is this right? If some types of jobs can be distributed over
>>> multiple nodes, can I configure, in Galaxy, how many nodes they should
>>> use?
>>
>> You're right -- my word choices were poor. Replace 'node' with 'core' in my paragraph to get an accurate suggestion for resources.
>>
>> Galaxy uses a job scheduler--SGE on the cloud--to distribute jobs to different cluster nodes. Jobs that require multiple cores typically run on a single node. Enis can chime in on whether CloudMan supports job submission over multiple nodes; this would require setup of an appropriate parallel environment and a tool that can make use of this environment.
>>
>> Good luck,
>> J.
>>
>>
>>
>>
>
>
>
> --
> E: sloc@unimelb.edu.au
> P: 03 903 53357
> M: 0414 854 759
>



--
E: sloc@unimelb.edu.au
P: 03 903 53357
M: 0414 854 759