tikv 的 cpu 性能瓶颈

【 TiDB 使用环境】生产环境
问题描述: 业务高峰期写入qps 在6k 左右,但是tikv cpu 偏高,sql 耗时偏高(机器资源足够)
TOP-SQL 以及部分监控情况:



tikv-detail 监控面板



tikv 相关配置

tikv:
    gc.enable-compaction-filter: true
    raftstore.capacity: 1536G
    readpool.coprocessor.use-unified-pool: true
    readpool.storage.use-unified-pool: true
    readpool.unified.max-thread-count: 24
    storage.block-cache.capacity: 48G
    storage.scheduler-worker-pool-size: 8 

表结构信息

CREATE TABLE `tblRealtimeSidAIGCDetail` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键自增',
  `sid` varchar(100) NOT NULL DEFAULT '0' COMMENT '检索id',
  `query` text DEFAULT NULL COMMENT '题目文本',
  `subquestioninfo` text DEFAULT NULL COMMENT '拆小题信息',
  `batch` bigint(40) NOT NULL DEFAULT '0' COMMENT '生产批次',
  `qid` varchar(40) NOT NULL DEFAULT '0' COMMENT '投放产生的id,无则为0',
  `source` varchar(20) NOT NULL DEFAULT '0' COMMENT '来源:1-单题拍,2-整页拍',
  `course` bigint(10) NOT NULL DEFAULT '0' COMMENT '学科',
  `grade` bigint(10) NOT NULL DEFAULT '0' COMMENT '年级 1,20,30:小初高',
  `questiontype` bigint(10) NOT NULL DEFAULT '0' COMMENT '题型',
  `weight` bigint(10) NOT NULL DEFAULT '0' COMMENT '热度值',
  `pval` decimal(10,2) NOT NULL DEFAULT '0' COMMENT '满意度',
  `gentime` bigint(40) NOT NULL DEFAULT '0' COMMENT '投放时间',
  `genway` bigint(10) NOT NULL DEFAULT '0' COMMENT '产生方式 1-实时,2-小时,2-天',
  `status` bigint(10) NOT NULL DEFAULT '0' COMMENT '所处状态',
  `createtime` bigint(40) NOT NULL DEFAULT '0' COMMENT '入库时间',
  `updatetime` bigint(40) NOT NULL DEFAULT '0' COMMENT '状态更新时间',
  `top_pid` varchar(100) NOT NULL COMMENT 'sid图片pid',
  `tid` varchar(255) NOT NULL DEFAULT '0' COMMENT '上线后tid',
  `ori_tid` varchar(20) NOT NULL DEFAULT '0' COMMENT '拍搜现场首位tid',
  `version` varchar(100) NOT NULL DEFAULT '0' COMMENT '模型版本',
  `deleted` tinyint(4) NOT NULL DEFAULT '0' COMMENT '1:软删',
  `ext` text DEFAULT NULL COMMENT '保留扩展字段',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入库时间,用于自动删除的时间格式',
  PRIMARY KEY (`id`) /*T![clustered_index] NONCLUSTERED */,
  UNIQUE KEY `sid` (`sid`),
  KEY `tid` (`tid`),
  KEY `questiontype` (`questiontype`),
  KEY `pull` (`batch`,`course`,`status`),
  KEY `idx_createtime_status` (`createtime`,`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=56243485550 /*T! SHARD_ROW_ID_BITS=4 */ COMMENT='';

screencapture-172-29-238-86-8085-d-eDbRZpnWa-tidb-superstrategy-aigc-performance-overview-2024-04-29-11_56_33.pdf (5.0 MB)

楼主看看Dashboard的热力图情况呢,贴下集群访问的热力情况。

prewrite 是2PC的提交阶段,这个阶段主要是在做MVCC的多版本检查、以及是锁冲突检测,说明这个事情花了较多的时间。

从热力图看着是有比较集中的写情况。

可以到 Grafana的 TiDB 面板,查看下 KV Error 和 DistSQL 面板的情况,检查锁冲突或者backoff是否较多。

1 个赞


看着也还好,会是跟这个sid 是唯一键有关系吗 ?导致写入的时候耗资源

从 Lock Resolve OPS这里可以确认执行任务时遇到的锁比较多,导致内部 backoff 重试次数多,这个过程会相比较耗资源,业务侧也会感知到SQL变慢的。

现在集中看看为啥要锁这么久,是读取数据的过程比较慢,还是要检查的MVCC版本比较多。

楼主重点搜索和排查下tikv面板 和 tikv的日志情况,。

https://docs.pingcap.com/zh/tidb/stable/grafana-tikv-dashboard

grafana里面找Compaction pending bytes

重点关注这个值掉下去的时候,也就是发生compaction的时候,是否和你的insert的prewrite时间超长的时候对的上。

我的经验是,一般偶尔的insert 慢查询,这种prewrite时间超长的时候都是tikv在compaction。

还有就是关注这个图里面明显亮斜线的部分是否是索引。局部的亮斜线看上去比较多。

https://docs.pingcap.com/zh/tidb/stable/dashboard-key-visualizer#明亮斜线需要关注业务模式

如果是索引写热点,现在确实没啥好办法。
如果不是索引而是表,那这个亮斜线对应的表是非常明确的写热点。需要你用SHARD_ROW_ID_BITS改造一下的。就像你对tblRealtimeSidAIGCDetail这个表做的那样。