presto 调优

Presto 调优

0、presto 原理架构

https://www.cnblogs.com/tgzhu/p/6033373.html

1、Presto 存在的问题

1. Coordinator单点问题（常见方案：ip漂移、nginx代理动态获取等）

2. 大查询容易OOM（0.186+版本支持dump到磁盘 未验证）

3. 没有容错能力，无重试机制

4. Presto部署环境复杂，MPP架构容易受到单台机器影响

5. Presto并发能力不足

2、调优策略

1. 部署多台Coordinator避免单点问题，上层封装一层查询服务 避免jdbc直连

2. 如果有必要在查询服务进行重试操作（需要判断任务状态）

3. 对worker相关内存参数进行合理配置，避免OOM

4. 启用Presto本身资源队列的同时，构建符合业务场景的查询队列，控制并发量及查询优先级，确保任务高效完成

5. 开发Presto监控系统，监测Presto集群状态，及时预警。动态调整Presto集群规模

3、内存调优

Presto分为三类内存池，分别为GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL。

SYSTEM_POOL是系统预留内存，worker初始化和执行任务必要的内存，默认为Xmx0.4 也可由resources.reserved-system-memory指定

RESERVED_POOL是最大查询内存，Presto会将当前好用内存最大的query切到该内存区域，默认为Xmx0.1 由query.max-memory-per-node配置

GENERAL_POOL其他查询内存，即除最大查询外其他query的查询内存，大小为Xmx-SYSTEM_POOL-RESERVED_POOL

• query.max-memory:表示单个查询在分布在所有相关节点上能用的内存之和的最大值。

• query.max-memory-per-node：单个查询在单个节点上用户内存能用的最大值，从定义上就能看出：query.max-memory-per-node 必须小于query.max-total-memory-per-node

• 同样： query.max-memory 也必须小于query.max-total-memory

• 另外：query.max-total-memory-per-node 与memory.heap-headroom-per-node 之和必须小于 jvm max memory .也就是jvm.config 中配置的-Xmx

• 注意：memory.heap-headroom-per-node：JVM max memory * 0.3

整体内存配置受以下场景的影响：

1. 用户查询数据量、复杂性（决定该用多大的查询内存）

2. 用户查询的并发度（决定该用多大的jvm堆）

需要注意的是：单纯的增大RESERVED_POOL的值并不能解决Presto的查询问题，因为RESERVED_POOL大部分时间是不参与计算的，只有满足以下情景才会被使用，而且只能被一个Query所使用。

1. GENERAL_POOL有节点出现阻塞节点的情况，即内存不足

2. RESERVED_POOL没有被使用

所以三者需要配置合理的值，如果并发比较大需要SYSTEM_POOL保持默认或者稍微再大一点，RESERVED_POOL可以稍微增大到八分之一左右。

同时对于jvm OOM的问题，需要对Presto的jvm.config进行配置：

-XX:G1ReservePercent=15
-XX:InitiatingHeapOccupancyPercent=40
-XX:ConcGCThreads=8

4、参考

https://cloud.tencent.com/developer/article/1156796

https://www.jianshu.com/p/f2b7d1550884

https://www.cnblogs.com/jixin/p/11234861.html

https://prestodb.io/docs/current/admin/properties.html