registros actuales sobre el uso de un problema HQL encontraron mapa = 100% y reducen = 100% con respecto a la idea de que puede realizar consecuencia, el último informa sobre un fallo repentino, la vida realmente está lleno de sorpresas e inesperada, sólo puedo decir esto ... no hay ninguna sorpresa feliz
Después de ver este error, ver el registro encontró la colmena, la colmena con la implementación de la interfaz es el mismo periódico, ver qué cosas a cabo, a continuación, utilizar de hadoop historia: 8088 vista agregada de registro y encontró la interfaz de usuario aquí es el comienzo de la 4 un mapa de una reducir, reducir registros no aparece que no hay mapa no es completa, lo que lleva a reducir no trabajo, punto de ellos en un registro Ver mapa descubrir el origen del mal periódico, el problema es, desbordamiento de pila, y la memoria virtual la causa de mapa fue impresionado
Varios digital enfocado a hacer algo simples Comentarios
110.2 MB de 1 GB
3,7 GB de 2,1 GB de memoria virtual utilizado. contenedor de matar
1,110.2MB es la memoria física real para esta tarea
2,1GB es conjunto mapreduce.map.memory.mb (predeterminado)
3,3.7GB tarea es tomar la memoria virtual
4,2.1GB es mapreduce.map.memory.db-pmem-relación yarn.nodemanager.vmem multiplicada obtenida
5, en el que yarn.nodemanager.vmem-pmem-relación es la relación de la memoria virtual y memoria física, el hilo-site.xml proporcionado, el valor predeterminado es 2,1
si I está situado localmente 3, que es el valor calculado 1 * 3 = 3 GB
En resumen registros nos dicen es la tarea a ser virtual de memoria sólo es 3.7G y 2,1 g de sistema de memoria virtual más allá del límite de no trabajo, aquí está un poco más allámemoria virtualHay diferencias con la memoria real de sus propios Baidu no entienden este conocimiento
Así que la solución en las siguientes áreas
En el conjunto de hilo site.xml de la comprobación de la memoria virtual (el valor predeterminado es Verdadero estado abierto)
<property>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
<description>Whether virtual memory limits will be enforced for containers.</description>
</property>
De acuerdo con mi propia configuración, y la cantidad de datos de memoria de descubrimiento de procesado es suficiente, ya que este se encuentra en mecanismo de comprobación de la memoria virtual en general encerrados fuera así que configure sólo esto, se puede continuar con la ejecución de la tarea
En el hilo-site.xml memoria física está marcada puede ser cerrada
<property>
<name>yarn.nodemanager.pmem-check-enabled </name>
<value>false</value>
<description>Whether virtual memory limits will be enforced for containers.</description>
</property>
Sin embargo, generalmente no se recomienda ajuste de tal porque si un programa tiene una pérdida de memoria y otros problemas, cancelar el registro de entrada, podría conducir al colapso de la agrupación.
Hay una escasez de memoria física puede hacer que el programa no se inicie, la memoria física aumento
En-site.xml mapred valor de los siguientes parámetros de acuerdo con la cantidad de procesamiento de datos ajustada adecuadamente:2048, -Xmx1024Mvalor auto-conjunto adecuado
<property>
<name>mapreduce.map.memory.mb</name>
<value>2048</value>
</property>
<property>
<name>mapreduce.map.java.opts</name>
<value>-Xmx1024M</value>
</property>
<property>
<name>mapreduce.reduce.memory.mb</name>
<value>2048</value>
</property>
<property>
<name>mapreduce.reduce.java.opts</name>
<value>-Xmx2560M</value>
</property>
Se puede ajustar yarn.nodemanager.vmem pmem - tamaño ratio, porque la memoria virtual se ve afectada por el porcentaje de memoria física
Puede haber un proceso que se ejecuta en los datos de RM en la inclinación, pérdidas de memoria y otras razones que sólo un análisis detallado de las razones específicas
Después de cambiar el archivo de configuración de hilo site.xml Recuerde reiniciar el hilo de clúster
