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

Hay una comprobación a nivel de hilo para la relación de uso de memoria Vertual y Física. El problema no es solo que la VM no tiene suficiente memoria física. Pero es porque el uso de memoria virtual es más de lo esperado para la memoria física dada.

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

Puede resolverse mediante:

1. Desactivar la comprobación del uso de la memoria virtual configuración hilado.nodemanager.vmem-check-enabled to false;

2. Aumente la relación VM: PM configurando hilo.nodemanager.vmem-pmem-ratio a algún 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/

Agregar la siguiente propiedad en hilado-sitio.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í ie es decir, ninguna de las configuraciones de mapreduce funcionó para mí; y tampoco lo hizo establecer yarn.nodemanager.vmem-check-enabled a false.

Sin embargo, lo que terminó funcionando fue configurar 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 la respuesta aceptada, debido a la baja reputación. Sin embargo, me gustaría añadir, este comportamiento es por diseño. El NodeManager está matando tu contenedor. Parece que está tratando de usar la transmisión de hadoop que se ejecuta como un proceso hijo de la tarea map-reduce. El NodeManager supervisa todo el árbol de procesos de la tarea y si consume más memoria que el máximo establecido en mapreduce.asignar.memoria.mb o mapreduce.reducir.memoria.mb respectivamente, esperaríamos la Nodemanager para matar a la tarea, de lo contrario su tarea está robando la memoria que pertenece a otros contenedores, que no desea.

Mientras trabajaba con spark en EMR estaba teniendo el mismo problema y configurar maximizeResourceAllocation=true hizo el truco; espero que ayude a alguien. Debe configurarlo cuando cree el clúster. De los documentos del 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 nos enfrentamos a este problema recientemente. Si el problema está relacionado con la memoria del mapeador, un par de cosas que me gustaría sugerir que deben verificarse son.

• Compruebe si combinador está habilitado o no? Si es así, entonces significa que la lógica de reducción tiene que ejecutarse en todos los registros (salida de mapper). Esto sucede en la memoria. En función de su aplicación, debe verificar si habilitar combinador ayuda o no. El intercambio es entre los bytes de transferencia de red y el tiempo / memoria / CPU para la lógica de reducción en' X ' número de registros.
  • Si siente que el combinador no es mucho de valor, simplemente deshabilítelo.
  • Si necesita 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 número de registros a un solo mapeador.
• Número de registros que se procesan en un solo mapeador. Recuerde que todos estos registros necesitan para ser ordenado en memoria (la salida del mapeador está ordenada). Considere establecer mapreduce.task.io.sort.mb (el valor predeterminado es 200MB) a un valor más alto si es necesario. mapred-configs.xml
• Si cualquiera de los anteriores no ayudó, intente ejecutar la lógica del mapeador como una aplicación independiente y perfile la aplicación usando un generador de perfiles (como JProfiler) y vea dónde se usa la memoria. Esto puede darte muy buenas ideas.