我们用的3.0.0版本的tidb集群，一共三台机器，每台机器上均部署了tidb、pd、tikv组件，刚开始的时候集群运行速度还比较快，但随着时间的推移，数据量越来越多后，tidb运行越来越慢比如创建数据表，delete操作或truncate操作等，很多时候集群负载很低，不知道是什么原因导致的，这个能不能优化一下
- 这些操作和您的数据量可能有关系，一开始数据量非常少，随着数据量增多，需要的时间增长。
- 能否反馈一个具体问题来查看？
1 个赞
之前我遇到类似问题，原因是很多delete/truncate导致空Region太多，merge空region就可以了
1 个赞
您好， 1：该段时间内是否是 ddl job 的累积？通过 admin show ddl jobs 可以看下累积任务。 2：该段时间内是否有 tidb 节点的下线操作？
可以确认下上述空 region 的情况。
你好，我们线上基本没有delete、truncate操作，所有业务都是软删除
没有ddl操作也没有下线节点
你好，你们tidb承担的什么业务
可以看下 PD 下的 empty regions 指标吗
数据仓库
这个指标怎么看
还是在监控面板里
这个问题解决了，原因是dm上的syncer线程开的太大了，默认开了48个线程，现在把线程调小（4个线程）后问题解决了，监控如下：
标号1:表示默认开启48线程时的tidb磁盘io情况
标号2:pause-task一段时间后在resume-task，情况略有好转
标号3:直接将dm线程降级为4个，磁盘io负载不在升高（标号3里的那个突刺应该是create table是tidb需要新建region导致的，随后突刺消失开始正常同步数据）
pd里的operator监控如下：
1 个赞
好的，就是磁盘 IO 高峰引起的 create table duration 高吧
我怀疑是这样的：
1、数据表的主键为数值型、且单调递增，也就是说id是连续的（这个很关键）
2、dm开启了大量的syncer线程（48个），这些线程在事务足够散的情况下会开启并发同步（有可能48个同时insert）
3、线上灌表操作或者pt改表操作，会在短时间内产生大量insert操作，而且这些insert操作没有并集数据，所以满足并发操作的前提
4、dm程序检测到这些insert操作可以并发执行，根据设置的syncer线程数开始同步数据
5、大量的insert操作同时往tidb里写入，id是连续的也就是说会写到同一个region里，该region所在的机器磁盘io响应变高（极端情况下会打满）
6、大量数据同时写入region自然就会造成热点，造成热点后pd开始产生调度（balance-leader）
