为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】v4.0.9
【问题描述】我的PD所在机器是80核的，CPU利用率能到70%多，突然升上去的；
其他情况：
目前集群的tikv存储85%以上了，还没准备扩容。这个怎么排查
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
1.请问下当前集群的拓扑结构是什么样的，可以通过 tiup cluster display {cluster-name} 反馈下；
2.在 PD 所在的服务器上看下消耗 CPU 最高的进程是哪个？确认下是否为 PD 进程，若是的话麻烦看下这个 pd 节点是否上面有 dashboard ，检查下是否使用了日志搜索功能导致的；
3.目前 tikv 节点剩余空间有多少 G，如果剩余空间不多的话可以考虑扩容下。
1.pd和tidb-server混合部署，3个tidb_sever+3个pd，还有7个tikv实例
2.确定是pd-server，没有dashboard;我尝试过驱离pd-server的leader到其他节点，另一个节点的cpu立马也飙高
3.2T的盘，用了85%了
集群的拓扑麻烦先截图发一下，另外看下 PD Leader 的日志里有无什么报错信息
麻烦提供下 pd leader 的日志，并参考 https://metricstool.pingcap.com/#backup-with-dev-tools 导出下 overview/tidb/pd/tikv-details 的监控数据
zftidb-Overview_2021-03-11T01_53_11.093Z.json (71.5 KB)
zftidb-PD_2021-03-11T01_53_46.236Z.json (152.5 KB)
zftidb-TiDB_2021-03-11T01_54_14.840Z.json (623.2 KB)
zftidb-TiKV-Details_2021-03-11T01_55_03.207Z.json (1.1 MB)
pd leader日志：链接: 百度网盘-链接不存在 提取码: e86q
上面的监控页面没有数据，麻烦等每个 Grafana 监控页面加载出来后再重新导出下。
从 pd leader 日志中看有大量的 region balance 调度，从 04:39~10:02 一共调度了 7w 多次，这个调度频率非常高了，另外之前提到 tikv 存储超过 85% ，已经高于 pd 调度参数 low_space_ratio 的默认值，这个可能会触发 pd 的调度任务：
如果可以扩容的话建议先扩容下，短时间不能扩容的话可以尝试调高下参数 low_space_ratio 值，然后再观察下 PD CPU 有无下降。
你好，设置成0.9了，并没有效果。
1.现在所有 tikv 节点的存储空间使用了多少？pd leader 日志里还是在一直打印 [INFO] [operator_controller.go:424] ["add operator"] 这类信息吗？
2.麻烦按照上面说的方法重新导出一下overview/tidb/pd/tikv-details 的监控数据 ，注意等页面数据加载出来后再导出。
1.tikv存储降到了84%；我这边在扩容一个节点（2T的盘），但是还在进行中，总数据量在50T，所以tikv下降会很慢；还是在打印这个信息 :add operator + send scheduler command 这类
2.我这边的环境读这个快照会很慢，我弄了个，但是可能还不是十分全，如果缺少关键的再麻烦告知下；
2021-03-11 14_08_36.zip (3.1 MB)
方便提供一下在 pd cpu 升高的前后时间段的监控和日志信息吗？另外在那个时间段内对集群有做过什么相关的操作以及前端业务有无做过什么调整。
发生在2月24日 10点～11点之间，之前利用率都在20%一下，我们主机配置有80核，目前cpu利用率到了60%了；
日志：链接: https://pan.baidu.com/s/1DXCUIdZ9I3DNa3INivSYPg 提取码: 4jgn
监控Overview=>PD = > handle requests duration seconds从24号10点，1ms以下上升到200ms左右了，现在也维持在这个数值
需要按文档建议的，进行pprof 抓取 PD 的 CPU profile 进行分析吗？
可以先抓取下，当时的监控数据估计不再了吧，现在单纯看 pd 2 月 24 号日志并没有发现 10 点~11 点 和 10 点前的内容有啥区别。
上面抓取的不是 pd 的 CPU ，试下：curl http://{pd_server_ip}:{pd_client_port}/debug/pprof/profile?seconds=60 > profile
从火焰图中看，PD 耗时最高的是 GRPC 下的 GetRegion 类请求，麻烦看下集群中是否有大量慢 SQL ,如果有的话可以先优化下；另外由于监控数据不全，不确定是否和现在的 tikv 存储空间不足 pd 大量调度也有关联，如果条件允许的话建议尽快扩容下磁盘空间。
好的，谢谢；
系统是有不少慢SQL;我们集群总容量是50T，现在已经85%左右了；
但是系统在夜间读写操作很低，但是cpu也不见下去，是否是tikv存储空间不足和pd调度的概率大一些了。