22|Spark UI(下):如何高效地定位性能问题?
- 深入了解
- 翻译
- 解释
- 总结
Spark UI的二级入口提供了丰富的信息,帮助开发者快速定位性能问题。通过对SQL、Jobs和Stages的详细页面进行解读,读者可以掌握性能问题的定位方法,为调优提供更多的洞察与思路。在SQL详情页,作者通过具体作业的执行计划展示了Exchange、Sort和Aggregate操作的度量指标,并结合实例进行了调优分析。在Jobs详情页,展示了隶属于当前Job的所有Stages,为读者提供了直观的执行细节。而在Stages详情页,包含了Stage DAG、Event Timeline与Task Metrics等信息,通过这些信息可以判断作业是否存在调度开销过大、或是Shuffle负载过重的问题,从而有针对性地对不同环节做调优。此外,通过Task Metrics提供的详尽的量化指标,读者可以轻松判定当前作业的不同任务之间的负载分布情况,进而改善作业性能。文章还提醒读者,应用是通过spark-shell提交的,因此节点8080端口的Spark UI会一直展示应用的“体检报告”,在退出spark-shell后,需要移步至节点的18080端口查看应用的“体检报告”。总的来说,通过本文的总结,读者可以快速了解Spark UI的二级入口,掌握性能问题的定位方法,为调优提供更多的洞察与思路。
《零基础入门 Spark》,新⼈⾸单¥59
全部留言(5)
- 最新
- 精选
- Geek_d4ccac老师好!有两个问题 1)括号里面的min,med,max是对什么取的极小,中数和极大。2)上一节设置了2 executor 每个3 GB memory, 为啥”peak memory total”会是18.8GB呢? 谢谢!
作者回复: 1)task level的统计值哈~ 2)3G和18.8G,是两个完全不同的概念哈,3G是开发者的设定值,每个Executors内存大小为3G;但是18.8G,是集群范围内,单位时间内存消耗的累计值,这里面有个时间的概念。简言之,3G的设置,是静态的,而18.8G的内存消耗,是一个动态的概念,英文里面把这个叫做memory footprint,它代表了单位时间任务对于内存的消耗与需求
2021-11-0441 - Geek_1e4b29一直对spill mem有点迷糊,假设有一份数据,按spark数据结构,在内存要100G,放磁盘要150G,如果executor是20G的话,忽略其他存储,spill memory以及spill disk大概是多少? 😂
作者回复: 这种情况下,spill memory好算,大概其就是80G左右,说白了就是内存数据结构放不下因而溢出的数据,在内存中的存储大小。spill disk不好算,这要看实际80G数据落盘到磁盘到底有多大~ 另外,老弟的假设反了哈,通常来说,磁盘上的(带压缩)数据,都比内存中(Java object)的小~
2021-10-3121 - 小新请问原始数据在内存中展开之后的总大小,这句话怎么理解?
作者回复: 就是如果把数据集在内存中存储、展开,所占用的内存总大小
2021-10-30 - kingcall我在把最后的结果show 出来的时候,为啥会提交两个job 呢? 下面是截图 https://kingcall.oss-cn-hangzhou.aliyuncs.com/blog/img/image-20211029160825553.png
作者回复: 老弟,不妨回想一下take的工作原理,为什么有两个show(甚至是多个show),自然就清楚啦~
2021-10-292 - Geek_3277ae您好,shuffle read time时间过长是什么原因呢?是computing time的10-20倍左右2023-08-01归属地:上海