On Mon, Nov 21, 2011 at 5:37 PM, Enis Afgan <
eafgan@emory.edu> wrote:
> 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
>
>
--
E:
sloc@unimelb.edu.au
P: 03 903 53357
M: 0414 854 759