Programming Practices - Hadoop in Action - page 156

-1, which means there's no limit to the number of tasks a JVM can be reused for. The
JobConf object has a convenience method, setNumTasksToExecutePerJvm(int) , to
set the property for a job. This is summarized in table 6.6.

Table 6.6 Configuration property for enabling JVM reuse

Property Description

mapred.job.reuse.jvm.num.tasks Integer property for setting the maximum number of
tasks a JVM can run. A value of -1 means no limit.

6.3.5 Running with speculative execution

One of the original design assumptions of MapReduce (as stated in the Google
MapReduce paper) is that nodes are unreliable and the framework must handle
the situation where some nodes fail in the middle of a job. Under this assumption,
the original MapReduce

framework specifies the map tasks and the reduce tasks to
be idempotent . This means that when a task fails, Hadoop can restart that task and
the overall job will end up with the same result. Hadoop can monitor the health of
running nodes and restart tasks on failed nodes automatically. This makes fault toler-

ance transparent to the developer.
Often nodes don't suddenly fail but experience slowdown as I/O devices go bad. In
such situations everything works but the tasks run slower. Sometimes tasks also run slow
because of temporary congestion. This doesn't affect the correctness of the running
job but certainly affects its performance. Even one slow-running task will delay the
completion of a MapReduce job. Until all mappers have finished, none of the reducers
will start running. Similarly, a job is not considered finished until all the reducers
have finished.
Hadoop uses the idempotency property again to mitigate the slow-task problem.
Instead of restarting a task only after it has failed, Hadoop will notice a slow-running
task and schedule the same task

to be run in another node in parallel . Idempotency
guarantees the parallel task will generate the same output. Hadoop will monitor the
parallel tasks. As soon as one finishes successfully, Hadoop will use its output and kill
the other parallel tasks. This entire process is called speculative execution .
Note that speculative execution of map tasks will take place only after all map tasks
have been scheduled to run, and only for map tasks that are making much less progress
than is average on the other map tasks. It's the same case for speculative execution of
reduce tasks. Speculative execution does not “race” multiple copies of a task to get the
best completion time. It only prevents the slow tasks from dragging down the job's
completion time.
By default, speculative execution is enabled. One can turn it off for map tasks and
reduce tasks separately. To do this, set one or both of the properties in table 6.7 to
false. They're applied on a per-job basis, but you can also change the cluster-wide
default by setting them in the cluster configuration file.