Kontener działa poza limitami pamięci

W Hadoop v1 przypisałem każde 7 gniazd mapowania i reduktora o rozmiarze 1 GB, moje mapery i reduktory działają dobrze. Moja maszyna ma pamięć 8G, procesor 8. Teraz z YARN, po uruchomieniu tej samej aplikacji na tym samym komputerze, otrzymałem błąd kontenera. Domyślnie mam takie ustawienia:

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

Dało mi to błąd:

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.

Następnie próbowałem ustawić limit pamięci w 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>

Ale nadal pojawia się błąd:

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.

Nie wiem, dlaczego zadanie mapy wymaga tak dużej ilości pamięci. W moim rozumieniu 1 GB pamięci wystarczy na moje zadanie mapowania / redukcji. Dlaczego przypisując więcej pamięci do kontenera, zadanie zużywa więcej? Czy to dlatego, że każde zadanie ma więcej podziałów? Wydaje mi się, że bardziej wydajne jest niewielkie zmniejszenie rozmiaru kontenera i utworzenie większej liczby kontenerów, aby więcej zadań było wykonywanych równolegle. Problem polega na tym, jak mogę się upewnić, że do każdego kontenera nie zostanie przypisanych więcej podziałów, niż może obsłużyć?

Należy również poprawnie skonfigurować maksymalne alokacje pamięci dla MapReduce. Z tego samouczka HortonWorks :

[…]

Każda maszyna w naszym klastrze ma 48 GB pamięci RAM. Część tej pamięci RAM powinna być> zarezerwowana do użytku w systemie operacyjnym. W każdym węźle przydzielimy 40 GB pamięci RAM dla> YARN do wykorzystania i zachowamy 8 GB dla systemu operacyjnego

W naszym przykładowym klastrze mamy minimalną pamięć RAM dla kontenera (yarn.scheduler.minimum -ocation-mb) = 2 GB. W ten sposób przydzielimy 4 GB na kontenery zadań mapowania i 8 GB na kontenery zadań Reduce.

W mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

Każdy kontener będzie uruchamiał maszyny JVM dla zadań mapowania i redukcji. Rozmiar sterty maszyny JVM powinien być mniejszy niż rozmiar pamięci Map i Reduce zdefiniowany powyżej, tak aby mieścił się w granicach pamięci kontenera przydzielonej przez YARN.

W mapred-site.xml:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

Powyższe ustawienia konfigurują górny limit fizycznej pamięci RAM, której będą używać zadania mapowania i zmniejszania .

Podsumowując:

1. W YARN powinieneś używać mapreducekonfiguracji, a nie mapredtych. EDYTUJ: ten komentarz nie ma już zastosowania po edycji pytania.
2. To, co konfigurujesz, to w rzeczywistości, ile chcesz zażądać, a nie jaka jest maksymalna kwota do przydzielenia.
3. Maksymalne limity są skonfigurowane przy użyciu java.optsustawień wymienionych powyżej.

Na koniec możesz sprawdzić to inne pytanie SO, które opisuje podobny problem (i rozwiązanie).

Na poziomie Yarn znajduje się sprawdzenie współczynnika wykorzystania pamięci wirtualnej i fizycznej. Problem polega nie tylko na tym, że maszyna wirtualna nie ma wystarczającej pamięci fizycznej. Ale dzieje się tak, ponieważ użycie pamięci wirtualnej jest większe niż oczekiwano dla danej pamięci fizycznej.

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

Można to rozwiązać:

1. Wyłącz sprawdzanie użycia pamięci wirtualnej, ustawiając yarn.nodemanager.vmem-check-enabled na false ;

2. Zwiększ współczynnik VM: PM, ustawiając współczynnik yarn.nodemanager.vmem-pmem- na wyższą wartość.

Piśmiennictwo :

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

Miałem bardzo podobny problem podczas używania 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; i też nie ustawiono yarn.nodemanager.vmem-check-enabledna fałsz.

Jednak to, co ostatecznie działało, to ustawienie tez.am.resource.memory.mb, na przykład:

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

Innym ustawieniem, które należy rozważyć, jest yarn.app.mapreduce.am.resource.mb

Nie mogę wypowiedzieć się na temat zaakceptowanej odpowiedzi z powodu złej reputacji. Chciałbym jednak dodać, że takie zachowanie jest zgodne z projektem. NodeManager zabija twój kontener. Wygląda na to, że próbujesz użyć przesyłania strumieniowego hadoop, które działa jako proces potomny zadania zmniejszania mapy. NodeManager monitoruje całe drzewo procesów zadania i jeśli zużywa więcej pamięci niż maksimum ustawione odpowiednio w mapreduce.map.memory.mb lub mapreduce.reduce.memory.mb, spodziewalibyśmy się, że Nodemanager zabije zadanie, w przeciwnym razie Twoim zadaniem jest kradzież pamięci należących do innych pojemników, których nie chcesz.

Podczas pracy z iskrą w EMR miałem ten sam problem i ustawienie maximizeResourceAllocation=truezałatwiło sprawę; mam nadzieję, że to komuś pomoże. Musisz to ustawić podczas tworzenia klastra. Z dokumentów 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

Gdzie myConfig.json powinien powiedzieć:

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

Niedawno też mieliśmy do czynienia z tym problemem. Jeśli problem dotyczy pamięci mappera, chciałbym zasugerować kilka rzeczy, które należy sprawdzić.

• Sprawdź, czy łącznik jest włączony, czy nie ? Jeśli tak, oznacza to, że logika redukcji musi być uruchomiona na wszystkich rekordach (dane wyjściowe programu mapującego). Dzieje się to w pamięci. W oparciu o swoją aplikację musisz sprawdzić, czy włączenie łącznika pomaga, czy nie. Kompromisem jest między bajtami transferu sieciowego a zajętym czasem / pamięcią / procesorem w celu zmniejszenia logiki liczby rekordów „X”.
  • Jeśli uważasz, że ten łącznik nie ma dużej wartości, po prostu go wyłącz.
  • Jeśli potrzebujesz sumatora, a `` X '' to ogromna liczba (powiedzmy miliony rekordów), rozważ zmianę logiki podziału (dla domyślnych formatów wejściowych użyj mniejszego rozmiaru bloku, zwykle rozmiar 1 bloku = 1 podział), aby zamapować mniejszą liczbę rekordów na pojedynczy mapownik.
• Liczba rekordów przetwarzanych w jednym mapowaniu. Pamiętaj, że wszystkie te rekordy muszą być posortowane w pamięci (dane wyjściowe programu mapującego są sortowane). W razie potrzeby rozważ ustawienie mapreduce.task.io.sort.mb (domyślnie 200 MB) na wyższą wartość. mapred-configs.xml
• Jeśli którekolwiek z powyższych nie pomogło, spróbuj uruchomić logikę mapowania jako samodzielną aplikację i sprofiluj aplikację za pomocą Profilera (takiego jak JProfiler) i zobacz, gdzie wykorzystywana jest pamięć. To może dać ci bardzo dobry wgląd.

Uruchomienie przędzy w podsystemie Windows Linux z systemem Ubunto OS, błąd „działanie poza limitami pamięci wirtualnej, zabijanie kontenera” Rozwiązałem ten problem, wyłączając sprawdzanie pamięci wirtualnej w pliku yarn-site.xml

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

Osobiście nie sprawdziłem, ale błędy hadoop-yarn-container-virtual-memory-zrozumienia-and-solving-container-is-running-outside-virtual-memory-limits-limits brzmi bardzo rozsądnie

Rozwiązałem problem, zmieniając yarn.nodemanager.vmem-pmem-rationa wyższą wartość i zgadzam się, że:

Innym mniej zalecanym rozwiązaniem jest wyłączenie sprawdzania pamięci wirtualnej przez ustawienie yarn.nodemanager.vmem-check-enabled na false.