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


85

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?


possível duplicata do contêiner de fios
Sheena

Oi ! sua configuração 'yarn.nodemanager.vmem-pmem-ratio = 2'?
sprite de

Respostas:


102

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


Sim. Definindo mapreduce.map.java.optse mapreduce.reduce.java.optsresolvendo meu problema. Você sabe se a memória real atribuída à tarefa é definida apenas por mapreduce.map/reduce.memory.mb? Como isso yarn.scheduler.minimum-allocation-mbafeta a atribuição de memória real?
Lishu

@lishu, se isso ajudou, aceite a resposta. Sobre sua última pergunta, a configuração de yarn se aplica a qualquer alocação de contêiner no cluster; isso inclui mapear e reduzir tarefas, mas também outras tarefas de outros tipos de aplicativos. As configurações de mapreduce se aplicam apenas a trabalhos de mapreduce.
cabad

@cabad, desenvolvo uma biblioteca que Lishu está usando. Eu gostaria de saber se você mudaria algo em sua resposta sabendo que a tarefa de MR está gerando um processo que, na verdade, está alocando a maior parte da memória (streaming hadoop). Certamente a configuração do Xmx não afeta o processo externo, pois não é um programa java. Obrigado pela ajuda.
piccolbo

2
Agora existe uma ferramenta útil da Hortonworks chamada hdp-configuration-utils para obter os valores recomendados. Obtenha-o em github.com/hortonworks/hdp-configuration-utils
selle

1
Se aplicar a configuração de memória adequada não corrigiu o problema (como no meu caso, na verdade funcionou em um hadoop rodando no ubuntu, mas não no CentOS) tente desabilitar o vmem check: blog.cloudera.com/blog/2014/04/…
Bakhshi,

47

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>

15

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


Um @hiroprotagonist, você sabe se o "ajuste" do parâmetro yarn tem que acontecer antes de o YARN iniciar ou se ele só é usado no momento da aplicação (e pode ser alterado de um trabalho para o próximo)?
Juiz Mental

1
Consegui definir na hora da aplicação. especificamente, no console interativo da colmeia.
Hiroprotagonista

8

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.


1

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"
    }
  }
]

1

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.

1

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> 

No WSL, a mensagem de erro tem números absurdos (pelo menos para mim): "... está sendo executado além dos limites de memória virtual. Uso atual: 338,8 MB de 2 GB de memória física usados; 481,1 GB de 4,2 GB de memória virtual usados. Killing container . "
Samik R

@SamikR Sim, eu tenho uma situação semelhante, acho que não são os problemas do hadoop, são os problemas do WSL. Talvez eu precise transferir a demonstração para um computador Linux OS real
Bingoabs

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.