Presto性能调优的五大技巧

 

Presto是一个分布式的查询引擎,本身并不存储数据,但是可以接入多种数据源,并且支持跨数据源的级联查询。

Presto的架构分为:

Coodinator:解析SQL语句,生成执行计划,分发执行任务给Worker节点执行。

Discovery Server:Worker节点启动后向Discovery Server服务注册,Coordinator从Discovery Server获得可以正常工作的Worker节点。

Worker:负责执行实际查询任务,访问底层存储系统。

存储:Presto的数据可以存储在HDFS/OBS,推荐热数据存储在HDFS,冷数据存储在OBS。

内存调优

内存管理原理

Presto有三种内存池,分别为GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL。

GENERAL_POOL:用于普通查询的physical operators。GENERAL_POOL值为 总内存(Xmx值)- 预留的(max-memory-per-node)- 系统的(0.4 * Xmx)。

SYSTEM_POOL:系统预留内存,用于读写buffer,worker初始化以及执行任务必要的内存。大小由config.properties里的resources.reserved-system-memory指定。默认值为JVM max memory * 0.4。

RESERVED_POOL:大部分时间里是不参与计算的,只有当同时满足如下情形下,才会被使用,然后从所有查询里获取占用内存最大的那个查询,然后将该查询放到 RESERVED_POOL 里执行,同时注意RESERVED_POOL只能用于一个Query。大小由config.properties里的query.max-memory-per-node指定,默认值为:JVM max memory * 0.1。

1、GENERAL_POOL有节点出现阻塞节点(block node)情况,即该node内存不

2、RESERVED_POOL没有被使用

  • query.max-memory:表示单个查询在分布在所有相关节点上能用的内存之和的最大值。
  • query.max-memory-per-node:表示单个查询在单个节点上用户内存能用的最大值。
  • query.max-total-memory-per-node:表示单个查询在单个节点上用户内存能用的最大值和系统内存量。其中系统内存是读取器、写入器和网络缓冲区等在执行期间使用的内存。
  • memory.heap-headroom-per-node:这个内存主要是第三方库的内存分配,无法被统计跟踪,默认值是-Xmx * 0.3

 

注意点:

1、query.max-memory-per-node小于query.max-total-memory-per-node。

2、query.max-total-memory-per-node 与memory.heap-headroom-per-node 之和必须小于 jvm max memory 也就是jvm.config 中配置的-Xmx。

Presto内存配置

内存调优参数

操作场景

 

Presto由于是完全基于内存的计算,经常出现OOM,需要调整内存。

修改参数

常见OOM报错

Query exceeded per-node total memory limit of xx

适当增加query.max-total-memory-per-node。

Query exceeded distributed user memory limit of xx

适当增加query.max-memory。

Could not communicate with the remote task. The node may have crashed or be under too much load

内存不够,导致节点crash,可以查看/var/log/message。

并行度

操作场景

调整线程数增大task的并发以提高效率。

修改参数

元数据缓存

操作场景

Presto支持Hive connector,元数据存储在Hive metastore中,调整元数据缓存的相关参数可以提高访问元数据的效率。

修改参数

Hash优化

操作场景

针对Hash场景的优化。

修改参数

优化OBS相关参数

操作场景

Presto支持on OBS,读写OBS过程中可以调整OBS客户端参数来提交读写效率。

修改参数

 

  • 2
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在进行Presto性能测试的过程中,出现了一些问题导致Kubernetes部署的Presto集群无法发挥出完全的性能,与物理机部署的Presto集群相比存在较大差距。这些问题主要包括节点分配不均等。为了解决这些问题,可以采取一些措施来优化性能。 传统方式部署Presto集群是以物理机的方式运行,而在Kubernetes上部署Presto集群是以容器的方式运行。尽管Kubernetes部署方式带来了很多优点,但容器方式和物理机方式的性能差异仍是未知的。因此,需要进行对比测试来评估两种不同部署方式的性能差异。 根据测试结果来看,在不同的查询分类中,Kubernetes部署的Presto集群的平均查询时间稍微短于物理机部署,两者的时间差基本保持在几秒之间。需要考虑到本次测试环境部署在云服务器上,不同时段使用云服务器会导致性能偏差,因此几秒钟的性能波动是可以接受的。排除了云服务器产生的波动后,可以得出结论,Kubernetes部署与物理机部署的Presto集群在性能和效率上几乎没有差别。所以对于不同类型的查询,Kubernetes部署的Presto集群与物理机部署相比,在查询速度上几乎没有性能损耗,性能和效率几乎没有损失。 综上所述,通过对比测试可以得出结论,Presto在Kubernetes环境下的性能表现良好,并且与传统的物理机部署方式相比几乎没有性能损耗。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [技术分享 | Presto性能对比测试:Kubernetes部署 VS 物理机部署](https://blog.csdn.net/Alluxio/article/details/127260337)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值