Spark ressources qui ne sont pas entièrement alloué sur Amazon EMR
Je suis en train de maximiser l'utilisation de cluster pour une tâche simple.
Cluster est de 1+2 x m3.xlarge, runnning Étincelle 1.3.1, Hadoop 2.4, Amazon AMI 3.7
La tâche lit toutes les lignes d'un fichier texte et de les analyser en tant que fichier csv.
Quand j'ai de l'étincelle-soumettre une tâche comme un fil-mode cluster, je reçois un de le résultat suivant:
- 0 exécuteur testamentaire: job attend à l'infini jusqu'à ce que je le supprimer manuellement
- 1 liquidateur: travail en vertu d'utiliser les ressources avec seulement 1 machine de travail
- OOM quand je n'attribuez pas assez de mémoire sur le pilote
Ce que j'aurais attendu:
- Étincelle pilote exécuter sur un cluster de maître avec toute la mémoire disponible, plus 2 exécuteurs testamentaires avec 9404MB chaque (tel que défini par installer-spark script).
Parfois, quand je reçois un "succès" exécution avec 1 exécuteur testamentaire, le clonage et le redémarrage de l'étape se termine avec 0 exécuteur testamentaire.
J'ai créé mon cluster à l'aide de cette commande:
aws emr --region us-east-1 create-cluster --name "Spark Test"
--ec2-attributes KeyName=mykey
--ami-version 3.7.0
--use-default-roles
--instance-type m3.xlarge
--instance-count 3
--log-uri s3://mybucket/logs/
--bootstrap-actions Path=s3://support.elasticmapreduce/spark/install-spark,Args=["-x"]
--steps Name=Sample,Jar=s3://elasticmapreduce/libs/script-runner/script-runner.jar,Args=[/home/hadoop/spark/bin/spark-submit,--master,yarn,--deploy-mode,cluster,--class,my.sample.spark.Sample,s3://mybucket/test/sample_2.10-1.0.0-SNAPSHOT-shaded.jar,s3://mybucket/data/],ActionOnFailure=CONTINUE
Avec une certaine étape, y compris les variations:
--pilote-mémoire 8G --pilote de cœurs 4 --num exécuteurs testamentaires 2
installer-spark script avec -x produit est le suivant étincelle de paramètres par défaut.conf:
$ cat spark-defaults.conf
spark.eventLog.enabled false
spark.executor.extraJavaOptions -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:MaxHeapFreeRatio=70
spark.driver.extraJavaOptions -Dspark.driver.log.level=INFO
spark.executor.instances 2
spark.executor.cores 4
spark.executor.memory 9404M
spark.default.parallelism 8
Mise à jour de 1
- Je obtenir le même comportement avec un générique JavaWordCount exemple:
/home/hadoop/spark/bin/spark-submit --verbose --master yarn --deploy-mode cluster --driver-memory 8G --class org.apache.spark.examples.JavaWordCount /home/hadoop/spark/lib/spark-examples-1.3.1-hadoop2.4.0.jar s3://mybucket/data/
Cependant, si je supprime le '--pilote-mémoire 8G", la tâche est affectée 2 exécuteurs testamentaires et se termine correctement.
Donc, quel est le problème avec le pilote de mémoire m'empêcher de tâche pour obtenir les exécuteurs?
Si le pilote est exécuté sur le cluster nœud maître du côté du Fils de maître conteneur comme expliqué ici?
Comment puis-je donner plus de mémoire à mon étincelle d'emploi chauffeur? (Où collecte et de certaines autres opérations surviennent)
OriginalL'auteur Michel Lemay | 2015-06-08
Vous devez vous connecter pour publier un commentaire.
La solution pour optimiser l'utilisation de cluster est d'oublier l'option '-x' paramètre lors de l'installation d'étincelle sur les EMR et d'ajuster les exécuteurs de la mémoire et des carottes à la main.
Ce post donne une très bonne explication de la façon dont l'allocation des ressources se fait lors de l'exécution de l'Étincelle sur le FILS.
Une chose importante à retenir est que toutes les exécuteurs testamentaires doivent avoir les mêmes ressources allouées! Comme nous parlons, l'Étincelle ne prend pas en charge hétérogène exécuteurs testamentaires. (Certains travaux sont actuellement déployés pour soutenir les Gpu mais c'est un autre sujet)
Pour en tirer le maximum de l'allocation de la mémoire pour le conducteur, tout en maximisant la mémoire pour les exécuteurs testamentaires, je dois partager mon nœuds comme ceci (ce slideshare donne de bonnes captures d'écran à la page 25):
REMARQUE: une Autre option serait de
spark-submit
avec--master yarn --deploy-mode client
à partir du nœud principal 0. Il n'existe aucun contre-exemple c'est une mauvaise idée?Dans mon exemple, je peux avoir au plus 3 exécuteurs de 2 vcores avec 4736 MO + un conducteur ayant les mêmes caractéristiques.
4736 mémoire est dérivée de la valeur de
yarn.nodemanager.resource.memory-mb
défini dans/home/hadoop/conf/yarn-site.xml
. Sur une m3.xlarge, il est mis à 11520 mo (voir ici pour toutes les valeurs associées à chacun des types d'instance)Alors, nous obtenons:
(11520 - 1024) /2 (exécuteurs testamentaires par nœuds) = 5248 => 5120 (arrondi à 256 mo de l'incrément défini dans le fil.le planificateur.minimum-allocation-mo)
7% * 5120 = 367 arrondi jusqu'à 384 (surcharge de la mémoire) deviendra à 10% dans de l'étincelle 1.4
5120 - 384 = 4736
D'autres liens intéressants:
Votre nœud de répartition implique que le pilote ne fonctionne pas sur le gestionnaire de ressources (Maître de l'instance dans EMR). Est-ce le cas? (essayer d'envelopper ma tête autour de tout cela) (lors de l'exécution en tant que fil-cluster)
Oui, c'est ce qu'il dit.. à Moins que je me trompe, je n'ai rien vu d'exécution sur le nœud maître lors de l'utilisation d'un fil de mode cluster.
Merci mec. Je ne peux pas croire Amazon ont sali cette sorte massivement. J'ai été en utilisant DME pour exécuter étincelle sur le FILS et ont été de me gratter la tête pourquoi un seul vCPU a été utilisé par nœud. Je préfère qu'ils n'a tout simplement pas la peine de paramètre par défaut au lieu de la mise cripplingly ceux qui sont inutiles 🙁
merci pour le réponse, puis-je vous demander pourquoi vous avez soustrait 1 024 à partir de la mémoire du nœud? est-il réservé pour le système d'exploitation?
OriginalL'auteur Michel Lemay
Le problème est autour des attentes pour comment Spark fonctionne sur le FILS. Lorsque l'Étincelle est de fonctionner avec un mode de déploiement de cluster ou de l'ensemble maître-à-fil-cluster le pilote est pas exécuté sur le nœud maître, mais dans l'Application conteneur Maître sur l'un des nœuds esclaves. Pour plus de détails, voir https://spark.apache.org/docs/latest/running-on-yarn.html
J'attends de ce qui se passe est que le cluster ne peuvent pas satisfaire les besoins en mémoire pour le conducteur (rappelez-vous que la mémoire effectivement demandé de le cluster est ce que vous demandez en plus des frais généraux) et donc en attente pour toujours allouer la Demande de Maître où le pilote s'exécutent ou des liquidateurs.
Pour donner au conducteur la quantité de mémoire que vous demandez, vous devrez utiliser d'autres esclaves afin de fournir des ressources pour le cluster de base de pilote et les exécuteurs en même temps. Avec la surcharge sur le pilote, je soupçonne que vous pourriez avoir besoin d'utiliser un type d'instance avec plus de mémoire. Lorsque vous demandez 8G pour le pilote de prendre un coup d'oeil dans le gestionnaire de ressources du journal et de vérifier le montant réel demandé.
Pour exécuter le pilote sur le nœud maître du mode de déploiement aurait besoin d'être client. Ce qui peut encore être fait avec DME étapes si vous utilisez une étape à l'appel d'un script pour localiser le jar du pilote sur le nœud maître et ensuite, l'étape suivante peut appeler étincelle présenter ensemble pour le déploiement en mode client et le référencement du POT sur la maîtrise locale du système de fichiers.
Le pilote n'est pas pour exécuteur, en parallèle, un travail. Juste pour quoi que ce soit perçue et la gestion de la SparkContext interaction/ordonnancement. Avec un 3 installation de la machine il n'y aurait que 2 nœuds pour les conteneurs. Si vous voyez le pilote mais pas de exécuteurs... à regarder de plus près les journaux à partir du pilote et gestionnaire de ressources afin de déterminer pourquoi un exécuteur testamentaire ne peut pas tourner sur la 2ème nœud.
OriginalL'auteur ChristopherB
Michel Lemay post est une bonne lecture de base, et il donne une réponse de 1 en particulier de la configuration du cluster. J'ai intégré cette logique dans une feuille de calcul qui permettra de présenter les meilleures options de cluster. Pour l'utiliser, remplissez le nombre de nœuds dans le cluster, le nombre de cœurs virtuels/nœud, et le montant de affectables mémoire/nœud. Après cela, la feuille de calcul, vous donner des options pour lancer des commandes qui permettront d'exploiter pleinement votre cluster pour une client & mode de cluster pour 1, 2, 4, et 8 exécuteurs testamentaires par nœud. J'ai mis en évidence la ligne correspondant à 2 exécuteurs testamentaires par nœud, comme cela a toujours été la meilleure option dans mes tests. N'hésitez pas à copier cette feuille ou ajouter des onglets pour les différents types de cluster que vous le souhaitez.
https://docs.google.com/spreadsheets/d/1VH7Qly308hoRPu5VoLIg0ceolrzen-nBktRFkXHRrY4/edit?usp=sharing
OriginalL'auteur David
Voici comment j'ai contourner le problème:
Par réglage de l'allumage.exécuteur testamentaire.mémoire + pilote-mémoire ci-dessous le total de chaque nœud MAÎTRE, puis le FIL est en mesure de placer à la fois le Maître et l'exécuteur sur un nœud donné.. Vous sacrifier un peu perdu la mémoire sur les autres nœuds, mais les plus importantes que j'ai le Cpu en cours d'exécution. Voici un exemple (sur r3.8xlarge):
OriginalL'auteur Jeremy