一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题
【TiDB 使用环境】生产环境
【TiDB 版本】6
【部署方式】云上部署（什么云）/机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
优先通过dashboard查看集群的cpu、内存、磁盘使用情况，另外，还可以通过grafana看下更多详细信息
看监控cpu超过60%可能就不够用了
tidb节点主要是cpu和内存，tikv节点磁盘空间超过80%就要考虑了
看监控资源使用情况，业务反馈页面有没有卡顿等
内存有要求吗?
磁盘空间80是不是会卡住?
主要还是观察主机层面的cpu使用率，和磁盘io使用率，网络容量去判断。
通过cpu使用率，磁盘io使用率去判断
判断 TiDB 资源瓶颈的核心是 “按组件拆分指标 + 结合监控与实操命令 + 参考业务反馈”
网络容量应该多少合适?
会有一定影响，但是还可以运行。
必须万兆太宽才能体验完整服务 
基本原理跟mysql 或者其他服务是一样的。cpu 内存，磁盘io，网络io这些
先看慢sql,再看性能视图,逐个节点排查
这个没有一个固定值，正常负载下，每个节点的网络流量是客户端到TiDB server 到TiKV，两两之间的数据交互。但是如果存在很多的写入或者节点异常集群内部数据均衡就容易导致网络流量过大。所以网络的流量正常的情况是变化比较平缓，且不超过网卡限制就好了。数据库存储场景下，网卡不太容易成为瓶颈。
看CPU 使用率、内存使用率和连接数
看服务器总内存就行，用到70%就肯定不太够了
资源指标像CPU 、内存 、 磁盘 、 网络是否持续处于高水位，如 CPU > 80% 且持续 5 分钟以上
业务指标比如QPS、TPS、 延迟 、 错误率是否出现异常，比如延迟飙升、QPS 不升反降、超时错误增加等