Erreur de mémoire insuffisante dans la phase de traitement aléatoire de Mapreduce
Je reçois des erreurs étranges lorsque j'exécute un programme wordcount-like mapreduce. J'ai un cluster hadoop avec 20 esclaves, chacun ayant 4 Go de RAM. J'ai configuré mes tâches de carte pour disposer d'un tas de 300 Mo et mes emplacements de tâches réduites de 1 Go. J'ai 2 emplacements de carte et 1 emplacement de réduction par nœud. Tout se passe bien jusqu'à la fin du premier tour des tâches de la carte. Ensuite, la progression reste à 100%. Je suppose que la phase copy est en cours. Chaque tâche de carte génère quelque chose comme:
Map output bytes 4,164,335,564
Map output materialized bytes 608,800,675
(J'utilise SnappyCodec pour la compression)
Après stalling pendant environ une heure, réduisez les tâches, à l’exception suivante:
Error: Java.lang.OutOfMemoryError: Java heap space at
org.Apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.shuffleInMemory(ReduceTask.Java:1703) at
org.Apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.getMapOutput(ReduceTask.Java:1563) at
org.Apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.copyOutput(ReduceTask.Java:1401) at
org.Apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.run(ReduceTask.Java:1333
J'étais en train de googler et j'ai trouvé ce lien, mais je ne sais pas trop quoi en faire: lien commun de hadoop
Je ne comprends pas pourquoi hadoop aurait des problèmes de copie et de fusion s'il était capable de réaliser un benchmark terasort. Il est impossible que toutes les sorties de la carte entrent dans le RAM du thread de réduction. Que se passe-t-il?
Dans le lien fourni ci-dessus, ils discutent de l'optimisation des paramètres suivants:
mapreduce.reduce.shuffle.input.buffer.percent = 0.7
mapreduce.reduce.shuffle.memory.limit.percent = 0.25
mapreduce.reduce.shuffle.parallelcopies = 5
Ils affirment que le fait que le produit des paramètres soit> 1 autorise des erreurs de taille considérable . EDIT: notez que 5 * 1,25 * 0,7 est toujours <1, concentrez-vous sur ma deuxième solution !) Avant de relancer cette simulation intensive, je serais très heureux d’entendre l’opinion de quelqu'un sur le problème auquel je suis confronté, car cela me dérange depuis près d’une semaine. Je semble également ne pas comprendre complètement ce qui se passe dans cette phase de copie, je m'attendrais à ce qu'un tri par fusion sur disque ne nécessite pas beaucoup de taille de tas?
Merci beaucoup à l'avance pour vos commentaires et réponses utiles!
Je pense que l’indice est que la taille de ma tâche de réduction était nécessaire presque complètement pour la phase de réduction. Mais la phase shuffle est en compétition pour le même espace-pile , le conflit qui a surgi a provoqué la fermeture de mes travaux. Je pense que cela explique pourquoi le travail ne se bloque plus si je baisse le shuffle.input.buffer.percent.
Le paramètre que vous citez mapred.job.shuffle.input.buffer.percent est apparemment un paramètre antérieur à Hadoop 2. Je pourrais trouver ce paramètre dans le fichier mapred-default.xml selon le 1.04 docs mais son nom a été remplacé par mapreduce.reduce.shuffle.input.buffer.percent selon le 2.2.0 docs .
Selon la documentation, la description de ce paramètre est la suivante:
Pourcentage de mémoire à allouer de la taille de segment maximale au stockage des sorties de mappe pendant la lecture aléatoire.
Pour une compréhension complète de Sort and Shuffle, voir Chapitre 6.4 du document Hadoop Definitive Guide . Ce livre fournit une autre définition du paramètre mapred.job.shuffle.input.buffer.percent:
Proportion de la taille totale de segment de mémoire à allouer au tampon de sortie de carte pendant la phase de copie de la lecture aléatoire.
Comme vous avez constaté que le fait de réduire la valeur de mapred.job.shuffle.input.buffer.percent de 0.7 par défaut à 0.2 a résolu votre problème, il est assez prudent de dire que vous auriez également pu résoudre votre problème en augmentant la valeur de la taille de segment de mémoire du réducteur.
Même après avoir changé le shuffle.input.buffer.percent en 0.2, cela ne fonctionne pas pour moi et j'ai la même erreur.
Après avoir testé et testé un cluster à un seul nœud, j'ai constaté qu'il devait y avoir suffisamment d'espace dans le répertoire /, car le processus utilisait cet espace en cas de débordement.
Le répertoire des déversements doit également être changé.
Bogue associé - https://issues.Apache.org/jira/browse/MAPREDUCE-6724
Peut provoquer une exception NegativeArraySizeException si maxSingleShuffleLimit calculé> MAX_INT