Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Solución de problemas de un clúster de Amazon EMR lento Esta sección describe el proceso de solución de problemas de un clúster que sigue en ejecución, pero que tarda mucho en devolver los resultados. Para obtener más información sobre qué hacer si el clúster ha terminado con un código de error, consulte [Solución de problemas de un clúster de Amazon EMR que ha fallado con un código de error](emr-troubleshoot-failed.md) Amazon EMR le permite especificar el número y el tipo de instancias en el clúster. Estas especificaciones son los medios principales que afectan a la velocidad con que la que se completa el procesamiento de datos. Una cosa que debería tener en cuenta es volver a ejecutar el clúster, esta vez especificando instancias de EC2 con más recursos o especificar un número mayor de instancias en el clúster. Para obtener más información, consulte [Configuración del hardware y las redes de los clústeres de Amazon EMR](emr-plan-instances.md). Los siguientes temas le guiarán a través del proceso de identificación de causas alternativas de un clúster lento. **Topics** + [Paso 1: recopile datos sobre el problema con el clúster de Amazon EMR](emr-troubleshoot-slow-1.md) + [Paso 2: compruebe el entorno del clúster de Amazon EMR](emr-troubleshoot-slow-2.md) + [Paso 3: examine los archivos de registro del clúster de Amazon EMR](emr-troubleshoot-slow-3.md) + [Paso 4: compruebe el estado de la instancia y el clúster de Amazon EMR](emr-troubleshoot-slow-4.md) + [Paso 5: comprobar si hay grupos suspendidos](emr-troubleshoot-slow-5.md) + [Paso 6: revise los ajustes de configuración del clúster de Amazon EMR](emr-troubleshoot-slow-6.md) + [Paso 7: examine los datos de entrada del clúster de Amazon EMR](emr-troubleshoot-slow-7.md) # Paso 1: recopile datos sobre el problema con el clúster de Amazon EMR El primer paso para solucionar problemas de un clúster es recopilar información sobre lo que ha fallado y el estado y la configuración actuales del clúster. Esta información se utilizará en los siguientes pasos para confirmar o descartar las posibles causas del problema. ## Definir el problema Una definición clara del problema es el primer punto de partida. Algunas preguntas que debe hacerse: + ¿Qué esperaba que sucediera? ¿Qué pasó en su lugar? + ¿Cuándo se produjo este problema por primera vez? ¿Con qué frecuencia ha ocurrido desde entonces? + ¿Ha cambiado algo en la forma en que configuro o ejecuto mi clúster? ## Detalles de clúster Los siguientes detalles del clúster son útiles para ayudar a detectar problemas. Para obtener más información sobre cómo recopilar esta información, consulte [Visualización del estado y los detalles del clúster de Amazon EMR](emr-manage-view-clusters.md). + El identificador del clúster. (También se denomina identificador de flujo de tareas). + Región de AWS y la zona de disponibilidad en la que se lanzó el clúster. + El estado del clúster, incluidos los detalles del último cambio de estado. + Tipo y número de instancias de EC2 especificados para los nodos maestro, principal y de tarea. # Paso 2: compruebe el entorno del clúster de Amazon EMR Compruebe su entorno para ver si hay interrupciones en el servicio o si ha superado un límite de AWS servicio. **Topics** + [Comprobar las interrupciones de servicio](#emr-troubleshoot-slow-2-outages) + [Comprobar los límites de uso](#emr-troubleshoot-slow-2-limits) + [Comprobar la configuración de subredes de Amazon VPC](#emr-troubleshoot-slow-2-vpc) + [Reiniciar el clúster](#emr-troubleshoot-slow-2-restart) ## Comprobar las interrupciones de servicio Amazon EMR utiliza varios servicios de Amazon Web Services internamente. Ejecuta servidores virtuales en Amazon EC2, almacena datos y scripts en Amazon S3 e informa de las métricas a. CloudWatch Los eventos que interrumpen estos servicios son poco frecuentes, pero, cuando se producen, pueden provocar problemas en Amazon EMR. Antes de continuar, compruebe el [Panel de estado del servicio](https://status.aws.amazon.com/). Compruebe la región en la que lanzó el clúster para ver si hay interrupciones en alguno de estos servicios. ## Comprobar los límites de uso Si va a lanzar un clúster grande, ha lanzado varios clústeres simultáneamente o es un usuario que comparte uno Cuenta de AWS con otros usuarios, es posible que el clúster haya fallado porque ha superado un límite de AWS servicio. Amazon EC2 limita el número de instancias de servidores virtuales que se ejecutan en una sola AWS región a 20 instancias reservadas o bajo demanda. Si lanza un clúster con más de 20 nodos o lanza un clúster que hace que el número total de instancias de EC2 activas en la suya Cuenta de AWS supere las 20, el clúster no podrá lanzar todas las instancias de EC2 que necesita y podría fallar. Cuando esto ocurre, Amazon EMR devuelve un error `EC2 QUOTA EXCEEDED`. Puede solicitar que se AWS aumente el número de instancias EC2 que puede ejecutar en su cuenta enviando una [solicitud para aumentar el límite de instancias de Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/). Otro factor que puede provocar que supere los límites de uso es el retraso que transcurre entre la finalización de un clúster y el momento en que libera todos sus recursos. En función de las diferencias de configuración, un clúster puede tardar entre 5 y 20 minutos terminar por completo y liberar los recursos asignados. Si aparece un error `EC2 QUOTA EXCEEDED` al intentar lanzar un clúster, puede deberse a que aún no se hayan liberado los recursos de un clúster terminado recientemente. En este caso, puede [solicitar un aumento de la cuota de Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/) o puede esperar 20 minutos y volver a lanzar el clúster. Amazon S3 limita el número de buckets creados en una cuenta a 100. Si el clúster crea un bucket nuevo que supera este límite, se producirá un error en la creación del bucket y es posible que el clúster falle. ## Comprobar la configuración de subredes de Amazon VPC Si el clúster se lanzó en una subred de Amazon VPC, la subred debe configurarse como se describe en [Configuración de redes en una VPC para Amazon EMR](emr-plan-vpc-subnet.md). Además, compruebe que la subred en la que lanza el clúster tenga suficientes direcciones IP elásticas libres para asignar una a cada nodo del clúster. ## Reiniciar el clúster La ralentización de procesamiento puede deberse a una condición transitoria. Plantéese terminar y reiniciar el clúster para ver si el rendimiento mejora. # Paso 3: examine los archivos de registro del clúster de Amazon EMR El siguiente paso consiste en examinar los archivos de registro para encontrar un código de error u otro indicio del problema que ha sufrido el clúster. Para obtener información sobre los archivos de registro disponibles, dónde encontrarlos y cómo verlos, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md). Es posible que sea necesario un poco de trabajo de investigación para determinar qué pasó. Hadoop ejecuta los trabajos en los intentos de tareas en varios nodos del clúster. Amazon EMR puede iniciar intentos de tareas especulativos y terminar los demás intentos de tareas que no se completen primero. Esto genera una actividad importante que se registra en los archivos de registro del controlador, stderr y syslog a medida que se produce. Además, se ejecutan varios intentos de tareas simultáneamente, pero un archivo de registro solo puede mostrar los resultados de forma lineal. Para comenzar, compruebe los registros de acciones de arranque para ver si hay errores o cambios de configuración inesperados durante el lanzamiento del clúster. A partir de ahí, consulte los registros de pasos para identificar los trabajos de Hadoop lanzados como parte de un paso con errores. Examine los registros de trabajos de Hadoop para identificar los intentos fallidos de tareas. El registro de intentos de tarea contendrá detalles sobre la causa del error de un intento de tarea. En las siguientes secciones, se describe cómo utilizar los distintos archivos de registro para identificar errores en el clúster. ## Comprobar los registros de acción de arranque Las acciones de arranque ejecutan scripts en el clúster a medida que se lanza. Por lo general, se utilizan para instalar software adicional en el clúster o para modificar los valores predeterminados de los valores de configuración. La comprobación de estos registros puede proporcionar información sobre los errores que se produjeron durante la configuración del clúster, así como sobre los cambios en los ajustes de configuración que podrían afectar al rendimiento. ## Comprobar los registros de pasos Hay cuatro tipos de registros de pasos. + **controlador:** contiene archivos generados por Amazon EMR (Amazon EMR) que se deben a errores encontrados al intentar ejecutar el paso. Si se produce un error en el paso durante la carga, puede encontrar el registro de seguimiento de la pila en este registro. Aquí se describen con frecuencia los errores al cargar la aplicación o al acceder a ella, así como los errores que faltan en el archivo de asignación. + **stderr:** contiene los mensajes de error que se produjeron al procesar el paso. Los errores de carga de la aplicación se describen a menudo aquí. En ocasiones, este registro contiene un seguimiento de pila. + **stdout:** contiene el estado generado por los ejecutables de asignación y reducción. Los errores de carga de la aplicación se describen a menudo aquí. En ocasiones, este registro contiene mensajes de error de la aplicación. + **syslog:** contiene registros de software ajeno a Amazon, como Apache y Hadoop. Los errores de streaming suelen describirse aquí. Compruebe si hay errores obvios en stderr. Si stderr muestra una lista corta de errores, el paso se detuvo rápidamente y se produjo un error. En la mayoría de los casos, esto se debe a un error en las aplicaciones de asignación y reducción que se ejecutan en el clúster. Examine las últimas líneas del controlador y de syslog en busca de avisos de errores. Siga cualquier aviso sobre tareas con errores, especialmente si dice “Trabajo con errores”. ## Comprobar los registros de intento de tarea Si el análisis anterior de los registros de pasos reveló una o más tareas fallidas, investigue los registros de los intentos de tareas correspondientes para obtener información de error más detallada. ## Comprobar los registros de daemon de Hadoop En raras ocasiones, Hadoop podría fallar. Para comprobar si ese es el caso, consulte los registros de Hadoop. Están ubicados en `/var/log/hadoop/` en cada nodo. Puede utilizar los JobTracker registros para asignar un intento de tarea fallido al nodo en el que se ejecutó. Una vez que conozca el nodo asociado al intento de tarea, puede comprobar el estado de la instancia de EC2 que aloja ese nodo para comprobar si se ha producido algún problema, por ejemplo, si se ha quedado sin CPU o memoria. # Paso 4: compruebe el estado de la instancia y el clúster de Amazon EMR Un clúster de Amazon EMR se compone de nodos que se ejecutan en instancias de Amazon EC2. Si dichas instancias se ven limitadas por los recursos (como, por ejemplo, quedarse sin CPU o memoria), tienen problemas de conectividad de red o se terminan, la velocidad de procesamiento del clúster se resiente. Existen hasta tres tipos de nodos en un clúster: + **nodo maestro**: administra el clúster. Si experimenta problemas de rendimiento, se ve afectado todo el clúster. + **nodos principales**: procesan tareas de map-reduce y mantienen Hadoop Distributed FileSystem (HDFS). Si uno de estos nodos experimenta un problema de rendimiento, puede ralentizar las operaciones de HDFS, así como el procesamiento de MapReduce. Puede añadir más nodos secundarios a un clúster para mejorar el rendimiento, pero no puede eliminar nodos secundarios. Para obtener más información, consulte [Cambio manual del tamaño de un clúster de Amazon EMR en ejecución](emr-manage-resize.md). + **nodos de tareas**: procesan tareas map-reduce. Se trata exclusivamente de recursos informáticos y no almacenan datos. Puede añadir nodos de tareas a un clúster para acelerar el rendimiento o eliminar los nodos de tareas que no sean necesarios. Para obtener más información, consulte [Cambio manual del tamaño de un clúster de Amazon EMR en ejecución](emr-manage-resize.md). Al examinar el estado de un clúster, debe examinar tanto el rendimiento global del clúster, así como el rendimiento de instancias concretas. Existen varias herramientas que puede utilizar: ## Compruebe el estado del clúster con CloudWatch Cada clúster de Amazon EMR informa de las métricas a. CloudWatch Estas métricas proporcionan información sobre el rendimiento de resumen acerca del clúster, como la carga total, utilización de HDFS, ejecución de tareas, tareas restante, bloques corruptos, etc. Al analizar las CloudWatch métricas, tendrá una idea general de lo que está sucediendo con su clúster y puede proporcionar información sobre las causas de la ralentización del procesamiento. Además de usarlo CloudWatch para analizar un problema de rendimiento existente, puede configurar alarmas que emitan alertas si se produce un problema de rendimiento en el futuro. CloudWatch Para obtener más información, consulte [Supervisión de las métricas de Amazon EMR con CloudWatch](UsingEMR_ViewingMetrics.md). ## Comprobar el estado del trabajo y de HDFS Utilice la pestaña **Interfaces de usuario de aplicaciones** de la página de detalles del clúster para ver los detalles de las aplicaciones de YARN. Para determinadas aplicaciones, puede consultar información adicional y tener acceso a los logs directamente. Esto resulta especialmente útil para las aplicaciones Spark. Para obtener más información, consulte [Visualización del historial de aplicaciones de Amazon EMR](emr-cluster-application-history.md). Hadoop proporciona una serie de interfaces web que puede utilizar para ver información. Para obtener más información sobre cómo acceder a estas interfaces web, consulte [Ver las interfaces web alojadas en clústeres de Amazon EMR](emr-web-interfaces.md). + JobTracker — proporciona información sobre el progreso del trabajo que está procesando el clúster. Puede utilizar esta interfaz para identificar si se ha bloqueado un trabajo. + HDFS NameNode : proporciona información sobre el porcentaje de uso de HDFS y el espacio disponible en cada nodo. Puede utilizar esta interfaz para identificar cuando HDFS se ve limitado por los recursos y requiere capacidad adicional. + TaskTracker — proporciona información sobre las tareas del trabajo que está procesando el clúster. Puede utilizar esta interfaz para identificar cuando se ha bloqueado una tarea. ## Comprobar el estado de la instancia con Amazon EC2 Otra forma de buscar información sobre el estado de las instancias en el clúster consiste en utilizar la consola de Amazon EC2. Dado que cada nodo del clúster se ejecuta en una instancia de EC2, puede utilizar las herramientas proporcionadas por Amazon EC2 para comprobar su estado. Para obtener más información, consulte [Ver instancias del clúster en Amazon EC2](UsingEMR_Tagging.md). # Paso 5: comprobar si hay grupos suspendidos Un grupo de instancias queda suspendido cuando encuentra demasiados errores al intentar lanzar nodos. Por ejemplo, si nodos nuevos devuelven error repetidamente al llevar a cabo acciones de arranque, el grupo de instancias, después de un tiempo, pasará al estado `SUSPENDED` en lugar intentar de forma continua aprovisionar nuevos nodos. Un nodo podría no cargarse si: + Hadoop o el clúster están estropeados por algún motivo y no aceptan un nuevo nodo en el clúster + Una acción de arranque falla en el nuevo nodo + El nodo no funciona correctamente y no puede iniciar sesión con Hadoop Si un grupo de instancias está en estado `SUSPENDED` y el clúster está en estado `WAITING`, puede añadir un paso de clúster para restablecer el número deseado de nodos secundarios y de tareas. Al añadir el paso se reanuda el procesamiento del clúster y coloca el grupo de instancias de nuevo en estado `RUNNING`. Para obtener más información sobre cómo restablecer un clúster en estado suspendido, consulte [Estado de suspensión](emr-manage-resize.md#emr-manage-resizeSuspended). # Paso 6: revise los ajustes de configuración del clúster de Amazon EMR Los ajustes de configuración especifican detalles acerca de cómo se ejecuta un clúster, como cuántas veces se vuelve a intentar una tarea y la cantidad de memoria que hay disponible para clasificación. Al lanzar un clúster con Amazon EMR, existen ajustes específicos de Amazon EMR además de los ajustes de configuración estándar de Hadoop. Los ajustes de configuración se almacenan en el nodo principal del clúster. Puede comprobar los ajustes de configuración para asegurarse de que su clúster tenga los recursos que necesita para ejecutarse de forma eficaz. Amazon EMR define los ajustes de configuración de Hadoop predeterminados que utiliza para lanzar un clúster. Los valores se basan en la AMI y el tipo de instancia que especifique para el clúster. Puede modificar los ajustes de configuración a partir de los valores predeterminados mediante una acción de arranque o especificando nuevos valores en parámetros de ejecución de trabajo. Para obtener más información, consulte [Creación de acciones de arranque para instalar software adicional con un clúster de Amazon EMR](emr-plan-bootstrap.md). Para determinar si una acción de arranque ha cambiado los ajustes de configuración, compruebe los registros de la acción de arranque. Amazon EMR registra los ajustes de Hadoop utilizados para ejecutar cada trabajo. Los datos de registro se almacenan en un archivo `job_job-id_conf.xml` denominado en el `/mnt/var/log/hadoop/history/` directorio del nodo principal, donde *job-id* se sustituyen por el identificador del trabajo. Si ha activado el archivado de registros, estos datos se copian en Amazon S3 en la `logs/date/jobflow-id/jobs` carpeta, donde aparece la fecha en que *date* se ejecutó el trabajo y *jobflow-id* es el identificador del clúster. Los siguientes ajustes de configuración de trabajo de Hadoop son especialmente útiles para investigar los problemas de rendimiento. Para obtener más información acerca de los ajustes de configuración de Hadoop y cómo afectan al comportamiento de Hadoop, visite [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/). **aviso** Establecer `dfs.replication` en 1 en clústeres con menos de cuatro nodos puede conllevar la pérdida de datos del HDFS si un solo nodo deja de funcionar. Se recomienda que utilice un clúster con al menos cuatro nodos principales para las cargas de trabajo de producción. Amazon EMR no permitirá que los clústeres escalen los nodos principales por debajo de `dfs.replication`. Por ejemplo, si `dfs.replication = 2`, el número mínimo de nodos principales es 2. Cuando utiliza el escalado administrado, el escalado automático o decide cambiar el tamaño del clúster manualmente, se recomienda que establezca `dfs.replication` en 2 o más. | Opción de configuración | Description (Descripción) | | --- | --- | | dfs.replication | El número de nodos de HDFS en los que un bloque único (como el bloque de disco duro) se copian para producir un entorno similar a RAID. Determina el número de nodos de HDFS que contienen una copia del bloque. | | io.sort.mb | Memoria total disponible para clasificación. Este valor debería ser 10x io.sort.factor. Este ajuste también puede utilizarse para calcular la memoria total utilizada por el nodo de tareas calculando io.sort.mb multiplicado por mapred.tasktracker.ap.tasks.maximum. | | io.sort.spill.percent | Utilizado durante la clasificación, momento en que el disco empezará a utilizarse porque la memoria de clasificación asignada se está llenando. | | mapred.child.java.opts | Obsoleto. Utilice mapred.map.child.java.opts y mapred.reduce.child.java.opts en su lugar. Las opciones de Java que se TaskTracker utilizan al lanzar una JVM para ejecutar una tarea en ella. Un parámetro común es “-Xmx” para configurar el tamaño de memoria máximo. | | mapred.map.child.java.opts | Las opciones de Java se TaskTracker utilizan al lanzar una JVM para ejecutar una tarea de mapa en ella. Un parámetro común es “-Xmx” para configurar el tamaño de montón de memoria máximo. | | mapred.map.tasks.speculative.execution | Determina si los intentos de tarea Map de la misma tarea se pueden lanzar en paralelo. | | mapred.reduce.tasks.speculative.execution | Determina si los intentos de tarea Reduce de la misma tarea se pueden lanzar en paralelo. | | mapred.map.max.attempts | El número máximo de veces que se puede intentar una tarea Map. Si todos fallan, entonces la tarea Map se marca como error. | | mapred.reduce.child.java.opts | Las opciones de Java que se TaskTracker utilizan al lanzar una JVM reducen la cantidad de tareas que se pueden ejecutar en ella. Un parámetro común es “-Xmx” para configurar el tamaño de montón de memoria máximo. | | mapred.reduce.max.attempts | El número máximo de veces que se puede intentar una tarea Reduce. Si todos fallan, entonces la tarea Map se marca como error. | | mapred.reduce.slowstart.completed.maps | La cantidad de tareas Map que deben completar antes de intentar las tareas Reduce. Si no se espera lo suficiente, se podrían devolver errores “Demasiados errores de recuperación” en los intentos. | | mapred.reuse.jvm.num.tasks | Una tarea se ejecuta dentro de una única JVM. Especifica cuántas tareas podría reutilizar la misma JVM. | | mapred.tasktracker.map.tasks.maximum | La cantidad máxima de tareas que se pueden ejecutar en paralelo por nodo de tareas durante el mapeo. | | mapred.tasktracker.reduce.tasks.maximum | La cantidad máxima de tareas que se pueden ejecutar en paralelo por nodo de tareas durante la reducción. | Si las tareas de clúster utilizan mucha memoria, puede mejorar el rendimiento utilizando menos tareas por nodo secundario y reduciendo el tamaño de montón de rastreador de trabajos. # Paso 7: examine los datos de entrada del clúster de Amazon EMR Compruebe los datos de entrada. ¿Están distribuidos de manera uniforme entre los valores clave? Si los datos están muy sesgados hacia uno o varios valores clave, la carga de procesamiento podría estar asignada a un pequeño número de nodos, mientras que los demás nodos están inactivos. Esta distribución desequilibrada de trabajo puede dar lugar a tiempos de procesamiento más lentos. Un ejemplo de conjunto de datos desequilibrado sería la ejecución de un clúster para alfabetizar palabras, pero disponer de un conjunto de datos que contenga solo palabras que comienzan con la letra "a". Cuando el trabajo se ha planificado, los valores de procesamiento del nodo que comienzan por "a" serían abrumadores, mientras que los nodos que procesan palabras que comienzan por otras letras estarían inactivos.