故事背景

在我上班悠哉悠哉的写代码的时候，忽然看到了一则报警信息，图如下。

内心一慌，这不是我们生产环境的数据库么？出问题这不得跟公司同归于尽，CPU 直接飙升到 98% 以上，内心疯狂骂娘，肯定又是哪个不知名用户疯狂查询大量数据导致的狂飙。出问题的是机器 06，我就去后台看了一下机器的 CPU 和 IO 情况。

狂奔的CPU

我们看了报警的 06 机器，他的 CPU 和 READ 都非常的高，我们可以看到CPU基本98左右，read 的 rate 大概是 200-300MB/s

那么其实就需要从机器里面去找出哪些查询是罪魁祸首。接下来我们就可以去机器里面看一下对应的日志信息，可以有效帮助我们快速定位到出问题的表。

寻找候选人

首先，我们需要进入到机器上对应的 pinot server 节点里面，登入之后可以去到 logs 目录，情况如下

这个目录下面储存的是 pinot 的日志信息，查询从哪来的，requestID 是什么都会存储在 xx.log 这个文件当中。接下来我们需要查看表的统计信息，可以知道某个时间段有哪些 table 被查询了，命令如下

cat pinotServer-11-* | grep schedulerWait | awk -F, '{if (length($4)>13) print $2}' | sort | uniq -c | sort -nr

这个命令的效果如下，可以明显看到哪些表正在被查询，然后就可以拿到这些候选人信息去看看他们的扫描数据的情况

寻找证据

上图只是举例子罢了，其实当时是另外一个表导致的问题，我们按照 pinot 官方文档搭建好了监控看板，直接去 Server 相关的卡片侧去查是谁导致的问题。

从这个图里面就可以看出来他跟 CPU 和 IO 的走势非常相近，就是因为这个大表的查询方式影响到了整个 06 机器上的查询。

解决方案

• 这个表主要是统计PV，UV，大数据量大明细查询去算 PV，UV 会导致全表扫描，所以需要优化对应的表存储结构
• 调整上层的超时任务，有问题就 kill 掉大查询的 SQL
• 调整计算方式，Pinot 新版本优化了很多 Distinct 的计算方式

总结

自此可以有一个还算粗糙的方案找到对应的问题数据，其实笔者也考虑到有个不错的方案优化成自动化的方式去找到对应的问题表，看这种问题的频繁程度在决定要不要去做对应的自动化工具。