2016-02-22 18 views
5

Mam zlecenie MR, w którym faza losowania trwa zbyt długo.Faza Shuffle trwa zbyt długo Hadoop

Początkowo myślałem, że to dlatego, że emituję dużo danych z Mappera (około 5 GB). Następnie naprawiłem ten problem, dodając Combiner, w ten sposób emitując mniej danych do Reducer. Po tym okresie losowania nie skrócił się, jak myślałem, że będzie.

Moim następnym pomysłem było wyeliminowanie Combiner, poprzez połączenie w samym programie Mapper. Pomysł ten dostałem z here, gdzie mówi się, że dane muszą być serializowane/deserializowane, aby użyć Combiner. Niestety faza losowania jest wciąż taka sama.

Moja jedyna myśl jest taka, że ​​może to być spowodowane tym, że używam pojedynczego reduktora. Ale nie powinno to być przypadkiem, ponieważ nie emituję dużej ilości danych podczas korzystania z programu Combiner lub łączenia w programie Mapper.

Oto moje statystyki:

enter image description here

Oto wszystkie liczniki dla mojego Hadoop (przędza) Praca:

enter image description here

Należy również dodać, że jest uruchomiony na mała grupa 4 maszyn. Każdy ma 8 GB pamięci RAM (zarezerwowane 2 GB), a liczba rdzeni wirtualnych wynosi 12 (2 zarezerwowane).

enter image description here

Są to maszyny wirtualne. Najpierw wszyscy byli na jednej jednostce, ale potem rozdzieliłem ich 2-2 na dwie jednostki. Na początku dzielili się dyskami twardymi, teraz na jednym dysku są dwie maszyny. Pomiędzy nimi jest sieć gigabitowa.

A oto więcej statystyki:

cała pamięć jest zajęta

enter image description here

procesora jest stale pod presją, gdy prowadzona jest praca (zdjęcie przedstawia procesor dla dwóch kolejnych przebiegów samej pracy)

enter image description here

Moje pytanie brzmi - dlaczego jest tak duży czas Shuffle i ho w to naprawić? Nie rozumiem też, że nie było przyspieszenia, mimo że znacznie zmniejszyłem ilość danych wysyłanych przez Mappera.

+0

trudno powiedzieć bez coraz więcej numerów: Jaka jest dokładna wielkość produkcji map? jak duże jest połączenie sieciowe między twoim serwerem (przepustowość)? czy możesz użyć więcej niż jednego reduktora (unikając w ten sposób wąskiego gardła przepustowości)? –

+0

Dziękuję za komentarz, zredagowałem moje pytanie. Naprawdę nie mam pojęcia, dlaczego byłoby tak wolno. Opracowałem głównie na jednej maszynie, więc uczę się o uruchamianiu zadań w klastrze, ale nie widzę powodu dla tego problemu. Byłoby bardzo trudno (jeśli nie niemożliwe) podzielić reduktor, ale chodzi o to, że nie widzę dla niego żadnej pracy. – Marko

+0

Trudno powiedzieć, dlaczego tak długo trwa 5mb, czegokolwiek niezwykłego można zobaczyć w ambari? jak sztywny procesor? możesz przejść do logów kontenera redukującego i znaleźć cokolwiek? –

Odpowiedz

0

kilka uwag:

  1. Do pracy 30 minut, czas GC jest zbyt wysoka (Spróbuj ponownego użycia przedmiotów raczej stworzenie nowego jednym dla każdej rozmowy na mapie()/Reduce() metoda)
  2. Średni czas mapy to zbyt wysokie, 16 minut co robisz na mapie?
  3. Pamięć YARN ma wartość 99%, co oznacza, że ​​w klastrze HDP działa zbyt wiele usług, a pamięć RAM nie jest wystarczająca do obsługi wielu usług.
  4. Proszę podnieść pamięć kontenera YAN, proszę podać co najmniej 1 GB.
  5. To wygląda na problem GC + overscheduled klastra
Powiązane problemy