2012-04-11 14 views
6

Ho cercato e non ho trovato molte informazioni relative ai processi di Hadoop Datanode che muoiono a causa del limite di sovraccarico del GC superato, quindi ho pensato di pubblicare una domanda."Limite di sovraccarico GC superato" su Hadoop .20 datanode

Stiamo eseguendo un test in cui è necessario confermare che il cluster Hadoop può gestire la presenza di circa 3 milioni di file memorizzati (attualmente un cluster a 4 nodi). Stiamo usando una JVM a 64 bit e abbiamo assegnato 8 g al namenode. Tuttavia, poiché il mio programma di test scrive più file su DFS, i datanode iniziano a decomporsi con questo errore: Eccezione nel thread "DataNode: [/ var/hadoop/data/hadoop/data]" java.lang.OutOfMemoryError: limite di sovraccarico del GC superato

Ho visto alcuni post su alcune opzioni (GC parallelo?) Immagino che possa essere impostato in hadoop-env.sh ma non sono troppo sicuro della sintassi e sono una specie di novizio, quindi non ha deluso come è fatto. Grazie per l'aiuto qui!

+0

Solo un aggiornamento qui per gente: @ 1.5 milioni di file in dfs, quando la mia JVM a 64 bit era a 1g (impostazione predefinita) i nodi dati iniziarono a morire con questo errore. Quando l'ho aumentato a 2g, è andato via fino a circa 3 milioni di file. Mi chiedo se questo tipo di memoria sia un problema noto o no e, in tal caso, quali altri consigli posso provare a risolverlo? – hatrickpatrick

+0

come detto da Tejas Patil, la dimensione predefinita del blocco è 64 MB. Hadoop carica i metadati per ogni file in memoria ogni volta che viene eseguito. Più file hai, più memoria occuperà. Se questi file sono molto più piccoli delle dimensioni di blocco predefinite e hai la possibilità di farlo, prova a combinare i file in file più grandi per archiviarli in HDFS. solo un pensiero :) – sufinawaz

risposta

7

cercare di aumentare la memoria per DataNode utilizzando questo: (riavvio Hadoop necessaria per far funzionare tutto)

export HADOOP_DATANODE_OPTS="-Xmx10g" 

questo imposterà il mucchio a 10GB ... è possibile aumentare secondo il vostro bisogno.

È inoltre possibile incollarlo all'inizio nel file $HADOOP_CONF_DIR/hadoop-env.sh.

+1

Fondamentalmente questo lo ha risolto, ma ho anche imparato che quando si archiviano molti file su un piccolo cluster, l'utilizzo del DataNode sale velocemente perché si possono verificare repliche di posti limitati. Se aggiungiamo nodi, la memoria del nodo dati non dovrebbe salire così velocemente (così ho sentito!). – hatrickpatrick

+1

@hatrickpatrick HDFS utilizza 64 MB di blocchi per archiviare i file ... se i file sono piccoli, verrà sprecata molta memoria e persino il namenode dovrà tenerne traccia. Avere pochi ma enormi file è meglio che avere molti piccoli file. –

-3

Il limite di sovraccarico del GC indica che il tuo (piccolo) heap è pieno.

Questo è ciò che spesso accade nelle operazioni MapReduce quando si elaborano molti dati. Prova questo:

< proprietà>

< nome> mapred.child.java.opts </name>

< valore> Xmx1024m XX: -UseGCOverheadLimit </value>

</proprietà>

Inoltre, prova le seguenti cose:

Utilizzare combinatori, i riduttori non dovrebbero avere alcun elenco più lungo di un piccolo multiplo del numero di mappe

Allo stesso tempo, è possibile generare heap dump da OOME e analizzare con YourKit, ecc adn analizzarlo

+2

Questo è semplicemente sbagliato. –

+0

@ThomasJungblut +1. mapred.child.java.opts può essere usato come heap di controllo per i lavori hadoop generati e non sul datanode. –

+1

ok, non l'ho controllato Ma, in realtà il suo problema è di due tipi: (1) Limitazione della memoria dei nodi di dati (2) Tra l'ordinamento dei passaggi ecc. Quindi, il punto è che non aumentiamo ciecamente la dimensione dell'heap del nodo dati t0 10 GB, 20 GB così, se possiamo sintonizzarci con i parametri (come sopra specificato) e usare i combinatori, penso che la soluzione sarebbe buona. –

0

Se si sta eseguendo una mappa ridurre il lavoro dalla riga di comando, è possibile aumentare l'heap utilizzando il parametro -D 'mapreduce.map.java.opts=-Xmx1024m' e/o -D 'mapreduce.reduce.java.opts = -Xmx1024m'. Esempio:

hadoop --config /etc/hadoop/conf jar /usr/lib/hbase-solr/tools/hbase-indexer-mr-*-job.jar --conf /etc/hbase/conf/hbase-site.xml -D 'mapreduce.map.java.opts=-Xmx1024m' --hbase-indexer-file $HOME/morphline-hbase-mapper.xml --zk-host 127.0.0.1/solr --collection hbase-collection1 --go-live --log4j /home/cloudera/morphlines/log4j.properties 

Si noti che in alcuni documenti Cloudera, che usano ancora i vecchi parametri mapred.child.java.opts, mapred.map.child.java.opts e mapred.reduce.child.java.opts. Questi parametri non funzionano più con Hadoop 2 (vedere What is the relation between 'mapreduce.map.memory.mb' and 'mapred.map.child.java.opts' in Apache Hadoop YARN?).

0

Questo problema risolto per me.Hadoop streaming "GC overhead limit exceeded"

Quindi, la chiave è quello di "anteporre quella variabile di ambiente" (1a volta visto questa sintassi di comando di Linux :))

HADOOP_CLIENT_OPTS = "- Xmx10g" jar Hadoop "your.jar" "source.dir" "target.dir"

Problemi correlati