¿Cuál es la relación entre ''mapreduce.map.memory.mb'' y ''mapred.map.child.java.opts'' en Apache Hadoop YARN?
configuration heap-size (2)
Me gustaría saber la relación entre los parámetros mapreduce.map.memory.mb y mapred.map.child.java.opts .
¿ mapreduce.map.memory.mb > mapred.map.child.java.opts ?
Gracias, Kewal.
Las siguientes propiedades le permiten especificar opciones para pasar a las JVM que ejecutan sus tareas. Estos se pueden usar con -Xmx para controlar el montón disponible .
Hadoop 0.x, 1.x (deprecated) Hadoop 2.x
------------------------------- --------------------------
mapred.child.java.opts
mapred.map.child.java.opts mapreduce.map.java.opts
mapred.reduce.child.java.opts mapreduce.reduce.java.opts
Tenga en cuenta que no hay un equivalente directo de Hadoop 2 para el primero de ellos; el consejo en el código fuente es usar los otros dos. mapred.child.java.opts todavía es compatible (pero está reemplazado por las otras dos configuraciones más específicas si están presentes).
Complementariamente a esto, lo siguiente le permite limitar la memoria total (posiblemente virtual) disponible para sus tareas, incluidas las definiciones de montón, pila y clase:
Hadoop 0.x, 1.x (deprecated) Hadoop 2.x
------------------------------- --------------------------
mapred.job.map.memory.mb mapreduce.map.memory.mb
mapred.job.reduce.memory.mb mapreduce.reduce.memory.mb
Sugiero configurar -Xmx al 75% de los valores de memory.mb .
En un clúster YARN, los trabajos no deben usar más memoria que la configuración del lado del servidor yarn.scheduler.maximum-allocation-mb o se yarn.scheduler.maximum-allocation-mb .
Para verificar los valores predeterminados y la precedencia de estos, consulte JobConf y MRJobConfig en el código fuente de Hadoop.
Solución de problemas
Recuerde que su mapred-site.xml puede proporcionar valores predeterminados para estas configuraciones. Esto puede ser confuso; por ejemplo, si su trabajo establece mapred.child.java.opts programáticamente, esto no tendría efecto si mapred-site.xml establece mapreduce.map.java.opts o mapreduce.reduce.java.opts . Debería establecer esas propiedades en su trabajo, para anular el mapred-site.xml. Verifique la página de configuración de su trabajo (busque ''xmx'') para ver qué valores se han aplicado y de dónde provienen.
Memoria de ApplicationMaster
En un clúster YARN, puede usar las siguientes dos propiedades para controlar la cantidad de memoria disponible para su ApplicationMaster (para guardar detalles de divisiones de entrada, estado de las tareas, etc.):
Hadoop 0.x, 1.x Hadoop 2.x
------------------------------- --------------------------
yarn.app.mapreduce.am.command-opts
yarn.app.mapreduce.am.resource.mb
Nuevamente, puede establecer -Xmx (en el primero) al 75% del valor de resource.mb .
Otras configuraciones
Hay muchas otras configuraciones relacionadas con los límites de memoria, algunas de ellas obsoletas: consulte la clase JobConf . Una útil:
Hadoop 0.x, 1.x (deprecated) Hadoop 2.x
------------------------------- --------------------------
mapred.job.reduce.total.mem.bytes mapreduce.reduce.memory.totalbytes
Establezca esto en un valor bajo (10) para forzar la reproducción aleatoria en el disco en caso de que golpee un OutOfMemoryError en MapOutputCopier.shuffleInMemory .
mapreduce.map.memory.mb es el límite de memoria superior que Hadoop permite asignar a un asignador, en megabytes. El valor predeterminado es 512. Si se excede este límite, Hadoop matará al asignador con un error como este:
El contenedor [pid = container_1406552545451_0009_01_000002, containerID = container_234132_0001_01_000001] se ejecuta más allá de los límites de la memoria física. Uso actual: se usaron 569.1 MB de memoria física de 512 MB; 970.1 MB de memoria virtual de 1.0 GB utilizada. Contenedor de matar
Hadoop mapper es un proceso de Java y cada proceso de Java tiene su propia configuración de asignación máxima de memoria de montón configurada mediante mapred.map.child.java.opts (o mapreduce.map.java.opts en Hadoop 2+). Si el proceso de mapeo se queda sin memoria, el mapeador arroja una java de las excepciones de memoria:
Error: java.lang.RuntimeException: java.lang.OutOfMemoryError
Por lo tanto, las configuraciones de Hadoop y Java están relacionadas. La configuración de Hadoop es más una de aplicación / control de recursos y Java es más una configuración de recursos.
La configuración del montón de Java debe ser más pequeña que el límite de memoria del contenedor de Hadoop porque necesitamos memoria de reserva para el código de Java. Por lo general, se recomienda reservar un 20% de memoria para el código. Por lo tanto, si la configuración es correcta, las tareas de Hadoop basadas en Java nunca deberían ser eliminadas por Hadoop, por lo que nunca debería ver el error "Killing container" como se indicó anteriormente.
Si tiene errores de falta de memoria en Java, debe aumentar ambas configuraciones de memoria.