如果遇到sql性能问题,可以先查看4040页面的sql执行信息。一个sql解析为多个stage,一个stage分为多个task。
对问题Sql的某一个stage,基本的分析思路如下:
所有的task都慢,检查下是否有笛卡尔积(关联字段重复值、关联字段是否有null值、关联过程中出现重复值等)、分桶数是否太少。
只有几个task很慢(大部分task都已经执行完成),检查下是否倾斜问题:存储倾斜(分桶不均匀等)、计算倾斜(关联条件中有null、重复值、关联码表)。
如果分发到某个节点上的task都慢,到该task所在的服务器,检查cpu、io、内存、硬盘的性能。
task数太多(几千到上万)而且每个task用时较少,检查表的小文件是否太多。
task数太少(几十个以内甚至只有几个)而且每个task时间很长,检查表的分桶数是否太少。
所有的task执行之间都比较平均,每个task的执行时间也挺快,但是sql总的执行时间很长。检查同时处于running状态的task个数,确认资源配置是否太低。
如果是insert ... select ...,检查源表是否有数据倾斜。
如果整个Inceptor突然变慢,检查慢的task是否在同一个节点,如果是,重点检查该节点的硬件是否正常或出现损坏,如果不是,检查交换机、网络以及集群的active角色是否出现过切换。
查看执行计划,检查是否有谓词下推失败等情况。
jstack Inceptor_server_pid,搜索 BLOCKED、waiting for 关键字。