首先，进行了性能测试。我发现该视频地图的n数度关系的应用被分为5个作业。最后的工作是将结果保存到HDFS，其余作业是相同计算过程的重复迭代。数字。
通过阅读程序代码，发现第一个作业需要初始化一个空数组，该数组生成一个阶段，但是此阶段表明，性能测试结果表明，超过合理的预期范围需要14秒钟时间，发现在此期间有一定数量的开销。实际上，这只是内存数据的初始化，并且在需要网络通信的代码上看不到代码。下面的图是一个计算节点之一的通信开销。发现在第一阶段，几乎没有通信操作。通信操作的通信操作约为每秒几十MB。
分析SPARK运行日志，并发现此阶段主要花费时间不是处理应用程序的计算逻辑，而是从驱动程序过程中下载应用程序代码。如前所述，Spark和MapReduce都转到数据的服务器节点。通过移动计算程序定位，从而节省了数据传输网络通信开销和分布式计算，即移动计算比移动数据更具成本效益，并且在执行此阶段的移动计算程序。
由于此视频关系图计算程序依赖于第三个方案软件包，因此包装后整个计算程序超过17MB。此17MB JAR软件包需要在所有计算服务器（即Worker节点）上部署。但是，只有17MB的数据不能花费太多时间？
在进一步分析了火花日志和代码后，发现将在每个计算节点上激活多个执行程序进程以进行计算，而SPARK的策略是由每个执行程序流程下载应用程序JAR包。当时，每台机器启动30 execor ProcessEsthis是4×30 = 120流程下载，驱动程序过程所在的机器是一张千兆网卡，它的成本为14秒才能完成这些数据传输。
找到问题后，解决方案是显而易见的。同一服务器上的多个执行程序进程不必通过Internet下载应用程序。仅将一个过程下载到局部区域后，其他过程可以将此文件复制到他们自己的工作路径。
该代码需要注意技术实施的细节。当多个进程同时下载程序包时，如何确保只有一个进程可下载，而其他过程则阻止了等待过程的同步。
解决方案是在过程中使用本地文件作为同步锁定。只能下载获得文件锁的过程。其他进程无法获得文件锁定。
这种优化的测量效果很好。第一阶段从14秒下降到小于1秒钟，效果显着。
这种情况的具体代码：https：//github.com/apache/spark/pull/1616
比较4个工具机器的使用：
在第一个作业的第二阶段，第三台机器的CPU使用率与其他机器的使用率显着不同，即计算资源利用不平衡的使用：存在繁忙且空闲的资源分配方法通常会导致性能问题。
分析火花日志和源代码。当使用驱动程序的免费计算资源注册的工人节点将触发SPARK任务分配。
但是测得的结果是在第二阶段，只有一位工作人员执行了任务，而其他服务器没有执行！
分析日志，并发现工人节点首先在驱动程序中注册，然后第一个注册的工作者开始接收任务。如果：
$由任务数量提供的工人提供的计算单元数将导致工人承担所有任务。
第一份工作的第二位是场景。演示数据很小。根据HDFS默认值的大小，只有17个块。第二阶段是为初始迭代计算加载这17个块。计算要完成的任务，因此，当第三个服务器首先在其他三个服务器中注册的第三台服务器时，触发了驱动程序的任务分配，并将所有17个任务带走。
同时，为了避免此类工人的首次注册，首先导致整个任务，考虑添加配置项目，只有注册的计算资源达到阈值比率以开始任务：
为了避免注册注册计算资源的注册，无法分配任务。执行任务后，添加了另一个配置项目，即最小等待时间，超过了最小等待时间（秒）。无论是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率是否达到注册率是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率是否达到注册率是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否达到注册率，是否已达到注册率注册的比例。所有人开始分配任务。
在启用了两个配置项之后，第二阶段任务均匀分配给4个工作人员，并且执行时间缩短了1.32次。4个Worker Server的CPU利用率也非常平衡。
您可以参考这种情况的特定代码：https：//github.com/apache/spark/pull/900https：//github.com/apache/spark/park/spark/pull/1525
从情况2中查看几个CPU利用率的图，我们还发现，所有4名工人的CPU的最大利用率只能达到60％以上。例如，在下图中，绿色部分为CPU空闲。
该资源使用瓶颈的分析，而无需分析火花日志和源代码。根据SPARK的原理，发现当时使用的CPU48核心在应用程序配置中使用的最大执行程序为120，每个服务器30个任务，尽管30个任务在每个CPU核心上100％运行，但是总CPU使用量仍然只有60％。
优化也很简单。应用程序启动参数的执行人数为48×4 = 192。
在性能测试中，发现使用不同的服务器时，CPU资源的使用也不同。某些服务器CPU在系统中，也就是说，系统状态的比例很高：
在该图中，紫色处于系统状态，在某些时候，SYS状态占CPU总使用率的近80％。该比例显然是不合理的。系统计算。
那么，操作系统忙碌而占用了很多CPU时间？通过跟踪Linux内核执行指令，这些系统状态的执行指令与Linux的配置参数有关，透明的巨大页面有关。
当打开透明的拥抱页面时，SYS -STATE CPU消耗将增加，并且透明的巨大页面的不同Linux版本默认为默认值是否有所不同。为了指示透明的巨大页面默认值的Linux，请关闭透明的巨大页面。
关闭后，与先前的CPU消耗相比，系统的比例大大下降，总应用时间消耗也大大下降。
分析网卡资源的消费，发现网络通信是一种瓶颈，这对整个应用程序都有明显的影响。
例如，在第二和第三作业中，网络通信消耗为50，网络读取和写作通信已达到网卡的最大吞吐量，整个集群都在等待网络传输。
千兆网卡的最大传输速率为125MB/s。这个速率绝对不能与CPU内存相提并论。尽管它比单个磁盘快，但服务器磁盘是8个磁盘的数组。总磁盘吞吐量粉碎了千兆网络卡，这是当前的瓶颈，网卡传输速率已成为系统性能瓶颈。
优化非常简单：使用10D卡。
50年代的网络通信时间被用来缩短到大约10。从性能曲线的角度来看，当网络通信仅触及网络卡的最大传输速率时，将完成传输，总计算时间缩短了几乎100s。
大数据软件性能优化将涉及硬件，操作系统，大数据产品及其配置，应用程序开发和部署方面。当性能无法满足需求时，首先查看性能指标是否合理。如果资源未完全使用，则可能是不合理的，或者需要优化大数据应用程序（包括SQL语句）；限制，则有必要具体分析。它是集群资源不足。需要添加新的硬件服务器。仍然有必要优化某个硬件，操作系统或JVM，甚至是大数据产品的源代码。