O contêiner está funcionando além dos limites de memória

No Hadoop v1, atribuí cada slot de 7 mapeadores e redutores com tamanho de 1 GB, meus mapeadores e redutores funcionam bem. Minha máquina tem 8G de memória e 8 processadores. Agora com o YARN, ao executar o mesmo aplicativo na mesma máquina, recebo um erro de contêiner. Por padrão, tenho estas configurações:

  <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>

Deu-me um erro:

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.

Em seguida, tentei definir o limite de memória em 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>

Mas ainda obtendo erro:

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.

Estou confuso por que a tarefa do mapa precisa de tanta memória. No meu entendimento, 1 GB de memória é suficiente para minha tarefa de mapear / reduzir. Por que, conforme atribuo mais memória ao contêiner, a tarefa usa mais? É porque cada tarefa recebe mais divisões? Acho que é mais eficiente diminuir um pouco o tamanho do container e criar mais containers, para que mais tarefas sejam executadas em paralelo. O problema é como posso ter certeza de que cada contêiner não receberá mais divisões do que pode suportar?

Você também deve configurar corretamente as alocações máximas de memória para MapReduce. Deste tutorial do HortonWorks :

[...]

Cada máquina em nosso cluster tem 48 GB de RAM. Parte dessa RAM deve ser reservada para uso do sistema operacional. Em cada nó, atribuiremos 40 GB de RAM para> YARN para usar e manter 8 GB para o sistema operacional

Para nosso cluster de exemplo, temos o mínimo de RAM para um contêiner (yarn.scheduler.minimum-alocação-mb) = 2 GB. Assim, atribuiremos 4 GB para contêineres de tarefas de mapa e 8 GB para contêineres de tarefas de redução.

Em mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

Cada contêiner executará JVMs para as tarefas Map e Reduce. O tamanho de heap da JVM deve ser definido como menor do que a memória Map and Reduce definida acima, para que fiquem dentro dos limites da memória do Container alocada pelo YARN.

Em mapred-site.xml:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

As configurações acima configuram o limite superior da RAM física que as tarefas de Mapeamento e Redução usarão .

Resumindo:

1. No YARN, você deve usar as mapreduceconfigurações, não mapredaquelas. EDITAR: Este comentário não é mais aplicável agora que você editou sua pergunta.
2. O que você está configurando é, na verdade, quanto deseja solicitar, não o máximo a ser alocado.
3. Os limites máximos são definidos com as java.optsconfigurações listadas acima.

Finalmente, você pode querer verificar esta outra questão do SO que descreve um problema semelhante (e solução).

Há uma verificação colocada no nível do Yarn para a proporção de uso de memória virtual e física. O problema não é apenas que a VM não tem memória física suficiente. Mas é porque o uso da memória virtual é mais do que o esperado para determinada memória física.

Nota : Isso está acontecendo no Centos / RHEL 6 devido à sua alocação agressiva de memória virtual.

Isso pode ser resolvido por:

1. Desative a verificação de uso de memória virtual definindo yarn.nodemanager.vmem-check-enabled para false ;

2. Aumente a proporção VM: PM definindo yarn.nodemanager.vmem-pmem-ratio para um valor mais alto.

Referências :

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

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

Adicione a seguinte propriedade em 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>

Tive um problema muito semelhante ao usar o HIVE no EMR. Nenhuma das soluções existentes funcionou para mim - ou seja, nenhuma das configurações do mapreduce funcionou para mim; e nem a configuração yarn.nodemanager.vmem-check-enabledcomo falsa.

Porém, o que acabou dando certo foi a configuração tez.am.resource.memory.mb, por exemplo:

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

Outra configuração a considerar é o ajuste yarn.app.mapreduce.am.resource.mb

Não posso comentar a resposta aceita, devido à baixa reputação. No entanto, gostaria de acrescentar que esse comportamento é intencional. O NodeManager está matando seu contêiner. Parece que você está tentando usar o streaming hadoop, que está sendo executado como um processo filho da tarefa de redução de mapa. O NodeManager monitora toda a árvore de processo da tarefa e se consumir mais memória do que o máximo definido em mapreduce.map.memory.mb ou mapreduce.reduce.memory.mb respectivamente, esperaríamos que o Nodemanager encerrasse a tarefa, caso contrário sua tarefa é roubar memória pertencente a outros contêineres, que você não quer.

Enquanto trabalhava com o Spark no EMR, estava tendo o mesmo problema e a configuração maximizeResourceAllocation=truefuncionou; espero que ajude alguém. Você deve configurá-lo ao criar o cluster. De 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

Onde myConfig.json deve dizer:

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

Também enfrentamos esse problema recentemente. Se o problema estiver relacionado à memória do mapeador, algumas coisas que eu gostaria de sugerir que precisam ser verificadas são.

• Verifique se o combinador está habilitado ou não ? Se sim, isso significa que a lógica de redução deve ser executada em todos os registros (saída do mapeador). Isso acontece na memória.Com base em seu aplicativo, você precisa verificar se habilitar o combinador ajuda ou não. A compensação é entre os bytes de transferência da rede e o tempo / memória / CPU necessários para a lógica de redução no número 'X' de registros.
  • Se você acha que o combinador não tem muito valor, apenas desative-o.
  • Se você precisa do combinador e 'X' é um grande número (digamos milhões de registros), então considere alterar sua lógica de divisão (para formatos de entrada padrão, use menos tamanho de bloco, normalmente 1 tamanho de bloco = 1 divisão) para mapear menos número de registros para um mapeador único.
• Número de registros sendo processados ​​em um único mapeador. Lembre-se de que todos esses registros precisam ser classificados na memória (a saída do mapeador é classificada). Considere definir mapreduce.task.io.sort.mb (o padrão é 200 MB) para um valor mais alto, se necessário. mapred-configs.xml
• Se alguma das opções acima não ajudar, tente executar a lógica do mapeador como um aplicativo independente e crie o perfil do aplicativo usando um Profiler (como JProfiler) e veja onde a memória está sendo usada. Isso pode lhe dar uma visão muito boa.

Executando yarn no subsistema Windows Linux com Ubunto OS, erro "executando além dos limites de memória virtual, Killing container" Eu resolvi desabilitando a verificação de memória virtual no arquivo yarn-site.xml

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

Eu não verifiquei pessoalmente, mas hadoop-yarn-container-virtual-memory -standing-and-solving-container-is-running-beyond-virtual-memory-limits-errors parece muito razoável

Resolvi o problema mudando yarn.nodemanager.vmem-pmem-ratiopara um valor mais alto e concordo que:

Outra solução menos recomendada é desabilitar a verificação de memória virtual definindo yarn.nodemanager.vmem-check-enabled como false.