TiDB 使用 Prometheus 和 Grafana 提供了非常详细的监控指标。在遇到各种性能或稳定性问题时,这些监控一般是问题的关键线索。但详尽的细节监控指标使用门槛较高,刚入门的 TiDB DBA 可能难以上手,例如:
-
如何快速了解当前集群最耗时的是哪类操作?
-
发现写入耗时很长,如何进一步定位原因,应该查看哪些监控项?
-
监控项这么多,它们之间的关系是什么?
TiDB 4.0.7 起提供了一个新功能,可以将数据库各个内部流程的耗时监控按父子关系绘制为关系图,帮助用户快速以另一种维度了解集群状态。
简介
监控关系图是在指定的时间范围内,将各个监控项按父子关系绘制的关系图。图中每个方框节点代表一个监控项,包含了以下信息:
-
监控项的名称
-
监控项的总耗时
-
监控项总耗时和查询总耗时的比例
父节点监控的总耗时 = 自己的耗时 + 孩子节点的耗时,所以有些节点还会显示自己的耗时和总耗时的比例。
例如下面监控节点表示:tidb_execute 监控项的总耗时为 19306.46 秒,占总查询耗时的 89.4%,其中本身的耗时是 9070.18 秒,占总查询耗时的 42%。将鼠标悬停在该方框上,可以看到监控项的注释说明,总次数,平均耗时,平均 P99 耗时等更多该监控的信息。
每个节点的大小和颜色深浅,与监控项自己的耗时占总查询耗时的比例成正比。一般在这个图中可以重点关注耗时较多的监控节点,然后顺着父子关系向下梳理。详细介绍请参考官方文档。话不多说,来看两个简单的示例吧。
示例 1
最近新上线一个业务后,原来的集群响应突然变慢了很多,小明看服务器 CPU 都挺空闲的呀,然后抓了一个监控关系图如下:
可以很快发现,上图中:
-
tidb_query.Update 表示 update 语句的执行耗时占总查询耗时的 99.59%。
-
tidb_execute 表示 TiDB 的执行引擎本身耗时占 68.69%
-
tidb_txn_cmd.commit 表示事务提交的耗时占总耗时的 30.66%
-
tidb_kv_backoff.txnLock 表示事务遇到锁冲突的 backoff 总耗时占 15%,这要比发送 prewrite 和 commit 的 tidb_kv_request 的耗时高很多。
到此,可以确定 update 语句存在严重的写冲突,可以按照 乐观事务模型下写写冲突问题排查 进一步排查冲突的表和 SQL 语句,然后和业务方沟通从业务上避免写冲突。
示例 2
最近需要导入一批数据到 TiDB 集群,导入速度有点慢,小明想看看系统现在慢在哪儿,然后看能不能优化下,他抓了一个导入数据时的监控耗时关系图如下:
上图中,最下面可以看到 tikv 的 raftstore 在处理 propose 前的等待耗时很长,说明 raftstore 存在瓶颈了,然后可以进一步查看 raftstore cpu,append/apply log 的延迟,如果 raftstore 的 thread cpu 使用率不高,则大概率是磁盘是磁盘的问题。具体可以按照 Performance TiKV Map 中 raftstore 相关模块和 TiDB 磁盘 I/O 过高的处理办法 进行排查,
除此之外,可以排查是否存在热点,可以按照 TiDB 热点问题处理 进一步排查是否有热点。
使用介绍
注:生成监控关系图时,会从 prometheus 中读取各项监控的数据。所以 TiDB 集群需要部署 prometheus ,推荐使用 tiup 部署集群。
登录 Dashboard 后点击左侧导航的集群诊断可以进入此功能页面:
设置区间起始时间和区间长度参数后,点击生成监控关系图按钮后,会进入监控关系图页面。
最后
本文介绍的监控关系图旨在帮助用户快速了解 TiDB 集群的负载情况和众多监控项之间的关系,后续计划集成 TiDB Performance Map,把和该项监控项相关的其他监控以及配置也关联上,进一步完善 TiDB 集群中各个组件监控项之间的关系。
如有任何疑问或者建议,欢迎在 AskTUG 下给我们留言~
目录