El contenedor se ejecuta más allá de los límites de memoria

En Hadoop v1, he asignado cada 7 ranuras de mapeador y reductor con un tamaño de 1GB, mis mapeadores y reductores funcionan bien. Mi máquina tiene memoria 8G, procesador 8. Ahora con YARN, cuando ejecuto la misma aplicación en la misma máquina, obtengo un error de contenedor. Por defecto, tengo esta configuración:

  <property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>1024</value>
  </property>
  <property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>8192</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>8192</value>
  </property>

Me dio error:

Container [pid=28920,containerID=container_1389136889967_0001_01_000121] is running beyond virtual memory limits. Current usage: 1.2 GB of 1 GB physical memory used; 2.2 GB of 2.1 GB virtual memory used. Killing container.

Luego intenté establecer el límite de memoria en mapred-site.xml:

  <property>
    <name>mapreduce.map.memory.mb</name>
    <value>4096</value>
  </property>
  <property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>4096</value>
  </property>

Pero todavía aparece el error:

Container [pid=26783,containerID=container_1389136889967_0009_01_000002] is running beyond physical memory limits. Current usage: 4.2 GB of 4 GB physical memory used; 5.2 GB of 8.4 GB virtual memory used. Killing container.

Estoy confundido por qué la tarea del mapa necesita tanta memoria. Según tengo entendido, 1 GB de memoria es suficiente para mi tarea de mapa / reducción. ¿Por qué a medida que asigno más memoria al contenedor, la tarea consume más? ¿Es porque cada tarea tiene más divisiones? Siento que es más eficiente disminuir un poco el tamaño del contenedor y crear más contenedores, de modo que se ejecuten más tareas en paralelo. El problema es ¿cómo puedo asegurarme de que a cada contenedor no se le asignen más divisiones de las que puede manejar?

También debe configurar correctamente las asignaciones máximas de memoria para MapReduce. De este tutorial de HortonWorks :

[...]

Cada máquina de nuestro clúster tiene 48 GB de RAM. Parte de esta RAM debe> reservarse para el uso del sistema operativo. En cada nodo, asignaremos 40 GB de RAM para> YARN para usar y mantendremos 8 GB para el sistema operativo

Para nuestro clúster de ejemplo, tenemos la RAM mínima para un contenedor (yarn.scheduler.minimum-deployment-mb) = 2 GB. Por lo tanto, asignaremos 4 GB para contenedores de tareas de mapas y 8 GB para contenedores de tareas reducidas.

En mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

Cada contenedor ejecutará JVM para las tareas Map y Reduce. El tamaño de almacenamiento dinámico de JVM debe establecerse en un valor inferior al de la memoria de mapa y reducción definida anteriormente, para que estén dentro de los límites de la memoria del contenedor asignada por YARN.

En mapred-site.xml:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

La configuración anterior configura el límite superior de la RAM física que utilizarán las tareas de Mapa y Reducción .

Para resumirlo:

1. En YARN, debes usar las mapreduceconfiguraciones, no mapredlas. EDITAR: Este comentario ya no es aplicable ahora que ha editado su pregunta.
2. Lo que está configurando es en realidad cuánto desea solicitar, no cuál es el máximo para asignar.
3. Los límites máximos se configuran con los java.optsajustes enumerados anteriormente.

Finalmente, es posible que desee verificar esta otra pregunta SO que describe un problema similar (y una solución).

Hay una marca de verificación en el nivel de hilo para la tasa de uso de memoria física y virtual. El problema no es solo que la máquina virtual no tiene suficiente memoria física. Pero es porque el uso de la memoria virtual es más de lo esperado para una memoria física determinada.

Nota : Esto está sucediendo en Centos / RHEL 6 debido a su asignación agresiva de memoria virtual.

Puede resolverse mediante:

1. Deshabilite la verificación de uso de memoria virtual estableciendo yarn.nodemanager.vmem-check-enabled en false ;

2. Aumente la relación VM: PM estableciendo yarn.nodemanager.vmem-pmem-ratio en un valor más alto.

Referencias :

https://issues.apache.org/jira/browse/HADOOP-11364

http://blog.cloudera.com/blog/2014/04/apache-hadoop-yarn-avoiding-6-time-consuming-gotchas/

Agregue la siguiente propiedad en yarn-site.xml

 <property>
   <name>yarn.nodemanager.vmem-check-enabled</name>
    <value>false</value>
    <description>Whether virtual memory limits will be enforced for containers</description>
  </property>
 <property>
   <name>yarn.nodemanager.vmem-pmem-ratio</name>
    <value>4</value>
    <description>Ratio between virtual memory to physical memory when setting memory limits for containers</description>
  </property>

Tuve un problema muy similar al usar HIVE en EMR. Ninguna de las soluciones existentes funcionó para mí, es decir, ninguna de las configuraciones de mapreduce funcionó para mí; y tampoco lo hizo el poner yarn.nodemanager.vmem-check-enableden falso.

Sin embargo, lo que terminó funcionando fue la configuración tez.am.resource.memory.mb, por ejemplo:

hive -hiveconf tez.am.resource.memory.mb=4096

Otro ajuste a considerar es yarn.app.mapreduce.am.resource.mb

No puedo comentar sobre la respuesta aceptada, debido a la baja reputación. Sin embargo, me gustaría agregar, este comportamiento es por diseño. NodeManager está matando su contenedor. Parece que está intentando utilizar la transmisión de hadoop, que se ejecuta como un proceso secundario de la tarea de reducción de mapas. El NodeManager monitorea todo el árbol de procesos de la tarea y si consume más memoria que el máximo establecido en mapreduce.map.memory.mb o mapreduce.reduce.memory.mb respectivamente, esperaríamos que Nodemanager elimine la tarea, de lo contrario su tarea es robar la memoria que pertenece a otros contenedores, que no desea.

Mientras trabajaba con Spark en EMR estaba teniendo el mismo problema y la configuración maximizeResourceAllocation=truefuncionó; Espero que ayude a alguien. Tienes que configurarlo cuando creas el clúster. De los documentos EMR:

aws emr create-cluster --release-label emr-5.4.0 --applications Name=Spark \
--instance-type m3.xlarge --instance-count 2 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/mybucket/myfolder/myConfig.json

Donde myConfig.json debería decir:

[
  {
    "Classification": "spark",
    "Properties": {
      "maximizeResourceAllocation": "true"
    }
  }
]

También enfrentamos este problema recientemente. Si el problema está relacionado con la memoria del mapeador, me gustaría sugerir un par de cosas que se deben verificar.

• ¿Compruebe si el combinador está habilitado o no ? En caso afirmativo, significa que la lógica de reducción debe ejecutarse en todos los registros (salida del asignador). Esto sucede en la memoria. Según su aplicación, debe verificar si habilitar el combinador ayuda o no. La compensación es entre los bytes de transferencia de la red y el tiempo / memoria / CPU necesarios para reducir la lógica en el número 'X' de registros.
  • Si cree que el combinador no tiene mucho valor, simplemente desactívelo.
  • Si necesita un combinador y 'X' es un número enorme (digamos millones de registros), entonces considere cambiar su lógica de división (para los formatos de entrada predeterminados, use menos tamaño de bloque, normalmente 1 tamaño de bloque = 1 división) para asignar menos cantidad de registros a un mapeador único.
• Número de registros que se procesan en un único asignador. Recuerde que todos estos registros deben ordenarse en la memoria (la salida del asignador está ordenada). Considere configurar mapreduce.task.io.sort.mb (el valor predeterminado es 200 MB) en un valor más alto si es necesario. mapred-configs.xml
• Si algo de lo anterior no ayudó, intente ejecutar la lógica del asignador como una aplicación independiente y perfile la aplicación usando un Profiler (como JProfiler) y vea dónde se usa la memoria. Esto puede brindarle muy buenas perspectivas.

Ejecutando yarn en el subsistema de Windows Linux con Ubunto OS, error "corriendo más allá de los límites de memoria virtual, contenedor de destrucción" Lo resolví desactivando la verificación de memoria virtual en el archivo yarn-site.xml

<property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property> 

No lo he comprobado personalmente, pero los errores de hadoop-yarn-container-virtual-memory-comprensión-y-solución-contenedor-se está ejecutando-más allá de los límites de la memoria virtual suena muy razonable

Resolví el problema cambiando yarn.nodemanager.vmem-pmem-ratioa un valor más alto y estaría de acuerdo en que:

Otra solución menos recomendada es deshabilitar la verificación de memoria virtual configurando yarn.nodemanager.vmem-check-enabled en false.