【 TiDB 使用环境】生产环境 or 测试环境 or POC
v.4.0.8 生产环境
【 TiDB 版本】
【遇到的问题】
tiflash 执行了一条大查询，导致tiflash节点重启了，重启后cpu使用率一直很高，居高不下
错误日志中发现一些WARNING 2022.08.04 17:30:52.218460 [ 884327 ] CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): LockException: region 466440, message:
目前不确定tiflash cpu高的原因？？
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
【附件】 相关日志及监控（https://metricstool.pingcap.com/)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
看下Tiflash节点的top里是那个进程占cpu多呢，
您好，可以看下 tiflash 是否持续有请求进来？可以看监控 Clinic-Cluster Coprocessor Request QPS 和 Handling Request Number。
看下哪些进程占用CPU高，进一步跟踪到SQL
是通过perf top -p 看内部哪些进程消耗cpu比较多么？
通过top看，tiflash进程%CPU指标最高3000%
目前能发现一些执行耗时的SQL
select report_time,sum(x1),sum(xx2)…（大约70个sum指标）
where report_time>= xxx and report_time<=xxx
group by report_time;
看了下时间范围，每次查一天，执行计划显示扫描的行数大约380w-400w
执行时间不太稳定，有4s左右能跑完的，也有需要100s才能跑完的
不太确定是否和它有关系
间隔一段时间，会有800-1000的请求，两个指标很对应
那么 cpu 升高应该是预期的了。执行时间差异大还要再查一下，可以看一下 tiflash grafana 监控和 日志是否有异常。
不过你这个 4.0.8 版本比较低了，可以考虑升级到 5.4 最新版本或者 6.1 最新版本。
request qps 到1000，是很高的值了么？ 日志内有一些warning WARNING 2022.08.04 17:30:52.218460 [ 884327 ] CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): LockException: region 466440, message:
每个 cop 查询一个 reigon，对于 AP 请求来说，request qps 到1000 确实挺高了。5.4 版本做了优化，会尽可能使用批量请求（super_batch 或者 mpp），显著提升查询效率。
这个 LockException 应该是符合预期的，它是在读的时候，遇到没有提交的事务就会报这个错误。这时候 TiFlash 会等待事务提交之后才能开始查询，确实是查询变慢的一个可能原因。你可以看看 TiFlash summary 监控的 Coprocessor / Error QPS 看看多不多
首先应该从os层介入，确定到具体进程之后才能breakdown呢
通过top看过，是tiflash占用比较高，你说的意思是tiflash子进程谁占用的cpu比较多么？
Error QPS 最高15个，正常都是1-2个，甚至没有，整体看很少
