Hadoop: Heap-Speicher und gc Probleme

Ich arbeite derzeit an einem Projekt, wo ich brauche, um eine in-memory-Struktur für meine map-Aufgabe. Ich habe einige Berechnungen, und ich kann sagen, dass ich nicht brauchen, mehr als 600 MB Speicher für jeden map-task.
Aber die Sache ist, dass nach einer Weile ich habe java heap space Probleme oder gc overhead limit. Ich weiß nicht, wie kann dies möglich sein.

Hier sind einige weitere details. Ich habe zwei, quad-core-system mit 12 GB ram. Das bedeutet also, ich kann bis zu 8 anzeigen Aufgaben zur gleichen Zeit ausgeführt. Ich Baue einen Baum, so habe ich einen iterativen Algorithmus, das eine map-reduce-job für jeden Baum Ebene. Mein Algorithmus funktioniert gut für kleine Datensätze, aber für eine Mittel-dataset heap space Probleme. Mein Algorithmus erreicht eine bestimmte Baum-Ebene und dann geht es aus der heap-Speicher, oder hat gc overhead Probleme. An diesem Punkt, habe ich einige Berechnungen, und ich sah, dass jede Aufgabe braucht nicht mehr als 100 MB Speicher. Also für 8 Aufgaben, ich bin mit über 800 MB Speicher. Ich weiß nicht, was Los ist. Ich habe sogar meine aktualisierten hadoop-env.sh die Datei mit diesen Zeilen:

   export HADOOP_HEAPSIZE=8000
   export HADOOP_OPTS=-XX:+UseParallelGC

Was ist das problem? Diese Linien auch überschreiben Sie die java-Optionen für mein system? Mit parallelGC ist etwas, das ich im internet sah, und es wurde empfohlen, wenn mit mehreren Kernen. 

     edits

Ok, hier sind einige änderungen nach der überwachung heap-Speicher und den Gesamtspeicher.
Verbrauche ich ca 3500MB RAM, wenn Sie laufen 6 Aufgabe zugleich. Das bedeutet, dass jobtracker, tasktracker, namenode, datanode, secondary namenode mein Betriebssystem und 6 Aufgaben, die alle verwenden, 3500 RAM, das ist eine sehr logische Größe. Also warum bekomme ich eine gc overhead limit???
Ich Folgen Sie den gleichen Algorithmus, der für jeden Baum Ebene. Das einzige was sich ändert ist die Anzahl der Knoten in jedem Baum Ebene. Viele Knoten in einem Baum der Ebene, nicht so viel overhead für meinen Algorithmus. Also warum kann der gc gut funktionieren?

  • Könntest du bitte posten Sie Ihre Karte und reduzieren Methoden?
  • ich könnte ja, aber Sie sind ein bisschen kompliziert. Posten mein code wäre hier sehr verwirrend. Wenn Sie immer noch wollen, um es zu sehen, Fragen Sie mich wieder
InformationsquelleAutor jojoba | 2012-03-14
  1. 5

    Wenn Sie die maximale Speicher-Größe hat sich nicht verändert, es werden 1/4 Hauptspeicher, d.h. über 3 GB plus etwas overhead für nicht-heap-Auslastung könnte 3,5 GB.

    Ich schlage vor, Sie versuchen

    export HADOOP_OPTS="-XX:+UseParallelGC -Xmx8g"

    legen Sie den maximalen Arbeitsspeicher auf 8 GB.

    Standardmäßig die maximale heap-Größe 1/4 des Speichers (es sei denn, Sie eine 32-bit-JVM unter Windows). Also, wenn die maximale heap-Größe wird ignoriert, es wird immer noch 3 GB.

    Ob Sie einen Tisch oder ein anderes, es wird nicht viel Unterschied wenn Sie aus dem Speicher.

    Ich schlage vor, Sie nehmen ein heap-dump mit -XX:+HeapDumpOnOutOfMemoryError und Lesen Sie diese in ein profiler, z.B. VisualVM zu sehen, warum es so viel Speicher.

    • ich bin mit fedora 12 consantine 64-bit. Setze ich diesen Befehl in HADOOP_OPTS ???
    • Oder Sie laufen können, VisualVM, während das Programm läuft, um zu sehen, wie viel Speicher verwendet wird.
    • ok, danke. ich werde versuchen, mit VisualVM und poste meine Ergebnisse
    • Können Sie ein Profil der Speicher, um zu sehen, was ist mit dem Speicher.
    • Also Sie sagen mir, dass ich irgendwie alle 8GB Speicher??
    • Sie werden in der Lage sein zu sehen, ob es nutzt, dass viel und brechen wie die Klassen mit den meisten Raum ein.
    • conf/hadoop-env.sh: Zeile 19: export: `-mx8g': not a valid identifier
    • nope, es hat nicht funktioniert entweder. Ich konnte sogar das problem, schneller als erwartet.
    • Können Sie sehen, dass die maximale heap-Größe von 8 GB, oder ist es etwas niedriger?
    • Nein, ich kann nicht sehen, dass,..wie kann ich sehen, wenn festgelegt wurde, um 8 GB?
    • In VisualVM, können Sie sehen, was die aktuelle heap-Größe wird in der memory-Grafik. Es wird wachsen, um das maximum, bevor es stirbt.

    InformationsquelleAutor Peter Lawrey
Schreibe einen Kommentar