本文作者:Jamie,观远数据in-house Spark之父,ABI领域史诗级工程师。
年初我们接到了一个客户反馈,表示服务器 cpu 占用异常,于是我们远程连接到服务器上面排查,发现是 Spark driver 占用了大部分 cpu。对于 cpu 占用问题,用 jstack 能很快定位到 jvm 的执行逻辑。分析 jstack 结果发现,大部分占用 cpu 的线程都在执行一个叫做 transpose window 的优化规则,而且都和这个逻辑里的一段方法有关:
private def compatiblePartitions(ps1 : Seq[Expression], ps2: Seq[Expression]): Boolean = {
ps1.length < ps2.length && ps2.take(ps1.length).permutations.exists(
ps1.zip(_).forall {
case (l, r) => l.semanticEquals(r)
})
}
这段逻辑看上去并不复杂,注意到这个方法里有一个 permutations
函数调用,这个函数会返回一个数组的所有排列。对于一个有 n 个不同元素的数组,他的排列数是 n!,也就是说这个算法时间复杂度会到 O(n!),那么我们遇到的问题很有可能和这个有关系了。但是我们还是需要找到是什么 sql 语句触发了这个问题。
从监控上来看,driver 的 cpu 是呈阶梯状上升的,那这些上升的时间点应该就是有问题任务提交的时间点,再结合 call stack 里面的逻辑是在做 window 相关的优化,我们重点去找这些时间点包含 window function 相关的