为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【概述】部署一个TIBD集群使用Sysbench跑测试
【背景】 做过哪些操作
使用TiUP 部署了一个分布式集群，3 TiDB，3 TiKV，3 PD 和一个 Haproxy
部署节点：
每个机器都是 8c ，32G，400G SSD
10.3.72.101 ： 1 TiKV + 1TiDB + 1PD + 监控
10.3.72.103 ： 1 TiKV + 1TiDB + 1PD
10.3.72.104 ： 1 TiKV + 1TiDB + 1PD
10.3.72.112 ： Haproxy
【现象】
TIKV节点挂掉，测试性能显示异常
【问题】
- 每次Sysbench 跑脚本 prepare 时，在Create Index阶段总会有一个TiKV挂掉。
- 正常集群（无节点挂掉）在跑脚本 Prepare 时，耗时非常高（创建索引非常慢）。
- 测试的时候跑了四个脚本： point_select 和 read_only 正常，但是read_write 和 update_index 性能极差，如何进行调优？Dashboard显示存在热点问题，但应该不仅仅只是热点问题
- 当前的部署架构是否可行（一台机器上一套 TiKV + TiDB + PD）？可能会出现哪些问题？
【业务影响】
性能测试难以达标(read_write和update_index被OB吊锤了)
【TiDB 版本】
v5.0.0
【应用软件及版本】
tiup: 1.5.0
【附件】 相关日志及配置信息
tiup cluster display tidb-test(当前已经挂掉了一个节点)
挂掉节点的日志：
tikv.log (1.3 MB)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
qizheng
(qizheng)
2
- TiKV 日志最近一次重启 2021/06/09 22:16:14.981 应该是遇到了 panic，之后由于存在 panic_mark_file 导致这个 tikv 不断重启，可以传一下 tikv_stderr.log 看看有没有报错
- prepare 往表里导入数据，可能存在 tikv 写热点导致负载不均衡
- read_write 和 update_index 对 tidb 内存有一定要求，同时 tikv 也会有缓存，可能资源比较紧张，具体需要分析下监控，可以参考故障诊断相关文档，需要先解决热点问题
- 目前部署架构不太合理，tidb，tikv 和 pd leader 存在资源的争用，单个组件的性能瓶颈会影响整个集群，按照 tidb 分布式架构，需要为 tidb 和 pd 单独分配机器部署，可以参考官网推荐的配置要求
read_write和update_index被OB吊锤了
可以分享下实测数据对比吗，OB 是不是也是同样的机器配置和架构
下午缩扩容尝试恢复挂掉节点，节点恢复失败，但每次重新部署集群该节点又可以正常运行。
tikv_stderr.log:
tikv_stderr.log (23.3 KB)
研究了下ob的部署架构，现在我部署的ob集群也是三台同样机器：
10.3.72.101： observer zone1
10.3.72.103： observer zone2
10.3.72.104： observer zone3
10.3.72.112： obproxy
考虑到两个集群对比测试的硬件环境和部署架构，TiDB集群采用了上述的部署结构（所以有点不太合理），两个集群是分别测试的，所以相互不会影响。
目前测试了的 point_select 性能是差不多的，在预估之内，但是在update_index和read_write上相差一个位数，OB保持1W多，TiDB只有1Q左右，所以感觉TiDB存在问题较大，平时不会是这个水平，考虑可能和部署结构有关，但是想做对比，要保持相同硬件条件，所以还在思考更好的TiDB部署架构。
qizheng
(qizheng)
4
从错误日志没有发现有用的报错信息，无法确定导致 panic 的原因，可以先把 panic 文件删掉再尝试重启。
point select 比较轻量执行路径也最短，性能相对较好，如果部署多个单机版 tidb (store=mocktikv) 测试性能应该还有提升；但是对于其他类型的 DML 或走 coprocessor 的 Query，单个 Query 消耗的 CPU 成本相比 OB 更高，除去热点原因，相同配置下 TiDB 会更早达到性能瓶颈，并且由于 golang 自身 runtime 和 gc 的一些开销，加上 tikv io 模型没有单独分离出来，所以整体的 cpu user 负载无法跑满。
由于单 Query 高 CPU 成本，目前要达到 OB 的测试性能指标，TiDB 还需要增加更多机器，降低成本包括磁盘的使用，也是产品以后持续优化的方向。
如果我再去增加TiDB的机器，做对比测试明显对于OB来说肯定是不公平的。
所以我主要还是想在TiDB上进行调优，但是目前这个性能差这么多，我认为是不正常的，感觉在某些地方存在一些不合理的问题，所以还在调试的过程中。
