2010-04-16 14 views
11

Tengo un problema con Hadoop produciendo demasiados archivos de registro en $ HADOOP_LOG_DIR/userlogs (el sistema de archivos Ext3 solo permite 32000 subdirectorios) que se ve como el mismo problema en esta pregunta: Error in Hadoop MapReduceConfigurar el registro de Hadoop para evitar demasiados archivos de registro

Mi pregunta es: ¿Alguien sabe cómo configurar Hadoop para rodar el directorio de registro o evitarlo? Intento evitar simplemente establecer las propiedades "mapred.userlog.retain.hours" y/o "mapred.userlog.limit.kb" porque quiero conservar realmente los archivos de registro.

También esperaba configurar esto en log4j.properties, pero mirando el origen de Hadoop 0.20.2, escribe directamente en los archivos de registro en lugar de usar log4j. Quizás no entiendo cómo se usa log4j por completo.

Cualquier sugerencia o aclaraciones sería muy apreciada.

Respuesta

4

Por desgracia, no es una forma configurable para evitar eso. Cada tarea para un trabajo obtiene un directorio en el historial/registros de usuario, que contendrá los archivos de salida del registro de tareas stdout, stderr y syslog. Las horas de retención ayudarán a evitar que muchas de ellas se acumulen, pero tendría que escribir una buena herramienta de rotación de registros para auto-tar.

También tuvimos este problema cuando escribíamos en un montaje NFS, porque todos los nodos compartirían el mismo directorio de historial/registro de usuarios. Esto significa que un trabajo con 30,000 tareas sería suficiente para romper el FS. El inicio de sesión local es realmente el camino a seguir cuando su clúster realmente comienza a procesar una gran cantidad de datos.

Si ya está iniciando sesión localmente y aún logra procesar más de 30,000 tareas en una máquina en menos de una semana, entonces probablemente esté creando demasiados archivos pequeños, lo que hace que se generen demasiados mapeadores para cada trabajo.

+0

Así que he encontrado :) Nuestra solución es modificar nuestro proceso de recopilación de datos para concatenar archivos antes de ejecutar cualquier trabajo. –

1

De acuerdo con la documentación, Hadoop uses log4j for logging. Quizás esté interesado en el lugar equivocado ...

+0

veo que Hadoop incluye log4j, pero mirando el código fuente, parece que se escribe directamente en el archivo de registro en lugar de utilizar log4j correctamente. Cambiar las propiedades de log4j no parece funcionar debido a esto. –

+0

@Eric Wendelin ¿puede proporcionar un enlace al archivo de origen donde parece estar ocurriendo esto? –

5

tenía este mismo problema. Establezca la variable de entorno "HADOOP_ROOT_LOGGER = WARN, consola" antes de iniciar Hadoop.

export HADOOP_ROOT_LOGGER="WARN,console" 
hadoop jar start.jar 
+0

¿Podría explicarme qué hace eso? ¿Pierdo algo si hago eso? –

+0

Desafortunadamente, cuando se presenta exactamente el mismo problema, esta solución no funciona. Enmascara el nivel de salida, pero no impide que Hadoop escriba 32,000 subdirectorios en la carpeta de registros de usuario de cada nodo. – MrGomez

2

Configuración hadoop usar log4j y el establecimiento de

log4j.appender.FILE_AP1.MaxFileSize=100MB 
log4j.appender.FILE_AP1.MaxBackupIndex=10 

como se describe en la this wiki page no funciona?

Al mirar el LogLevel source code, parece que hadoop usa el registro de commons, y tratará de usar log4j por defecto, o jdk logger si log4j no está en el classpath.

Por cierto, es posible cambiar los niveles de registro en el tiempo de ejecución, eche un vistazo a commands manual.

0

También corrí en el mismo problema ... Hive produce una gran cantidad de registros, y cuando el nodo del disco está lleno, no se pueden lanzar más contenedores. En Yarn, actualmente no hay ninguna opción para deshabilitar el registro. Un archivo particularmente grande es el archivo syslog, que genera GB de registros en pocos minutos en nuestro caso.

Configurando en "yarn-site.xml" la propiedad yarn.nodemanager.log.retain-seconds a un valor pequeño no ayuda. No es posible establecer "yarn.nodemanager.log-dirs" en "file: /// dev/null" porque se necesita un directorio. La eliminación de la escritura de ritmos (chmod -r/logs) tampoco funcionó.

Una solución podría ser la de un directorio "agujero negro nula".Compruebe aquí: https://unix.stackexchange.com/questions/9332/how-can-i-create-a-dev-null-like-blackhole-directory

Otra solución que nos funciona es desactivar el registro antes de ejecutar los trabajos. Por ejemplo, en la colmena, a partir de la secuencia de comandos mediante las siguientes líneas está trabajando:

set yarn.app.mapreduce.am.log.level=OFF; 
set mapreduce.map.log.level=OFF; 
set mapreduce.reduce.log.level=OFF; 
Cuestiones relacionadas