0、presto 原理架構
https://www.cnblogs.com/tgzhu/p/6033373.html
1、Presto 存在的問題
-
Coordinator單點問題（常見方案：ip漂移、nginx代理動態獲取等）
-
大查詢容易OOM（0.186+版本支持dump到磁盤 未驗證）
-
沒有容錯能力，無重試機制
-
Presto部署環境復雜，MPP架構容易受到單台機器影響
-
Presto並發能力不足
2、調優策略
-
部署多台Coordinator避免單點問題，上層封裝一層查詢服務 避免jdbc直連
-
如果有必要在查詢服務進行重試操作（需要判斷任務狀態）
-
對worker相關內存參數進行合理配置，避免OOM
-
啟用Presto本身資源隊列的同時，構建符合業務場景的查詢隊列，控制並發量及查詢優先級，確保任務高效完成
-
開發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堆）
需要注意的是：單純的增大RESERVED_POOL的值並不能解決Presto的查詢問題，因為RESERVED_POOL大部分時間是不參與計算的，只有滿足以下情景才會被使用，而且只能被一個Query所使用。
-
GENERAL_POOL有節點出現阻塞節點的情況，即內存不足
-
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