- 背景概述
基于yarn模式的spark集群，共8个节点。其中，Hadoop和spark均采用CDH5.12.1版本，独立一个节点部署Cloudera Manager Server5，NameNode和SecondNameNode部署于同一个的机器上。
这是一个小型的用于生产环境测试、开发的集群，通过Cloudera manager 管理控制控制平台进行管理和监控。
在完成spark1.6版本升级到spark2.2，经过一些参数配置修改和调试后，集群达到了平衡稳定，如下图：
- 测试过程
本来岁月静好，集群安稳运行，结果今天在启用spark2-shell服务后，在集群各个节点执行jps命令后，发现多了一个进程：ExecutorLauncher，而且仅在NameNode节点显示。如下图：
Feiwei01:Namenode节点：
Feiwei04：其中一个测试节点：
在另一个节点处ssh登陆feiwei04，输入jps命令，查看显示：
本地没有ExecutorLauncher进程。
然后在Cloudera Manager 浏览器页面查看到相应的NameNode节点的物理内存消耗发生变化。
开启spark2-shell服务前：
开启服务后：
我们可以看到，各个节点的内存消耗均有变化，但是NameNode节点和feiwei04测试节点变化最大最明显。
接下来，再在一个节点启动Spark2-shell，jps进程和内存又有变化，如下图：
新增测试节点feiwei06：
NameNode节点Jps新增：
内存新变化：
后续依次增加测试节点，启动shell服务后，jps进程和内存都会变化。
Jps进程会比较随机的在节点上启动，有的节点一个，有的两个，有的没有。一般的，在没有启用shell服务的节点会有一个监听进程。
内存消耗：
- 总结
起初，测试显示好像和NameNode有些关系，因为出现了如图情况：
但是多番测试后，发现并非如此，如图显示就和NameNode节点没有必然联系：
我们都知道spark是基于内存的计算框架，会对内存需求大，在考虑集群规划的时候，往往应该需要考虑到集群整体和各个节点的规划布局，适当冗余，有利于集群资源高效利用。
另外，访问spark主节点的18089端口，查看其历史任务，如图：