Resource Errors
The following errors are commonly caused by constrained resources on the cluster.
Topics
Do you have enough HDFS space for your cluster?
If you do not, Amazon EMR returns the following error: “Cannot replicate block, only managed to replicate to zero nodes.” This error occurs when you generate more data in your cluster than can be stored in HDFS. You will see this error only while the cluster is running, because when the cluster ends it releases the HDFS space it was using.
The amount of HDFS space available to a cluster depends on the number and type of Amazon EC2 instances that are used as core nodes. All of the disk space on each Amazon EC2 instance is available to be used by HDFS. For more information about the amount of local storage for each EC2 instance type, see Instance Types and Families in the Amazon EC2 User Guide for Linux Instances.
The other factor that can affect the amount of HDFS space available is the replication factor, which is the number of copies of each data block that are stored in HDFS for redundancy. The replication factor increases with the number of nodes in the cluster: there are 3 copies of each data block for a cluster with 10 or more nodes, 2 copies of each block for a cluster with 4 to 9 nodes, and 1 copy (no redundancy) for clusters with 3 or fewer nodes. The total HDFS space available is divided by the replication factor. In some cases, such as increasing the number of nodes from 9 to 10, the increase in replication factor can actually cause the amount of available HDFS space to decrease.
For example, a cluster with ten core nodes of type m1.large would have 2833 GB of space available to HDFS ((10 nodes X 850 GB per node)/replication factor of 3).
If your cluster exceeds the amount of space available to HDFS, you can add additional core nodes to your cluster or use data compression to create more HDFS space. If your cluster is one that can be stopped and restarted, you may consider using core nodes of a larger Amazon EC2 instance type. You might also consider adjusting the replication factor. Be aware, though, that decreasing the replication factor reduces the redundancy of HDFS data and your cluster's ability to recover from lost or corrupted HDFS blocks.
Are you seeing "EC2 Quota Exceeded" errors?
If you are getting messages that you are exceeding your Amazon EC2 instance quota,
this may
be for one of several reasons. Depending on configuration differences, it may take
up to
5-20 minutes for previous clusters to terminate and release allocated resources. If
you
are getting an
EC2 QUOTA EXCEEDED error when you attempt to launch a
cluster, it may be because resources from a recently terminated cluster have not yet
been released. Furthermore, if you attempt to resize an instance group, you may also
encounter this error when your new target size is greater than the current instance
quota for the account. In these cases, you can either terminate and launch the cluster
with a smaller target size. In all cases, you can terminate unused cluster resources
or
EC2 instances, request that your Amazon EC2 quota be
increased, or wait to re-launch a cluster.
Note
You cannot issue more than one resize request to the same cluster. Therefore, if your first request fails, you will have to potentially terminate your current cluster and launch another cluster to with the number of instances desired.
Are you seeing "Too many fetch-failures" errors? amount.
Are you seeing "File could only be replicated to 0 nodes instead of 1" errors?
When a file is written to HDFS, it is replicated to multiple core nodes. When you see this error, it means that the NameNode daemon does not have any available DataNode instances to write data to in HDFS. In other words, block replication is not taking place. This error can be caused by a number of issues:
The HDFS filesystem may have run out of space. This is the most likely cause.
DataNode instances may not have been available when the job was run.
DataNode instances may have been blocked from communication with the master node.
Instances in the core instance group might not be available.
Permissions may be missing. For example, the JobTracker daemon may not have permissions to create job tracker information.
The reserved space setting for a DataNode instance may be insufficient. Check whether this is the case by checking the dfs.datanode.du.reserved configuration setting.
To check whether this issue is caused by HDFS running out of disk space, look at the
HDFSUtilization metric in CloudWatch. If this value is too high, you can add
additional core nodes to the cluster. Keep in mind that you can only add core nodes
to a
cluster, you cannot remove them. If you have a cluster that you think might run out
of
HDFS disk space, you can set an alarm in CloudWatch to alert you when the value of
HDFSUtilization rises above a certain level. For more information, see
Manually Resizing a Running Cluster and Monitor Metrics with CloudWatch.
If HDFS running out of space was not the issue, check the DataNode logs, the NameNode logs and network connectivity for other issues that could have prevented HDFS from replicating data. For more information, see View Log Files.
Are your TaskTracker nodes being blacklisted?
A TaskTracker node is a node in the cluster that accepts map and reduce tasks. These are assigned by a JobTracker daemon. The JobTracker monitors the TaskTracker node through a heartbeat.
There are a couple of situations in which the JobTracker daemon blacklists a TaskTacker node, removing it from the pool of nodes available to process tasks:
If the TaskTracker node has not sent a heartbeat to the JobTracker daemon in the past 10 minutes (60000 milliseconds). This time period can be configured using the
mapred.tasktracker.expiry.intervalconfiguration setting. For more information about changing Hadoop configuration settings, see Create Bootstrap Actions to Install Additional Software.
If the TaskTracker node has more than 4 failed tasks. You can change this to a higher value using the
modify mapred.max.tracker.failuresconfiguration parameter. Other configuration settings you might want to change are the settings that control how many times to attempt a task before marking it as failed:
mapred.map.max.attemptsfor map tasks and
mapreduce.reduce.maxattemptsfor reduce tasks. For more information about changing Hadoop configuration settings, see Create Bootstrap Actions to Install Additional Software.
You can use the CloudWatch CLI to view the number of blacklisted TaskTracker nodes. The command for doing so is shown in the following example. For more information, see the Amazon CloudWatch CLI Reference.
mon-get-stats NoOfBlackListedTaskTrackers --dimensions JobFlowId=
JobFlowID--statistics Maximum --namespace AWS/ElasticMapReduce
The following example shows how to launch a cluster and use a bootstrap action to
set
the value of
mapred.max.tracker.failures to 7, instead of the default
4.
Type the following command using the AWS CLI and replace
myKey with the name of your EC2 key pair.
aws emr create-cluster --name "
Test cluster" --ami-version
2.4--applications Name==
"Modified mapred.max.tracker.failures",Args=[
"-m","mapred.max.tracker.failures=7"]
Note
If you have not previously created the default EMR service role and EC2 instance
profile, type aws
emr create-default-roles to create them before typing
the
create-cluster subcommand.
When you launch a cluster using the preceding example, you can connect to the
master node and see the changed configuration setting in
/home/hadoop/conf/mapred-site.xml. The modified line will
appear as shown in the following example.
<property><name>mapred.max.tracker.failures</name><value>7</value></property>