一般来说,优化一个系统的性能是——性能监控和参数调整的两个阶段,本文主要共享这两个方面。
性能监控工具
[火花监测工具]
Spark提供了一些基本的web监控页面,有助于日常监控。
1.应用程序web ui
http://master:4040(默认端口为4040,可以修改)可以获取此信息。(1)stages和tasks时间表(2)RDD大小和内存使用情况;(3)系统环境信息;(4)正在运行的executor信息。
2.history server
Spark应用程序结束后,您可以继续检查Spark应用程序的stages和tasks执行信息,从而使程序能够轻松分析原因未知的情况。配置方法如下:
(1)$SPARK_HOME/con
Exportspark _ history _ opts='-D
d=HDFS ://Hadoop 00033608020/directory '
说明:“仅显示最近50个应用程序:Spark History Server”页仅显示该路径下的信息。
(2)$SPARK_HOME/con
True
在HDFS ://Hadoop 000:8020/directory #应用运行期间,所有信息都将写入此属性中指定的路径
3.对了
(1)启动HistoryServer
$SPARK_HOMR/bin
(2)停止HistoryServer
$SPARK_HOMR/bin
4.甘格里亚
配置Ganglia可以分析群集使用情况和资源瓶颈,但ganglia默认情况下不打包,因此在编译mvn时需要添加-Pspark-ganglia-lgpl并修改配置文件$ SPARK _ HOME/
5.Executor logs
Standalone模式:$SPARK_HOME/logs
YARN模式:YARN日志配置在yarn-文件(yarn.nodemanager.log-dirs)中,或使用命令获取yarn logs -applicationId。
[其他监测工具]
1.Nmon()
Nmon输入:c: CPU n:网络m:内存d:磁盘
2.Jmeter(http://jmeter .a)。
通常使用Jmeter作为系统性能参数的实时演示。安装JMeter非常简单。可以从官方网站下载并解压缩后使用。对于执行命令%JMETER_HOME%/bin中的Windows用户,请直接使用jme。
启动Jmeter:生成测试计划并设置线程组设置周期数。
新增监听器:jp@gc-PerfMon Metrics Collector。
监听器设定值:接收主机连接埠和监听内容(例如CPU)。
开始接收:可以实时获取节点的CPU状态信息,图4显示CPU遇到瓶颈。
3.Jprofiler()
JProfiler是专为分析J2SE和J2EE应用程序而设计的全功能JProfiler。将CPU、线程和内存分析结合到强大的应用程序中。JProfiler的GUI可以轻松找到性能瓶颈、捕获内存泄漏以及解决多线程问题。例如,分析哪些对象使用更多内存。什么方法占用更大的CPU资源等?通常,使用Jprofiler监视在本地模式下运行的Spark应用程序的性能瓶颈和内存泄漏。
这些工具可以通过提供的链接直接查看详细的使用方法。
火花调谐
[火花集群并行度]
Spark丛集环境必须有足够的平行程度,才能充分利用系统资源。修正使您可以调整Executor的数量和使用资源。Standalone和YARN方式资源的日程安排是不同的。
:在Standalone模式下
1.每个节点使用的最大内存量:spark _ worker _ instances * spark _ worker _ memory;
2.每个节点的最大并发task数:spark _ worker _ instances * spark _ worker _ cores。
YARN模式:
1.丛集作业平行程度:spark _ executor _ instances * spark _ executor _ cores;
2.丛集记忆体总计:(executor数目)*(spark _ executor _ memory)(spark _ driver _ memory)。
Spark将堆内存大小添加到Executor和Driver中,并添加Executor端:设置,默认值executorMemory * 0.07和384的最大值。驱动程序端:由设置,默认值为driverMemory * 0.07和384的最大值。
调整上述参数将增加群集并行度,并允许系统同时执行更多任务,从而增加同一任务的并行度,从而减少轮询次数。例如:如果一个阶段有并行度为50的100T stage,则必须轮询两次才能执行此操作。如果并行度为100,则只需一次。
但是,在资源相同的情况下,并行度越高,相应的Executor内存就越少,因此必须根据实际情况调整内存和内核。Spark还可以对所有任务重复使用JVM,以减少任务启动消耗,从而能够非常有效地支持短时间的任务(例如200毫秒)。在Standalone模式下,核心可以超额分配比物理核心多1至2倍的容量。
[调整火花工作量]
Spark中的操作数是由从stage开始的所有RDD的partition总和决定的,因此必须知道如何计算每个RDD的partition。以Spark应用程序从HDFS读取数据为例,HadoopRDD的分区方法完全继承自MapReduce的FileInputFormat。具体的分区数取决于多种因素,包括HDFS的块大小、ma大小和文件压缩方法。有关详细信息,请参阅。
[调整火花内存]
内存优化有三个考虑因素:对象使用的内存、访问对象的消耗和垃圾收集开销。
1.优化对象占用的内存、数据结构
默认情况下,Spark使用Java序列化对象。Java对象的访问速度更快,但通常比内部属性数据占用的空间多2至5倍。spark主页(http://spark . adocs/latest/tuning . html # tuning-Java-structures),以减少内存使用量并减少Java序列化后的额外开销
(1)使用对象数组和原始类型数组,而不是Java或Scala集合类(collection class)。Fastutil库为原始数据类型提供了非常方便的集合类,并且与Java标准类库兼容。
(2)使用包含指针的嵌套数据结构,避免存储小对象。
(3)考虑使用数字ID或枚举类型,而不是字符串类型的主键。
(4)如果内存小于32GB,请设置JVM参数-xx3360 usecompressedoops,将8字节指针修改为4字节。同时,设置JVM参数-XX3360 Usecompressedstrings,以便在Java 7或更高版本中将每个ASCII字符编码为8位。
2.内存回收
(1)获取内存统计信息:在优化内存之前,必须知道群集的内存回收频率、内存回收时间等。可以在中设置spark _ Java _ opts="-verbose 3360 GC-xx 3360 printgcdetails "
(2)优化高速缓存大小:Spark默认情况下将60%的执行内存()用于RDD高速缓存。也就是说,在作业执行过程中,40%的内存可用于创建对象。如果任务执行速度减慢,JVM经常回收内存,或者内存空间不足,则降低缓存大小设置可以减少内存消耗并减小大小。
3.频繁的GC或OOM
在这种情况下,首先要确认是在驱动器端发生,还是在Executor端发生,然后单独处理。
驱动程序端:通常,太大的结果集将恢复到驱动程序端,因此必须增加驱动程序端的内存解决方案,或者进一步减少结果集的数量。
Executor端:
(1)使用外部数据作为输入的舞台:GC通常是在Map端执行map-Stage-combine时,由group过多引起的。解决方法可以通过增加分区数(即task数)来减少每个task要处理的数据,从而降低GC可能性。
(2)使用shuffle作为输入的Stage:GC出现在这些Stage中的常见原因也与shuffle相关。一般原因是一个或多个组中的数据太多。换句话说,所谓的数据倾斜最简单的方法是增加SparkSQL等shuffle的task数,如果增加Shuffle的task不能解决问题,那么可以看出你的数据倾斜很严重,一组数据比另一组大得多。要从业务逻辑上调整,为大集团提前单独处理。(约翰f肯尼迪)。
[修改序列化]
Kryo序列化结果使用Kryo序列化,因为它比Java标准序列化更小、更快。具体方法:中的org.apache.设置为KryoSerializer。
官方文件参考(http://spark . adocs/latest/tuning . html # summary):在大多数程序中使用Kryo框架和序列化可以解决大多数与性能相关的问题。
[调整火花盘]
如果群集环境中数据分布不均匀,导致节点之间的活动分布不均匀,以及节点之间源数据的不必要网络传输对系统性能产生了重大影响,则为了磁盘调整,建议首先均匀分配数据资源。它还可以在一定程度上处理源数据。
1.在内存允许的范围内,将经常访问的文件或数据放置在内存中。
2.如果有足够的磁盘,HDFS可以相应地增加源数据的备份数,从而减少网络传输。
3.Spark支持多种文件格式和压缩方法,根据不同的应用环境做出合理的选择。如果每次计算只需要其中一列,则可以使用列文件格式来减少磁盘I/O。常用的列为parquet和rcfile。如果文件太大,压缩原始文件将减少磁盘I/o(gzip、snappy、lzo等)。
[其他]
广播变量(broadcast)
需要从Task访问驱动程序端大数据时,可以使用SparkContext中的广播变量来减少每个任务的大小以及在群集中启动任务的成本。请参阅官方文章http://spark . adocs/latest/tuning . html # broadcasting-large-variables。
打开推测机制
推测机制后,如果群集中一个系统的task特别慢,则推测机制将任务分配给另一个系统,最后Spark选择最快的结果作为最终结果。
添加到:true
推测机制与以下参数有关:
1.interval 100:测试周期(毫秒);
2.quantile 0.75: task完成率时开始估计
3.multiplier 1.5:比其他时间慢几倍的时候开始推测。
摘要
Spark系统的性能调整是一个复杂的过程,需要对Spark和Hadoop有足够的知识。在业务应用程序平台(Spark)、存储(HDFS)、操作系统、硬件等多个方面,性能可能会受到重大影响。使用多种性能监控工具,您可以更好地了解系统性能,并根据上述经验进行调整。
作者简介:Tian Yi,Spark Contributor,北京Spark Meetup发起人,亚洲通信技术大数据平台部门研发经理,重点关注SparkSQL和Spark Streaming。
这篇文章选自程序员电子版2015年3月的A期,本期有更多文章请确认这里。请确认2000年创刊至今所有文章列表为程序员封面秀。欢迎来到程序员电子版(包括iPad、Android、IPAD版本)。
1.《关于csdn官网我想说Spark性能调优》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。
2.《关于csdn官网我想说Spark性能调优》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/keji/1953407.html