Je jouais avec une application de shell distribuée (Hadoop-2.0.0-CDH4.1.2).
C'est l'erreur que je reçois pour le moment. La partie intéressante est que, il semble y avoir aucun problème avec la configuration, car un simple concernant la configuration, pour la commande en question, le "ping localhost" a généré deux réponses , comme on peut le voir à partir du Alors, quel pourrait être le problème? ls ou Uname est terminé avec succès et la sortie était disponible dans le conteneur2 stdout. yarn.nodenamager.vmem-pmem-ratio est 3 et la mémoire physique totale disponible est de 2 Go, ce que je pense est plus que suffisant, par exemple pour exécuter. conteneurlogs / conteneur_1357039792045_0005_01_000002 / 721917 / STDOUT /? START = -4096.
6 Réponses :
OK, découvert. Augmentez le paramètre Master Memory à plus de 750 Mo et vous réussirez à exécuter l'application de fil.
Il serait utile de mentionner quel paramètre et n'importe quelle référence où vous avez trouvé cela.
Dans le message d'erreur, vous pouvez voir que vous utilisez plus de mémoire virtuelle que votre limite actuelle de 1,0 Go. Cela peut être résolu de deux manières:
Désactiver la vérification de la limite de mémoire virtuelle Le fil va simplement ignorer la limite; Pour ce faire, ajoutez ceci à votre La valeur par défaut de ce paramètre est Augmentez la mémoire virtuelle au rapport de la mémoire physique dans votre la valeur par défaut est Vous pouvez également augmenter la quantité de mémoire physique que vous allouez à Un conteneur. Assurez-vous de ne pas oublier de redémarrer le fil après avoir changé la configuration. yarn-site.xml : vrai . Yarn-Site.xml Changez ceci à un niveau supérieur valeur que est actuellement définie 2.1
Cette solution a fonctionné exactement ce qui est décrit par TM Liye. Merci beaucoup! Sauvé beaucoup de mon temps. Note - Vous devez redémarrer le fil STOP-YARN.SH/START-YARN.SH
Nul besoin de changer la configuration du cluster. J'ai découvert que je ne fais que fournir le paramètre supplémentaire à distanc m'a aidé pour moi.
Merci, vous avez sauvé ma vie :) Je pensais devoir changer de configuration et redémarrer l'ensemble du cluster, mais augmenter la mémoire travaillée dans mon cas. Exécution également discicp .
Content ça aidé! Je me rends compte que la question initiale ne concerne pas discicp , mais je pense que c'est fondamentalement le même problème qui devrait avoir la même solution.
Aussi m'a aidé. Merci!
Si vous exécutez Tez-Framework, il faut définir les paramètres ci-dessous dans Tez-Site.xml et dans le site de fil-site.xml Tous ces paramètres sont obligatoires à définir
Vous pouvez modifier ceci en une valeur supérieure à celle par défaut 1 Go de votre site de fil-site.xml
yarn.app.mapreduce.am.resource.mb
Dans la pratique, j'ai vu ce problème surviennent lors de l'exécution de requêtes contre de grandes tables ou des tables contenant un grand nombre de fichiers / de petits fichiers ou de tables non garantis ou d'interrogeant un grand nombre de partitions.
Le problème survient lorsque Tez tente de calculer le nombre de mappeurs qu'il a besoin de frayer et tout en faisant ce calcul, il a tendance à passer à la fois en raison de la valeur par défaut (1 Go) est trop inférieur.
Le moyen de résoudre ce problème est de ne pas définir Le réglage doit être soit défini sur * -Site.xml ou tout en accumulant la coque de la ruche comme ci-dessous:
Dans l'exemple ci-dessus, je signalant le fil de signalisation pour frayer le Am pour être de 2 Go au lieu de la valeur par défaut.
tez.am.resource.memory.mb pour dire 2GB ou 4GB.
En outre, une chose de plus très importante est que ce paramètre ne peut pas être réglé à partir de la requête de la ruche comme il est trop tard. Le premier conteneur est le premier conteneur à être engendré par le fil, ce qui, dans la requête de la ruche, n'est pas utile.
HIVE --HIVECONF TEZ.AM.RESOURCE.MEMORY.MB = 2048 My-GRAND-QUERY.HQL