Kontener działa poza limitami pamięci

Na poziomie przędzy znajduje się sprawdzanie współczynnika wykorzystania pamięci Vertualnej i fizycznej. Problem polega nie tylko na tym, że maszyna wirtualna nie ma wystarczającej pamięci pysical. Ale to dlatego, że wykorzystanie pamięci wirtualnej jest więcej niż oczekiwano dla danej pamięci fizycznej.

Uwaga: dzieje się tak w Centos/RHEL 6 ze względu na agresywną alokację pamięci wirtualnej.

Można go rozwiązać poprzez:

1. Wyłącz sprawdzanie użycia pamięci wirtualnej przez ustawienie przędza.nodemanager.vmem-check-enabled to false;

2. Zwiększ stosunek VM: PM przez ustawienie przędzy .nodemanager.vmem-pmem-ratio do jakiejś wyższej wartości.

Bibliografia :

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

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

Dodaj następującą właściwość w / align = "left" / 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>

Miałem bardzo podobny problem używając HIVE w EMR. Żadne z istniejących rozwiązań nie działało dla mnie-tj. żadna z konfiguracji mapreduce nie działała dla mnie; ani ustawienie yarn.nodemanager.vmem-check-enabled Na false.

Jednak to, co skończyło się pracą, to ustawienie tez.am.resource.memory.mb, na przykład:

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

Kolejnym ustawieniem do rozważenia jest yarn.app.mapreduce.am.resource.mb

Nie mogę skomentować zaakceptowanej odpowiedzi, ze względu na niską reputację. Chciałbym jednak dodać, że takie zachowanie jest z założenia. NodeManager zabija Twój kontener. Wygląda na to, że próbujesz użyć strumieniowania hadoop, który działa jako proces potomny zadania Map-reduce. NodeManager monitoruje całe drzewo procesów zadania i jeśli zżera więcej pamięci niż maksimum ustawione w mapreduce.Mapa.pamięć.mb lub mapreduce.zmniejsz.pamięć.mb, spodziewalibyśmy się Nodemanager, aby zabić zadanie, w przeciwnym razie Twoim zadaniem jest kradzież pamięci należącej do innych kontenerów, których nie chcesz.

Podczas pracy z spark w EMR miałem ten sam problem i ustawienie maximizeResourceAllocation=true zadziałało; mam nadzieję, że komuś pomoże. Musisz go ustawić podczas tworzenia klastra. Z EMR docs:

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

Gdzie myConfig.json powinien powiedzieć:

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

Ostatnio również mieliśmy do czynienia z tym problemem. Jeśli problem jest związany z pamięcią mapera, kilka rzeczy, które chciałbym zasugerować, które należy sprawdzić, to.

• Sprawdź czycombiner jest włączony czy nie ? Jeżeli tak, to oznacza, że logika reduce musi być uruchomiona na wszystkich rekordach (wyjście mappera). To dzieje się w pamięci. na podstawie Twojej aplikacji musisz sprawdzić, czy włączenie combinera pomaga, czy nie. Kompromis jest między bajtów transferu sieciowego i czasu / pamięci / procesora dla zmniejszenia logiki na 'X' liczba rekordów.
  • Jeśli uważasz, że combiner nie ma dużej wartości, po prostu go wyłącz.
  • Jeśli potrzebujesz combinera i 'X' jest ogromną liczbą (powiedzmy milionami rekordów), rozważając zmianę logiki podziału (dla domyślnych formatów wejściowych używaj mniej rozmiaru bloku, zwykle 1 rozmiar bloku = 1 split), aby mapować mniejszą liczbę rekordów do jednego mapera.
• Liczba rekordów przetwarzanych w jednym maperze. Pamiętaj, że wszystkie te zapisy potrzebują to be posorted in memory (Wyjście mappera jest posortowane). Rozważ ustawienie mapreduce.task.io.sort.mb (domyślnie 200MB) na wyższą wartość w razie potrzeby. mapred-configs.xml
• jeśli któreś z powyższych nie pomogło, spróbuj uruchomić logikę mappera jako samodzielną aplikację i profilować aplikację za pomocą profilera (takiego jak JProfiler) i sprawdź, gdzie pamięć zostanie wykorzystana. To może dać bardzo dobry wgląd.