Spark集群调试，测试实录

• 背景概述 

    

基于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端口，查看其历史任务，如图：