Kontener działa poza limitami pamięci

85

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

Lishu
źródło
możliwy duplikat pojemnika
Sheena
Cześć ! twoja konfiguracja „yarn.nodemanager.vmem-pmem-ratio = 2”?
sprite

Odpowiedzi:

102

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

Cabad
źródło
Tak. Ustawiając mapreduce.map.java.optsi mapreduce.reduce.java.optsrozwiązując mój problem. CZY wiesz, czy rzeczywista pamięć przypisana do zadania jest definiowana tylko przez mapreduce.map/reduce.memory.mb? Jak yarn.scheduler.minimum-allocation-mbwpływa na faktyczne przypisanie pamięci?
Lishu,
@lishu, jeśli to pomogło, zaakceptuj odpowiedź. Jeśli chodzi o twoje ostatnie pytanie, ustawienie przędzy dotyczy dowolnego przydziału kontenerów w klastrze; obejmuje to mapowanie i redukcję zadań, ale także inne zadania z innych typów aplikacji. Ustawienia mapreduce dotyczą tylko zadań mapreduce.
cabad,
@cabad, tworzę bibliotekę, której używa Lishu. Zastanawiałem się, czy zmieniłbyś cokolwiek w swojej odpowiedzi, wiedząc, że zadanie MR tworzy proces, który w rzeczywistości alokuje większość pamięci (strumieniowanie hadoopów). Z pewnością ustawienie Xmx nie wpływa na proces zewnętrzny, ponieważ nie jest to program Java. Dzięki za pomoc.
piccolbo,
2
Jest teraz przydatne narzędzie firmy Hortonworks o nazwie hdp-configuration-utils do pobierania zalecanych wartości. Zdobądź to na github.com/hortonworks/hdp-configuration-utils
selle
1
Jeżeli stosując właściwą konfigurację pamięci nie rozwiąże problemu (jak w moim przypadku, faktycznie pracował na Hadoop działa na ubuntu ale nie na CentOS) spróbuj wyłączyć sprawdzanie vMem: blog.cloudera.com/blog/2014/04/...
Bakhshi
47

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>
Sanjiv
źródło
15

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

hiroprotagonist
źródło
Hm @hiroprotagonist, czy wiesz, czy „podkręcanie” parametru przędzy musi nastąpić przed uruchomieniem YARN, czy też jest używane tylko w czasie aplikacji (i może być zmieniane z jednego zadania do drugiego)?
Sędzia Mental
1
mogłem ustawić w czasie aplikacji. w szczególności w interaktywnej konsoli gałęzi.
hiroprotagonista
8

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.

Brian G.
źródło
1

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"
    }
  }
]
pandorabob
źródło
1

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.
Rathan
źródło
1

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> 
Sanjay Singh
źródło
Na WSL komunikat o błędzie ma absurdalne liczby (przynajmniej dla mnie): „... działa poza limitami pamięci wirtualnej. Obecne użycie: 338,8 MB z 2 GB pamięci fizycznej; używane 481,1 GB z 4,2 GB pamięci wirtualnej. Kontener zabijania ”.
Samik R
@SamikR Tak, mam podobną sytuację, myślę, że to nie jest kwestia hadoopów, to sprawy WSL. Może muszę przenieść demo na prawdziwy komputer z systemem Linux
Bingoabs
0

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.

Sida Zhou
źródło