As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solucionar problemas com um cluster lento do Amazon EMR
Esta seção orienta você durante o processo de solução de problemas com um cluster que ainda está em execução, mas está demorando muito para retornar resultados. Para obter mais informações sobre o que fazer se o cluster tiver sido encerrado com um código de erro, consulte [Solucionar problemas de um cluster do Amazon EMR que falhou com um código de erro](emr-troubleshoot-failed.md)
O Amazon EMR permite que você especifique o número e o tipo de instâncias no cluster. Essas especificações são os principais meios de afetar a velocidade com a qual o processamento dos seus dados é concluída. Uma ação que você pode considerar é reexecutar o cluster, dessa vez especificando instâncias do EC2 com recursos maiores ou especificando um número maior de instâncias no cluster. Para obter mais informações, consulte [Configuração de hardware e redes do cluster do Amazon EMR](emr-plan-instances.md).
Os tópicos a seguir você orientam você durante o processo de identificar as causas alternativas de um cluster lento.
**Topics**
+ [Etapa 1: coletar dados sobre o problema com o cluster do Amazon EMR](emr-troubleshoot-slow-1.md)
+ [Etapa 2: verificar o ambiente de cluster do EMR](emr-troubleshoot-slow-2.md)
+ [Etapa 3: examinar os arquivos de log do cluster do Amazon EMR](emr-troubleshoot-slow-3.md)
+ [Etapa 4: verificar a integridade do cluster e das instâncias do Amazon EMR](emr-troubleshoot-slow-4.md)
+ [Etapa 5: verificar se há grupos suspensos](emr-troubleshoot-slow-5.md)
+ [Etapa 6: revisar as configurações do cluster do Amazon EMR](emr-troubleshoot-slow-6.md)
+ [Etapa 7: examinar dados de entrada do cluster do Amazon EMR](emr-troubleshoot-slow-7.md)
# Etapa 1: coletar dados sobre o problema com o cluster do Amazon EMR
A primeira etapa para solucionar problemas de um cluster é coletar informações sobre o que deu errado e o status e a configuração atuais do cluster. Essas informações serão usadas nas etapas a seguir para confirmar ou descartar as possíveis causas do problema.
## Definir o problema
Começamos fazendo uma definição clara do problema. Algumas perguntas para se fazer:
+ O que eu esperava que acontecesse? O que aconteceu em vez disso?
+ Quando o problema ocorreu pela primeira vez? Com que frequência ele ocorreu desde então?
+ Alguma coisa mudou na forma como eu configuro ou executo o cluster?
## Detalhes do cluster
Os detalhes do cluster a seguir são úteis para ajudar a monitorar problemas. Para obter mais informações sobre como reunir essas informações, consulte [Exibição de status e detalhes do cluster do Amazon EMR](emr-manage-view-clusters.md).
+ Identificador do cluster. (Também chamado de identificador de fluxo de trabalho.)
+ Região da AWS e na Zona de Disponibilidade em que o cluster foi lançado.
+ Estado do cluster, inclusive detalhes da última alteração de estado.
+ Tipo e número de instâncias do EC2 especificados para os nós principal, central e de tarefa.
# Etapa 2: verificar o ambiente de cluster do EMR
Verifique seu ambiente para ver se há interrupções no serviço ou se você excedeu um limite de AWS serviço.
**Topics**
+ [Verificar a existência de interrupções de serviço](#emr-troubleshoot-slow-2-outages)
+ [Verificar os limites de uso](#emr-troubleshoot-slow-2-limits)
+ [Verificar a configuração da sub-rede da Amazon VPC](#emr-troubleshoot-slow-2-vpc)
+ [Reiniciar o cluster](#emr-troubleshoot-slow-2-restart)
## Verificar a existência de interrupções de serviço
O Amazon EMR usa diversos Amazon Web Services internamente. Ele executa servidores virtuais no Amazon EC2, armazena dados e scripts no Amazon S3 e reporta métricas para. CloudWatch Os eventos que interrompem esses serviços são raros, mas, quando ocorrem, podem causar problemas no Amazon EMR.
Antes de avançar, verifique o [Painel de status dos serviços](https://status.aws.amazon.com/). Verifique a região onde você iniciou o cluster para saber se há um eventos de interrupção em qualquer um desses serviços.
## Verificar os limites de uso
Se você estiver iniciando um cluster grande, tiver lançado vários clusters simultaneamente ou se for um usuário compartilhando um Conta da AWS com outros usuários, o cluster pode ter falhado porque você excedeu um limite de AWS serviço.
O Amazon EC2 limita o número de instâncias de servidores virtuais em execução em uma única AWS região a 20 instâncias sob demanda ou reservadas. Se você iniciar um cluster com mais de 20 nós ou executar um cluster que faça com que o número total de instâncias do EC2 ativas em você Conta da AWS exceda 20, o cluster não poderá executar todas as instâncias do EC2 necessárias e poderá falhar. Quando isso acontece, o Amazon EMR retorna um erro `EC2 QUOTA EXCEEDED`. Você pode solicitar o AWS aumento do número de instâncias do EC2 que você pode executar em sua conta enviando uma [solicitação para aumentar o aplicativo Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/) Instance Limit.
Outra coisa que pode fazer você exceder os limites de uso é o atraso entre quando um cluster é encerrado e quando ele libera todos os recursos. Dependendo da configuração, pode demorar de 5 a 20 minutos para um cluster ser encerrado totalmente e liberar os recursos alocados. Se você estiver recebendo um erro `EC2 QUOTA EXCEEDED` ao tentar iniciar um cluster, isso poderá acontecer porque os recursos de um cluster recém-encerrado talvez ainda não tenham sido liberados. Nesse caso, é possível [solicitar que sua cota do Amazon EC2 seja aumentada](https://aws.amazon.com/contact-us/ec2-request/) ou esperar 20 minutos e reiniciar o cluster.
O Amazon S3 limita a cem o número de buckets criados em uma conta. Se o cluster criar um bucket novo que exceda esse limite, haverá falha na criação do bucket e poderá fazer com que haja uma falha no cluster.
## Verificar a configuração da sub-rede da Amazon VPC
Se o cluster foi iniciado em uma sub-rede da Amazon VPC, a sub-rede precisa ser configurada conforme descrito em [Configuração de redes em uma VPC no Amazon EMR](emr-plan-vpc-subnet.md). Além disso, verifique se a sub-rede na qual o cluster é iniciado tem endereços IP elásticos livres suficientes para atribuir um a cada nó do cluster.
## Reiniciar o cluster
A lentidão no processamento pode ser causada por uma condição transitória. Considere encerrar e reiniciar o cluster para ver se o desempenho melhora.
# Etapa 3: examinar os arquivos de log do cluster do Amazon EMR
A próxima etapa é examinar os arquivos de log para localizar um código de erro ou outra indicação do problema que o cluster enfrentou. Para obter informações sobre os arquivos de log disponíveis, onde encontrá-los e como visualizá-los, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
Pode ser necessário realizar algum trabalho investigativo para determinar o que aconteceu. O Hadoop executa o trabalho em tentativas de tarefa em múltiplos nós do cluster. O Amazon EMR pode iniciar tentativas de tarefa especulativas, terminado as outras tentativas de tarefa que não foram concluídas primeiro. Isso gera uma atividade considerável que é registrada nos arquivos de log controller, stderr e syslog quando isso acontece. Além disso, várias tentativas de tarefa são executadas simultaneamente, mas um arquivo de log só pode exibir os resultados de forma linear.
Comece verificando os logs de ações de bootstrap em busca de erros ou alterações inesperadas na configuração durante a inicialização do cluster. A partir daí, consulte os logs de etapas para identificar trabalhos do Hadoop iniciados como parte de uma etapa com erros. Examine os logs de trabalhos do Hadoop para identificar as tentativas de tarefa com falha. O logs de tentativas de tarefa conterá detalhes sobre o que causou a falha de uma tentativa de tarefa.
As seções a seguir descrevem como usar os diversos arquivos de log para identificar erros no cluster.
## Verificar os logs de ação de bootstrap
As ações de bootstrap executam scripts no cluster quando ele é iniciado. Geralmente são usados para instalar outros softwares no cluster ou para alterar as configurações com base nos valores padrão. Verificar esses logs pode fornecer insights sobre os erros que ocorreram durante a configuração do cluster, bem como das alterações nas configurações que podem afetar a performance.
## Verificar os logs de etapa
Há quatro tipos de logs de etapas.
+ **controller:** contém arquivos gerados pelo Amazon EMR (Amazon EMR) que surgem de erros encontrados ao tentar executar a etapa. Se a etapa falhar durante o carregamento, você encontrará o rastreamento da pilha nesse log. Os erros ao carregar ou acessar a aplicação muitas vezes são descritos aqui, assim como os erros ausentes do arquivo do mapeador.
+ **stderr:** contém mensagens de erro que ocorreram durante o processamento da etapa. Os erros de carregamento de aplicações muitas vezes são descritos aqui. Às vezes, esse log contém um rastreamento de pilha.
+ **stdout:** contém o status gerado pelos executáveis do mapeador e do redutor. Os erros de carregamento de aplicações muitas vezes são descritos aqui. Às vezes, o log contém mensagens de erro da aplicação.
+ **syslog:** contém registros de softwares que não são da Amazon, como Apache e Hadoop. Os erros de transmissão muitas vezes são descritos aqui.
Verifique se há erros óbvios em stderr. Se stderr exibe uma pequena lista de erros, a etapa foi interrompida rapidamente com um erro gerado. Isso geralmente é causado por um erro nas aplicações mapeadoras e redutoras que estão sendo executadas no cluster.
Verifique se há em avisos de erros ou falhas nas últimas linhas do controller e do syslog. Siga todos os avisos sobre tarefas que falharam, sobretudo se estiver escrito “Job Failed”.
## Verificar os logs de tentativa de tarefas
Se a análise anterior dos logs de etapas retornou uma ou mais tarefas com falha, investigue os logs das tentativas de tarefa correspondentes para obter informações mais detalhadas sobre o erro.
## Verificar os logs de daemons do Hadoop
Em casos raros, o Hadoop em si poderá falhar. Para ver se esse é o caso, é necessário examinar os logs do Hadoop. Eles estão localizados em cada nó do `/var/log/hadoop/`.
Você pode usar os JobTracker registros para mapear uma tentativa de tarefa malsucedida para o nó em que ela foi executada. Depois de conhecer o nó associado à tentativa de tarefa, verifique a integridade da instância do EC2 que hospeda esse nó para ver se houve algum problema, como falta de CPU ou de memória.
# Etapa 4: verificar a integridade do cluster e das instâncias do Amazon EMR
Um cluster do Amazon EMR é formado por nós em execução em instâncias do Amazon EC2. Se essas instâncias tornarem-se limitadas por recursos (por exemplo, se ficarem sem memória ou CPU), passarem por problemas de conectividade de rede ou forem encerradas, a velocidade de processamento do cluster será prejudicada.
Existem até três tipos de nós em um cluster:
+ **nó principal**: gerencia o cluster. Se ele sofrer um problema de desempenho, todo o cluster será afetado.
+ **nós core**: processam tarefas map/reduce e mantêm o Sistema de Arquivos Distribuído do Hadoop (HDFS). Se um dos nós passar por um problema de desempenho, isso poderá retardar as operações do HDFS, bem como o processamento de map/reduce. Você pode adicionar outros nós core a um cluster para melhorar o desempenho, mas não pode remover nós core. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md).
+ **nós de tarefa**: processam tarefas map/reduce. Estes são recursos puramente de computação e não armazenam dados. Você pode adicionar nós de tarefas a um cluster para acelerar o desempenho ou pode remover nós de tarefas que não são necessários. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md).
Ao examinar a integridade de um cluster, você deve considerar o desempenho do cluster como um todo, bem como o desempenho de instâncias individuais. Existem várias ferramentas que pode ser usadas:
## Verifique a integridade do cluster com CloudWatch
Cada cluster do Amazon EMR reporta métricas para. CloudWatch Essas métricas fornecem informações de desempenho resumidas sobre o cluster, como a carga total, a utilização do HDFS, as tarefas em execução, as tarefas restantes, os blocos corrompidos e muito mais. A análise das CloudWatch métricas fornece uma visão geral do que está acontecendo com seu cluster e pode fornecer informações sobre o que está causando a lentidão no processamento. Além de usar CloudWatch para analisar um problema de desempenho existente, você pode definir alarmes que CloudWatch causem alertas caso ocorra um problema de desempenho futuro. Para obter mais informações, consulte [Monitorando métricas do Amazon EMR com CloudWatch](UsingEMR_ViewingMetrics.md).
## Verificar a integridade do status do trabalho e do HDFS
Use as **Interfaces do usuário do aplicativo** na página de detalhes do cluster para visualizar os detalhes do aplicativo YARN. Para determinados aplicativos, você pode analisar diretamente os logs de acesso em mais detalhes. Isso é útil principalmente para aplicativos Spark. Para obter mais informações, consulte [Como exibir o histórico da aplicação do Amazon EMR](emr-cluster-application-history.md).
O Hadoop fornece uma série de interfaces Web que você pode usar para visualizar informações. Para obter mais informações sobre como acessar essas interfaces Web, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md).
+ JobTracker — fornece informações sobre o progresso do trabalho que está sendo processado pelo cluster. Você pode usar essa interface para identificar quando um trabalho ficou preso.
+ HDFS NameNode — fornece informações sobre a porcentagem de utilização do HDFS e o espaço disponível em cada nó. Você pode usar essa interface para identificar quando o HDFS está se tornando limitado por recursos e requer capacidade adicional.
+ TaskTracker — fornece informações sobre as tarefas do trabalho que está sendo processado pelo cluster. Você pode usar essa interface para identificar quando uma tarefa ficou presa.
## Verificar a integridade da instância com o Amazon EC2
Outra maneira de procurar informações sobre o status das instâncias no cluster é usar o console do Amazon EC2. Como cada nó do cluster é executado em uma instância do EC2, você pode usar as ferramentas fornecidas pelo Amazon EC2 para verificar seu status. Para obter mais informações, consulte [Visualizar instâncias de cluster no Amazon EC2](UsingEMR_Tagging.md).
# Etapa 5: verificar se há grupos suspensos
Um grupo de instâncias fica suspenso quando encontra muitos erros ao tentar executar nós. Por exemplo, se novos nós falharem repetidamente durante a execução de ações de bootstrap, depois de algum tempo, o grupo de instâncias entrará no estado `SUSPENDED` em vez de tentar provisionar continuamente novos nós.
Um nó poderá falhar se:
+ O Hadoop ou o cluster estiver de alguma forma com problemas e não aceitar um novo nó no cluster
+ Uma ação de bootstrap falhar no novo nó
+ O nó não estava funcionando corretamente e não conseguir fazer check-in no Hadoop
Se um grupo de instâncias estiver no estado `SUSPENDED`, e o cluster estiver em um estado `WAITING`, você poderá adicionar uma etapa de cluster para redefinir o número desejado de nós core e de tarefa. Adicionar a etapa retoma o processamento do cluster e coloca o grupo de instâncias em um estado `RUNNING`.
Para obter mais informações sobre como redefinir um cluster em um estado suspenso, consulte [Estado suspenso](emr-manage-resize.md#emr-manage-resizeSuspended).
# Etapa 6: revisar as configurações do cluster do Amazon EMR
Definições de configuração especificam detalhes sobre como um cluster é executado, como quantas vezes uma tarefa deve ser repetida e quanta memória está disponível para classificação. Quando você executa um cluster usando o Amazon EMR, existem configurações específicas do Amazon EMR, além das definições de configuração padrão do Hadoop. As definições de configuração são armazenadas no nó principal do cluster. Você pode verificar as definições de configuração para garantir que o cluster tenha os recursos necessários para um funcionamento eficiente.
O Amazon EMR define definições de configuração do Hadoop padrão que ele utiliza para iniciar um cluster. Os valores se baseiam na AMI e no tipo de instância que você especifica para o cluster. Você pode modificar os valores padrão das definições de configuração usando uma ação de bootstrap ou especificando novos valores em parâmetros de execução de trabalho. Para obter mais informações, consulte [Como criar ações de bootstrap para instalar softwares adicionais com um cluster do Amazon EMR](emr-plan-bootstrap.md). Para determinar se uma ação de bootstrap alterou as definições de configuração, verifique os logs dessa ação.
O Amazon EMR registra em log as configurações do Hadoop usadas para executar cada trabalho. Os dados de registro são armazenados em um arquivo nomeado no `job_job-id_conf.xml` `/mnt/var/log/hadoop/history/` diretório do nó principal, onde *job-id* são substituídos pelo identificador do trabalho. Se você habilitou o arquivamento de logs, esses dados são copiados para o Amazon S3 na pasta, *date* onde está `logs/date/jobflow-id/jobs` a data em que o trabalho foi executado *jobflow-id* e é o identificador do cluster.
As seguintes definições de configuração de trabalhos do Hadoop são especialmente úteis para investigar problemas de desempenho. Para obter mais informações sobre as definições de configuração do Hadoop e como elas afetam o comportamento do Hadoop, acesse [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/).
**Atenção**
Definir `dfs.replication` como 1 em clusters com menos de quatro nós poderá causar perda de dados do HDFS se um único nó ficar inativo. É recomendável usar um cluster com pelo menos quatro nós centrais para workloads de produção.
O Amazon EMR não permitirá que os clusters escalem os nós principais abaixo de `dfs.replication`. Por exemplo, se `dfs.replication = 2`, o número mínimo de nós central será 2.
Ao usar o Ajuste de Escala Gerenciado, o Auto Scaling ou optar por redimensionar manualmente o cluster, é recomendável definir `dfs.replication` como 2 ou mais.
| Definição da configuração | Description |
| --- | --- |
| dfs.replication | O número de nós HDFS para os quais um único bloco (como o bloco de disco rígido) é copiado a fim de produzir um ambiente semelhante ao RAID. Determina o número de nós HDFS que contêm uma cópia do bloco. |
| io.sort.mb | Total de memória disponível para classificação. Esse valor deve ser 10x io.sort.factor. Essa configuração também pode ser usada para calcular o total de memória usado pelo nó de tarefas, contando io.sort.mb multiplicado por mapred.tasktracker.ap.tasks.maximum. |
| io.sort.spill.percent | Usado durante a classificação, no momento em que o disco começa a ser usado porque a memória de classificação alocada está ficando cheia. |
| mapred.child.java.opts | Suspenso. Em vez disso, use mapred.map.child.java.opts e mapred.reduce.child.java.opts. As opções Java são TaskTracker usadas ao iniciar uma JVM para que uma tarefa seja executada nela. Um parâmetro comum é “-Xmx” para configurar o tamanho máximo da memória. |
| mapred.map.child.java.opts | As opções Java são TaskTracker usadas ao iniciar uma JVM para que uma tarefa de mapeamento seja executada nela. Um parâmetro comum é “-Xmx” para configurar o tamanho máximo do heap de memória. |
| mapred.map.tasks.speculative.execution | Determina se tentativas de tarefas map da mesma tarefa podem ser executadas em paralelo. |
| mapred.reduce.tasks.speculative.execution | Determina se tentativas de tarefas reduce da mesma tarefa podem ser executadas em paralelo. |
| mapred.map.max.attempts | O número máximo de vezes que uma tarefa map pode ser tentada. Se tudo falhar, a tarefa map será marcada como falha. |
| mapred.reduce.child.java.opts | As opções Java são TaskTracker usadas ao iniciar uma JVM para que uma tarefa reduzida seja executada nela. Um parâmetro comum é “-Xmx” para configurar o tamanho máximo do heap de memória. |
| mapred.reduce.max.attempts | O número máximo de vezes que uma tarefa reduce pode ser tentada. Se tudo falhar, a tarefa map será marcada como falha. |
| mapred.reduce.slowstart.completed.maps | A quantidade de tarefas map que devem ser concluídas antes que tarefas reduce sejam tentadas. Uma espera insuficiente pode causar erros “Too many fetch-failure” em tentativas. |
| mapred.reuse.jvm.num.tasks | Uma tarefa é executada em uma única JVM. Especifica quantas tarefas podem reutilizar a mesma JVM. |
| mapred.tasktracker.map.tasks.maximum | A quantidade máxima de tarefas que podem ser executadas em paralelo por nó de tarefa durante o mapeamento. |
| mapred.tasktracker.reduce.tasks.maximum | A quantidade máxima de tarefas que podem ser executadas em paralelo por nó de tarefa durante a redução. |
Se as suas tarefas de cluster consumirem muita memória, você poderá melhorar o desempenho usando menos tarefas por nó core e reduzindo seu tamanho do heap do rastreador de trabalhos.
# Etapa 7: examinar dados de entrada do cluster do Amazon EMR
Observe seus dados de entrada. Eles estão distribuídos uniformemente entre seus valores de chave? Se os seus dados estiverem fortemente desviados para um ou alguns valores de chave, a carga de processamento pode estar mapeada para um pequeno número de nós, enquanto outros nós estão ociosos. Essa distribuição desequilibrada de trabalho pode resultar em tempos de processamento mais lentos.
Um exemplo de um conjunto de dados desequilibrado seria executar um cluster para colocar palavras em ordem alfabética, mas ter um conjunto de dados contendo apenas palavras que começam com a letra "a". Quando o trabalho fosse mapeado, o nó processando valores que começam com "a" seria sobrecarregado, enquanto os nós processando palavras que começam com outras letras ficariam ociosos.