2017-07-04 1 views
0

J'essaie de compresser chaque bit de mon cluster lors de la configuration de l'application spark, mais il semble que je ne comprends pas tout à fait correctement. Donc, je lance l'application sur un cluster AWS EMR avec 1 maître et 2 nœuds principaux de type m3.xlarge (15G ram et 4 vCPU pour chaque nœud). Cela signifie que par défaut, 11,25 Go sont réservés sur chaque nœud pour les applications programmées par le fil. Ainsi, le nœud maître est utilisé uniquement par le gestionnaire de ressources (fil), ce qui signifie que les 2 nœuds centraux restants seront utilisés pour planifier les applications (nous avons donc 22.5G à cette fin). Jusqu'ici tout va bien. Mais voici la partie que je ne comprends pas. Je commence l'application d'allumage avec les paramètres suivants:Configuration de l'application Spark streaming avec YARN

--driver mémoire 4G --num-exécuteurs 4 --executor-conducteurs 7 --executor-mémoire 4G

Qu'est-ce signifie par mes perceptions (de ce que j'ai trouvé en tant qu'information) est que pour le conducteur sera attribué 4G et 4 exécuteurs seront lancés avec 4G chacun d'eux. Donc une estimation grossière fait 5 * 4 = 20G (permet de les faire 21G avec les réserves de mémoire attendues), ce qui devrait être bien puisque nous avons 22.5G pour les applications. Voici une capture d'écran de l'interface utilisateur du fil de Hadoop après le lancement:

enter image description here

Ce que nous pouvons voir que 17,63 sont utilisés par l'application mais un peu moins que le taux prévu ~ 21G et cela déclenche la première question: que s'est-il passé ici? Puis je vais à la page des exécuteurs de l'UI spark. Voici la grande question:

enter image description here

Les exécuteurs sont 3 (non 4), la mémoire allouée pour eux et le conducteur est 2.1g (pas la 4G spécifiée). Donc, le fil hadoop dit 17.63G sont utilisés, mais l'étincelle dit 8.4G sont alloués. Alors, que se passe-t-il ici? Est-ce lié au planificateur de capacité (de la documentation je n'ai pas pu arriver à cette conclusion)?

Répondre

0

Pouvez-vous vérifier si spark.dynamicAllocation.enabled est activé. Si tel est le cas, votre application peut donner des ressources au cluster si elles ne sont plus utilisées. Le nombre minimum d'exécuteurs à lancer au démarrage sera déterminé par spark.executor.instances. Si ce n'est pas le cas, quelle est votre source pour l'application étincelle et quelle est la taille de partition définie pour cela, spark mappera littéralement la taille de la partition aux cœurs d'étincelles, si votre source n'a que 10 partitions, et quand vous essayez d'allouer 15 cœurs, il n'utilisera que 10 cœurs car c'est ce qui est nécessaire. Je suppose que cela pourrait être la cause que l'étincelle a lancé 3 exécuteurs au lieu de 4. En ce qui concerne la mémoire, je recommanderais de revisiter parce que vous demandez 4 exécuteurs et 1 pilote avec 4 Go chacun, ce qui équivaut à 5*4+5*384MB équivaut à 22GB et vous essayez de utilisez tout et il ne reste pas grand chose pour votre système d'exploitation et nodemanager pour exécuter ce ne serait pas la façon idéale de faire.

+0

L'allocation dynamique est activée et c'est OK (elle alloue 22g sur 30g-2 nœuds avec 15G chacun). Donc, ces 22G ne sont alloués que pour le gestionnaire de ressources de fils et j'ai 4G sur chaque nœud pour le système d'exploitation. Donc, ce 5 * 4 + 5 * 384 Mo est tout à fait correct. Le problème est qu'il n'alloue pas toute la mémoire comme vous pouvez le voir sur les captures d'écran. –