Почему выполнение spark-shell на YARN два раза приводит к ожиданию второго? - PullRequest
0 голосов
/ 02 сентября 2018

Я настраиваю свой кластер Hadoop для тестирования и помещаю все в 3 контейнера Docker.

Мой файл spark-defaults.conf на мастере:

spark.master                     yarn
spark.eventLog.enabled           true
spark.eventLog.dir               hdfs://spark-master:9000/spark/logs
spark.serializer             org.apache.spark.serializer.KryoSerializer
spark.history.provider          org.apache.spark.deploy.history.FsHistoryProvider
spark.history.fs.logDirectory    hdfs://spark-master:9000/spark-logs
spark.history.fs.update.interval 10s
spark.history.ui.port            18080
spark.driver.memory              512m
spark.executor.memory            512m
spark.yarn.am.memory             512m
spark.yarn.historyServer.address spark-master:18080
spark.executor.instances         1

ядро-site.xml

[root@spark-master hadoop]# cat core-site.xml 
<configuration>
    <property>
        <name>fs.default.name</name>
        <value>hdfs://spark-master:9000</value>
    </property>
    <property>
        <name>io.file.buffer.size</name>
        <value>131072</value>
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/tmp/hadoop</value>
    </property>
</configuration>

пряжа site.xml

[root@spark-master hadoop]# cat yarn-site.xml 
<configuration>
    <property>
        <name>yarn.nodemanager.aux-services</name>
        <value>mapreduce_shuffle</value>
    </property>
    <property>
        <name>yarn.resourcemanager.hostname</name>
        <value>spark-master</value>
    </property>
    <property>
        <name>yarn.nodemanager.resource.memory-mb</name>
        <value>4096</value>
    </property>
    <property>
        <name>yarn.scheduler.maximum-allocation-mb</name>
        <value>4096</value>
    </property>
    <property>
        <name>yarn.scheduler.minimum-allocation-mb</name>
        <value>128</value>
    </property>
    <property>
        <name>yarn.nodemanager.vmem-check-enabled</name>
        <value>false</value>
    </property>
    <property>
        <name>yarn.log-aggregation-enable</name>
        <value>true</value>
    </property>
</configuration>

HDFS-site.xml

[root@spark-master hadoop]# cat hdfs-site.xml 
<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>/hdfs/namenode</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>/hdfs/datanode</value>
    </property>
    <property>
        <name>dfs.namenode.handler.count</name>
        <value>100</value>
    </property>
</configuration>

список узлов пряжи

[root@spark-master /]# yarn node -list
Total Nodes:2
     Node-Id         Node-State Node-Http-Address   Number-of-Running-Containers
cassandra-node-1:39414          RUNNING cassandra-node-1:8042                              1
cassandra-node-2:42546          RUNNING cassandra-node-2:8042                              1

мастер

[root@spark-master /]# jps
1952 SparkSubmit
597 NameNode
458 ResourceManager
1066 SecondaryNameNode
2906 Jps
75 ZeppelinServer
1292 HistoryServer
2702 SparkSubmit

узел-1 * * тысяча двадцать-одина

[root@cassandra-node-1 /]# jps
96 NodeManager
1606 CoarseGrainedExecutorBackend
3094 Jps
231 DataNode

узел-2

[root@cassandra-node-2 /]# jps
229 DataNode
3110 Jps
1565 ExecutorLauncher
94 NodeManager

Здесь все вроде бы хорошо. Я вижу, что в одном контейнере есть диспетчер приложений, а в другом - исполнитель spark shell.

Теперь проблема довольно проста. Все, что я хочу сделать, это выполнить spark-shell два раза - я хотел сделать Сценарий «одна искровая оболочка и один интерпретатор Zeppelin на пряже», но интерпретатор Zeppelin не работал, поскольку ожидал бесконечно, поэтому для простоты я хочу просто запустить две искровые оболочки.

Но когда я собираюсь выполнить вторую оболочку, она застряла, но здесь достаточно ресурсов для использования, верно? Имеется 3,13 ГБ оперативной памяти, из 8 используется только 1 vcore (7 vcore free), все кажется довольно простаивающим, так почему еще одна спарк-оболочка не запущена и не ожидает?

Для ожидающей попытки приложения сообщается, что:

Total Outstanding Resource Requests: <memory:896, vCores:1>

Но у меня достаточно памяти и процессор, похоже, тоже не проблема.

У меня есть 4-ядерный процессор - процессор Intel® Core i5-2540M @ 2.60 ГГц (cat / proc / cpuinfo дает 4 процессора), однако я не понимаю, почему он сообщает, что у меня 8 (может быть, потому что 2 Docker контейнеры, поэтому он думает, что у меня есть 2x4, но у меня есть только 4).

Возможно, проблема в том, что одна оболочка spark занимает 2 ядра, так как она использует 2 контейнера (один для главного приложения, другой для spark executor), а другая оболочка spark также будет использовать 2, поэтому его 4 вместе, но это как-то может выделить только три, а один выдающийся, но почему, когда у меня всего 4?

Первая оболочка запускается без проблем, но вторая «принята», но ожидает ресурсов и работает только в том случае, если я уничтожу первую искрогасительную оболочку.

EDIT

1) список узлов пряжи перед любым применением

Total Nodes:2
         Node-Id         Node-State Node-Http-Address   Number-of-Running-Containers
cassandra-node-2:43961 RUNNING  cassandra-node-2:8042 0
cassandra-node-1:36905 RUNNING  cassandra-node-1:8042 0

2) список узлов пряжи - после запуска первой спарк-оболочки - я попал в консоль спарк-оболочки


Total Nodes:2
         Node-Id         Node-State Node-Http-Address   Number-of-Running-Containers
cassandra-node-2:43961 RUNNING  cassandra-node-2:8042 2
cassandra-node-1:36905 RUNNING  cassandra-node-1:8042 0

3) после запуска второй спарк-оболочки вывод такой же, как в 2) и вторая оболочка дает мне:

[root@spark-master /]# spark-shell
Setting default log level to "WARN".
To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel).
2018-09-04 10:56:14 WARN  Utils:66 - Service 'SparkUI' could not bind on port 4040. Attempting port 4041.

И нет дополнительного выхода, так как он застрял.

Попытка приложения для второй искровой оболочки в бэкэнде hadoop говорит:

Total Outstanding Resource Requests: memory:896, vCores:1
...