[
https://issues.apache.org/jira/browse/MAPREDUCE-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728417#action_12728417
]
Arun C Murthy commented on MAPREDUCE-728:
-----------------------------------------
bq. I have one item of high-level feedback. It looks like Mumak has two
components - a simulator and a trace-driven workload generator. It would be
nice if the workload generator was pluggable so that the simulator could be
used on synthetic workloads without requiring a trace.
The proposal is for Mumak to work with Rumen (whose jira is coming along soon)
which expose necessary apis to let us 'query' Rumen for characteristics of the
workload (e.g. for a given job j how long did a data-local map-task take? or a
off-rack one take?). So, yes you could seed Rumen with a synthetic trace and
run Mumak against it.
bq. What will be done about speculative tasks?
For V1 we plan to ignore speculation. It is considerably harder to simulate
per-task progress and thus the plan is to push it to a future release.
bq. Will Mumak simulate high-memory jobs?
Yes!
bq. The schedulers and the JobTracker currently have some threads that perform
an operation periodically and sleep in-between doing so. To make these work in
a simulator, I think we have to make these pieces of code not use threads [...]
Agreed. I know for sure that neither the default or capacity-scheduler use
threads, what about fair-share? How hard is it to stop using threads there?
bq. Calls to System.currentTimeMillis will have to be replaced by use of Clock
throughout the schedulers.
+1
As you'll see when we put up our work we use a 'virtual time' throughout Mumak
which we will use to seed JobTracker.clock.
> Mumak: Map-Reduce Simulator
> ---------------------------
>
> Key: MAPREDUCE-728
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-728
> Project: Hadoop Map/Reduce
> Issue Type: New Feature
> Reporter: Arun C Murthy
> Assignee: Arun C Murthy
> Fix For: 0.21.0
>
> Attachments: mumak.png
>
>
> h3. Vision:
> We want to build a Simulator to simulate large-scale Hadoop clusters,
> applications and workloads. This would be invaluable in furthering Hadoop by
> providing a tool for researchers and developers to prototype features (e.g.
> pluggable block-placement for HDFS, Map-Reduce schedulers etc.) and predict
> their behaviour and performance with reasonable amount of confidence,
> there-by aiding rapid innovation.
> ----
> h3. First Cut: Simulator for the Map-Reduce Scheduler
> The Map-Reduce Scheduler is a fertile area of interest with at least four
> schedulers, each with their own set of features, currently in existence:
> Default Scheduler, Capacity Scheduler, Fairshare Scheduler & Priority
> Scheduler.
> Each scheduler's scheduling decisions are driven by many factors, such as
> fairness, capacity guarantee, resource availability, data-locality etc.
> Given that, it is non-trivial to accurately choose a single scheduler or even
> a set of desired features to predict the right scheduler (or features) for a
> given workload. Hence a simulator which can predict how well a particular
> scheduler works for some specific workload by quickly iterating over
> schedulers and/or scheduler features would be quite useful.
> So, the first cut is to implement a simulator for the Map-Reduce scheduler
> which take as input a job trace derived from production workload and a
> cluster definition, and simulates the execution of the jobs in as defined in
> the trace in this virtual cluster. As output, the detailed job execution
> trace (recorded in relation to virtual simulated time) could then be analyzed
> to understand various traits of individual schedulers (individual jobs turn
> around time, throughput, faireness, capacity guarantee, etc). To support
> this, we would need a simulator which could accurately model the conditions
> of the actual system which would affect a schedulers decisions. These include
> very large-scale clusters (thousands of nodes), the detailed characteristics
> of the workload thrown at the clusters, job or task failures, data locality,
> and cluster hardware (cpu, memory, disk i/o, network i/o, network topology)
> etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.