性能调优之分配更多资源

分配更多资源

性能调优的王道就是增加和分配更多的资源，性能和速度上的提升是显而易见的。基本上，在一定范围之内，增加资源与性能的提升是成正比的。写完了一个复杂的spark作业之后，进行性能调优的时候，首先第一步，我觉得就是要来调节最优的资源配置，在这个基础之上，如果说你的spark作业，能够分配的资源达到了你的能力范围的顶端之后，无法再分配更多的资源了，那么才是考虑去做后面的这些性能调优的点。

分配哪些资源？

主要是多分配executor、cpu per executor、memory per executor、driver memory

在哪里分配这些资源？

在我们在生产环境中，提交spark作业时，用的spark-submit shell脚本，里面调整对应的参数?
/usr/local/spark/bin/spark-submit \?
–class cn.spark.sparktest.core.WordCountCluster \?
–num-executors 3 \ 配置executor的数量?
–driver-memory 100m \ 配置driver的内存（影响不大）?
–executor-memory 100m \ 配置每个executor的内存大小?
–executor-cores 3 \ 配置每个executor的cpu core数量?
/usr/local/SparkTest-0.0.1-SNAPSHOT-jar-with-dependencies.jar \

调节到多大算是最大呢？

第一种情况，如果使用的是Spark Standalone模式，公司集群上搭建了一套Spark集群，你心里应该清楚每台机器还能够给你使用的大概有多少内存，多少cpu core，那么，设置的时候就根据这个实际的情况去调节每个spark作业的资源分配。比如说你的每台机器能够给你使用4G内存，2个cpu core。一共有20台机器，那么启动20个executor，平均每一个executor分配4G内存，2个cpu core。

第二种情况是基于Yarn的集群。因为Yarn 使用资源队列资源调度。应该去查看你的spark作业要提交到的资源队列大概有多少资源？比如资源队列总共有500G内存，100个cpu core，如果自己的spark作业准备使用50个executor，平均每个executor就是10G内存，2个cpu core。

一个原则：你能使用的资源有多大就尽量去调节到最大的大小（包括executor的数量，大约在几十个到上百个不等，然后executor内存和executor cpu core 调节到最大）。

以Standalone集群模式举例，首先Driver里运行Application，并且Application有自己的SparkContexxt，SparkContext里的DAGScheduler和TaskScheduler会将我们的算子切割成大量的task提交到Application的executor上面去执行，可能一个Executor会分配100个task。

增加executor?
如果executor数量比较少，那么，能够并行执行的task数量就比较少，就意味着，我们的Application的并行执行的能力就很弱。?
比如有3个executor，每个executor有2个cpu core，那么同时能够并行执行的task就是6个。6个执行完以后，再换下一批6个task。当增加了executor数量以后，就意味着，能够并行执行的task数量也就变多了，比如原先是6个，现在可能可以并行执行10个，甚至20个，100个。那么并行能力就比之前提升了数倍，数十倍，相应的，性能（执行的速度），也能提升数倍~数十倍。

增加每个executor的cpu core?
增加每个executor的cpu core也是增加了执行的并行能力。比如原本20个executor，每个才2个cpu core，能够并行执行的task数量，就是40个task。现在每个executor的cpu core增加到了5个，那么能够并行执行的task数量就是100个task，执行的速度就提升了2.5倍。

增加每个executor的内存量?
增加了内存量以后，对性能的提升大概有三点：?
1. 如果需要对RDD进行cache，那么更多的内存就可以缓存更多的数据，将更少的数据写入磁盘，甚至不写入磁盘，从而减少了磁盘IO。?
2. 对于shuffle操作，在reduce端会需要内存来存放拉取的数据并进行聚合。如果内存不够，也会写入磁盘。如果给executor分配更多内存以后，就有更少的数据需要写入磁盘，甚至不需要写入磁盘，从而减少了磁盘IO，提升了性能。?
3. 对于task的执行，可能会创建很多对象。如果内存比较小，可能会频繁导致JVM堆内存满了，然后频繁GC（垃圾回收，包括minor GC和full GC），频繁垃圾回收速度会很慢。内存加大以后，带来更少的GC，避免了速度变慢，从而速度变快了。