spark调优经验(待续)

spark调优是须要依据业务须要调整的,并非说某个设置是一成不变的,就比方机器学习一样,是在不断的调试中找出当前业务下更优的调优配置。以下零碎的总结了一些我的调优笔记。

spark 存储的时候存在严重的分配不均的现象,有几台机器在过渡使用, 有几台机器却非常少被使用。有几台机器缓存了几十个上百个RDD blocks  有的机器一个RDD blocks 都没有。这样存储有RDD blocks 的能够进行运算。运算的tasks 最多为该机器core数。

spark.storage.memoryFraction 分配给用于缓存RDD的内存的比例

比方假设spark.executor.memory              30g  spark.storage.memoryFraction       0.5          则用于缓存的内存为14G 多。 默认留一些做其它用。

每个RDD blocks  的大小不一定是64兆 可能小于64兆,另外假设driver不是子节点,driver 程序执行的节点上的用于缓存的内存 ,就不会被使用。

其实一个两三G 的数据 须要用的缓存也至少须要两三G。假设中间过程中还有产生RDD 且也须要缓存到内存。则须要分配很多其它的内存用于缓存。

在缓存足够多的情况的

很多其它的内存不足错误提示(OOM) 来源于计算的时候产生的一些中间对象即计算所须要的内存。

所以分配用于缓存的内存 应该是这么算的。 比方我有10G的文件,4台机器。则每台机器至少2.5g缓存,假设每台机器分配给excutor 的内存为10g ,则memoryFraction 则至少为0.25  最好配大一些。但不能太大, 太大会导致计算内存不够。

并且假设中间过程还有产生新的RDD。则须要依据实际情况调大memoryFraction。

RDD 缓存分布不均匀 是影响spark 的非常大的性能之中的一个。为什么这么说?

由于有的机器分配给用于RDD 缓存的内存都用完了  ,这样相对而言在这个机器上计算的开销也会大,有的机器缓存占用的内存非常少。就算用这个机器来计算,还须要启动Node_local 模式。这样会影响计算的时间。

调优过程也遇到了一些问题,还没解决,比方:

为什么一个2G 的数据。默认块大小为64M. default.parallelism 设置成100,可它总是不按这个数据来分,比方常常分成了108个blocks,影响partions个数的參数还有哪些?还有我明明有四个节点,但常常有节点被分配的RDD 和计算都非常少非常少,这样的资源浪费的情况应该怎么调解?

时间: 2024-10-21 05:15:06

spark调优经验(待续)的相关文章

spark 调优经验(续二)

FAQ 1.      spark性能配置 我目前的环境是5台机器,每台机器8个核.如果有以下两种配置方案: (a) SPARK_WORKER_INSTANCES = 8 SPARK_WORKER_CORES = 1 (b) SPARK_WORKER_INSTANCES = 1 SPARK_WORKER_CORES = 8 如何处理? 答: a方案每个节点会启动8个worker运行8个JVM,每个worker将会启动一个excutors, b方案将会启动一个worker运行一个JVM.如果数据很

JVM调优经验分享

前言 一.JVM调优知识背景简介 二.JVM调优参数简介 三.JVM调优目标 四.JVM调优经验 结束语 <br/> 本次分享探讨的JVM调优是指server端运行的JVM调优,适应版本为[1.6– 1.7], 不涉及最新的1.8版本. 假设线程池.连接池.程序代码等都已经做过优化,效果(系统吞吐量.响应性能)仍然不理想,我们就可以考虑JVM调优了. <br/> 一. JVM调优知识背景简介 1.堆与栈的概念 堆和栈是程序运行的关键:栈是运行时的单位,而堆是存储的单位. 栈解决程序

GC浅析之三-性能调优经验总结

性能调优经验总结 问题的出现: 在日常环境下,以某server 为例,该机器的每秒的访问量均值在368左右,最大访问量在913.对外提供服务的表现为每两三个小时就有秒级别的时间客户端请求超时,在访问量增大的情况下用户请求超时频率明显增多. 现象的直接分析: 通过监控GC发现该现象,GC中比较频繁的出现promotion failed和concurrent mode failure.由于promotion failed产生的直接原因为在发送YGC时,old区因为碎片.可用空间不够,造成无法晋升对象

【Spark学习】Apache Spark调优

Spark调优 本文系根据官方文档翻译而来,转载请注明本文链接 http://www.oschina.net/translate/spark-tuning?print 数据序列化 内存优化 确定内存用量 调整数据结构 序列化RDD存储 垃圾收集调整 其他考虑因素 并行化水平 Reduce任务的内存用量 Broadcasting large variables 总结 因为大部分Spark程序都具有“内存计算”的天性,所以集群中的所有资源:CPU.网络带宽或者是内存都有可能成为Spark程序的瓶颈.

spark调优之开发调优

(1)避免重复的RDD 案例: val rdd1 = sc.textFile("hdfs://zzy/hello.txt") rdd1.map(...) val rdd2 = sc.textFile("hdfs://zzy/hello.txt") rdd2.reduce(...) 这里条用了两次textFile,并且读取的是同一个文件,造成了多次的磁盘读取,如果是hi同一个文件,读取一次即可. (2)尽可能多的复用一个RDD 错误演示: //由于业务需要,对rdd1

【Spark调优】小表join大表数据倾斜解决方案

[使用场景] 对RDD使用join类操作,或者是在Spark SQL中使用join语句时,而且join操作中的一个RDD或表的数据量比较小(例如几百MB或者1~2GB),比较适用此方案.. [解决方案] 小表join大表转为小表broadcast+map大表实现.具体为: 普通的join是会shuffle的,而一旦shuffle,就相当于会将相同key的数据拉取到一个shuffle read task中再进行join,此时就是reduce join,此时如果发生数据倾斜,影响处理性能,而此时恰好

【Spark调优】大表join大表,少数key导致数据倾斜解决方案

[使用场景] 两个RDD进行join的时候,如果数据量都比较大,那么此时可以sample看下两个RDD中的key分布情况.如果出现数据倾斜,是因为其中某一个RDD中的少数几个key的数据量过大,而另一个RDD中的所有key都分布比较均匀,此时可以考虑采用本解决方案. [解决方案] 对有数据倾斜那个RDD,使用sample算子采样出一份样本,统计下每个key的数量,看看导致数据倾斜数据量最大的是哪几个key. 然后将这几个key对应的数据从原来的RDD中拆分出来,形成一个单独的RDD,并给每个ke

MySQL数据库调优经验

?RDS for MySQL 由亚洲唯一WebScaleSQL团队维护内核源码,结合阿里巴巴多年MySQL数据库调优经验,从数据库源码层及数据库参数进行了性能优化,在相近规格配置下,RDS for MySQL性能值能达到自建数据库性能的3倍以上. RDS for MySQL针对通用的场景,在内核做了一系列的优化: 1. 改进了InnoDB redo组提交功能,多线程并发写入的情况下能有10%以上的速度提升. 2. 优化锁,对一些会引起串行化的大锁进行了拆分,能够有效避免长时间的读锁等待,提升数据

大数据-spark理论(3)sparkSql,sparkStreaming,spark调优

导读目录 第一节:sparksql 1:简介 2:核心 3:与hive整合 4:dataFrame 5:函数 第二节:spark Streaming 1:对比strom 2:DStream的算子 3:代码 4:driver HA 5:读取数据 第三节:spark调优 第一节:sparksql (1)简介: Shark:shark是sparksql的前身,hive是shark的前身 快的原因:不仅是内存,还有谓词下移(减少一定量的数据IO) 正常 谓词下移 (先关联表在切割) (先将表中的字段过滤