Por que o nó central do meu cluster do Amazon EMR está ficando sem espaço em disco?
Estou executando trabalhos do Apache Spark em um cluster do Amazon EMR e o nó central está quase sem espaço em disco.
Resolução
Determine quais nós centrais não estão íntegros
Os nós que têm pelo menos um volume do Amazon Elastic Block Store (Amazon EBS) conectado são considerados não íntegros se atingirem mais de 90% de utilização do disco. Para determinar quais nós podem ter atingido 90% de utilização do disco, faça o seguinte:
1. Verifique a métrica MRUnhealthyNodes do Amazon CloudWatch. Essa métrica indica o número de nós não íntegros de um cluster do EMR.
**Observação:**Você pode criar um Alarme do CloudWatch para monitorar a métrica MRunHealthyNodes.
2. Conecte-se ao nó primário e acesse o log do controlador de instância em /emr/instance-controller/log/instance-controller.log. No log do controlador de instância, pesquise instanceJointStatusMap para identificar quais nós não estão íntegros.
Para obter mais informações, consulte Alta utilização do disco em Como resolver erros ExecutorLostFailure de “Perda de escravo” do Spark no Amazon EMR?
3. Faça login nos nós principais e execute o seguinte comando para determinar se uma montagem tem alta utilização:
df -h
Remova arquivos temporários e locais desnecessários do aplicativo Spark
Quando você executa trabalhos do Spark, os aplicativos Spark criam arquivos locais que consomem o restante do espaço em disco no nó central. Se o comando df -h mostrar que /mnt, por exemplo, está usando mais de 90% de espaço em disco, verifique quais diretórios ou arquivos têm alta utilização.
Execute o comando a seguir no nó principal para ver os dez principais diretórios que estão usando mais espaço em disco:
cd /mnt sudo du -hsx * | sort -rh | head -10
Se o diretório /mnt/hdfs tiver alta utilização, verifique o uso do HDFS e remova todos os arquivos desnecessários, como arquivos de log. Reduzir o período de retenção ajuda a limpar automaticamente os arquivos de log do HDFS.
hdfs dfsadmin -report hadoop fs -du -s -h /path/to/dir
Reduza o período de retenção dos logs de eventos do Spark e do contêiner YARN
Uma causa comum do uso do HDFS é o diretório /var/log. O diretório**/var/log** é onde os arquivos de log, como logs de eventos do Spark e logs de contêineres do YARN, são armazenados. Você pode alterar o período de retenção desses arquivos para economizar espaço.
O exemplo de comando a seguir exibe o uso de /var/log/spark.
Observação: /var/log/spark é o diretório padrão de logs de eventos do Spark.
hadoop fs -du -s -h /var/log/spark
Reduza o período de retenção padrão dos arquivos de histórico de trabalhos do Spark
Os arquivos de histórico de trabalhos do Spark estão localizados em /var/log/spark/apps por padrão. Quando o limpador de histórico do sistema de arquivos é executado, o Spark exclui arquivos do histórico de trabalhos com mais de sete dias. Para reduzir o período de retenção padrão, faça o seguinte:
Em um cluster em execução:
1. Conecte-se ao nó primário usando SSH.
2. Adicione ou atualize os seguintes valores em /etc/spark/conf/spark-defaults.conf. A configuração a seguir executa o limpador a cada 12 horas. A configuração limpa arquivos com mais de 1 dia. Você pode personalizar esse período para seu caso de uso individual nos parâmetros spark.history.fs.cleaner.internval e spark.history.fs.cleaner.maxAge.
------ spark.history.fs.cleaner.enabled true spark.history.fs.cleaner.interval 12h spark.history.fs.cleaner.maxAge 1d ------
3. Reinicie o Servidor de histórico do Spark.
Durante a inicialização do cluster:
Use a configuração a seguir. Você pode personalizar o período para seu caso de uso individual nos parâmetros spark.history.fs.cleaner.internval e spark.history.fs.cleaner.maxAge.
{ "Classification": "spark-defaults", "Properties": { "spark.history.fs.cleaner.enabled":"true", "spark.history.fs.cleaner.interval":"12h", "spark.history.fs.cleaner.maxAge":"1d" } }
Para obter mais informações sobre esses parâmetros, consulte Monitoramento e instrumentação na documentação do Spark.
Reduza o período de retenção padrão dos logs de contêiner do YARN
Os logs do aplicativo Spark, que são os logs de contêiner do YARN dos trabalhos do Spark, estão localizados em /var/log/hadoop-yarn/apps no nó principal. O Spark move esses logs para o HDFS quando o aplicativo termina de ser executado. Por padrão, o YARN mantém logs de aplicativos no HDFS por 48 horas. Para reduzir o período de retenção:
1. Conecte-se aos nós primário, central ou de tarefa usando SSH.
2. Abra o arquivo /etc/hadoop/conf/yarn-site.xml em cada nó do seu cluster do Amazon EMR (nós primário, central e de tarefa).
3. Reduza o valor da propriedade yarn.log-aggregation.retain-seconds em todos os nós.
4. Reinicie o daemon ResourceManager. Para obter mais informações, consulte Como visualizar e reiniciar o Amazon EMR e processos de aplicação.
Você também pode reduzir o período de retenção reconfigurando o cluster. Para obter mais informações, consulte Reconfigurar um grupo de instâncias em um cluster em execução.
Reduza o uso de /mnt/yarn
Se o diretório /mnt/yarn for muito utilizado, ajuste a retenção do cache do usuário ou ajuste a escala dos volumes do EBS no nó. Para obter mais informações, consulte Como evitar que o cache do usuário de um trabalho do Hadoop ou do Spark consuma muito espaço em disco no Amazon EMR?
Redimensione o cluster ou ajuste a escala do Amazon EMR
Adicione mais nós centrais para mitigar os problemas de espaço do HDFS. Além disso, adicione qualquer um dos nós centrais ou de tarefa se os diretórios que não sejam os diretórios do HDFS estiverem ficando cheios. Para obter mais informações, consulte Como ajustar a escala de recursos do cluster.
Você também pode estender os volumes do EBS em nós existentes ou usar um script de escalabilidade dinâmica. Para obter mais informações, consulte:
- Como resolver falhas de estágio “não há mais espaço no dispositivo” no Spark no Amazon EMR?
- Aumente a escala verticalmente de forma dinâmica do armazenamento em clusters do Amazon EMR
Informações relacionadas
Conteúdo relevante
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 3 anos