通过慢查询发现，集群每隔大概30分钟，就会出现集中commit;，每次1.7万个 这种指令，导致整个集群出现短暂响应时间慢，这种是程序引起的还是tidb内部某个部分压力过大导致的？
这么规律，排查下有什么定时任务没，数据库的业务上的都查下
数据库这块是我安装的，安装后除了br备份，就没有啥定时任务了。
找到这个commit的txn，然后根据txn找一下sql,这个如何操作？
这么有规律，在有问题时间点刷刷数据库连接信息，看看能不能查到跑什么呢
select * from INFORMATION_SCHEMA.PROCESSLIST
where command<>‘Sleep’
从监控面板上看，是scheduler is busy，而且只有一个tikv节点有报这个busy，多半是热点写入导致的，可以分析下写入热点问题
写入热点数据，通过grafana的哪些监控可以判断出来？
你的应用程序有没有批量操作，比如批量插入或者导入的情况，然后程序中一次提交几百条数据这样的情况，排查下
开发说是没有，都是用户一条一条请求过来。不过不太相信开发的话，还是得找出证据来说明。
可以按专栏中的文章排查
有规律性的，基本都是定时任务执行，看看数据本身，或是应用
流量可视化里也看一下又没有热点表
可以写个脚本把当时的连接都打印出来
检查下是不是有定时任务
好像是跟analyze统计信息有关。每次出现都是伴随着analyzte统计语句的出现
我觉得analyze应该不会有那么多commit吧，应该是你commit多了，对应的表提交的多了，触发了自动analyze（可以先看下是不是自动收集信息的时间段之内），建议看下对应analyze的表在那个时间点是不是有很多增删改的语句。
经过测试，由于表的分区有1024个，后台一直在analyze，占用了大量资源，导致每隔一段时间就会出现server is busy，我现在的处理方法是把自动收集关闭，手动写脚本，凌晨指定时间收集统计信息。听官方说v7.5即将在未来两个出，对分区的统计收集有很好的支持。到时候升级一下集群版本再观察一下。
1 个赞
如何关闭的自动analyze 啊，我也想关闭
收到已经配置，谢谢