在渊49
1
为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】 场景 + 问题概述
使用sysbench进行压测，数据写不进去，查询也很慢。
【背景】 做过哪些操作
使用sysbench进行压测。
【现象】 业务和数据库现象
1万条数据的情况下，可以写入数据，TPS只有75，
2万条数据的情况下，可以写入数据，TPS只有65，
2000万条数据的情况下，可以写入数据，但是TPS只有124。
4000万条数据的情况下，无法写入数据。
【问题】 当前遇到的问题
读写性能过差
【业务影响】
正在技术选型
【TiDB 版本】
【应用软件及版本】
sysbench
【附件】 相关日志及配置信息
诊断报告链接：
http://124.70.29.116:2379/dashboard/api/diagnose/reports/1c983885-f978-41e0-a650-13a1ffc8db66/detail
监控概览链接：
http://124.70.29.116:2379/dashboard/#/overview
- TiUP Cluster Display 信息
- TiUP CLuster Edit config 信息
监控（https://metricstool.pingcap.com/)
- TiDB-Overview Grafana监控
- TiDB Grafana 监控
- TiKV Grafana 监控
- PD Grafana 监控
- 对应模块日志（包含问题前后 1 小时日志）
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
2 个赞
h5n1
(H5n1)
2
以下文档可以参考下
https://asktug.com/t/topic/183732/2
2 个赞
在渊49
4
测试的资源是：
PD三台机器，每台都是32C、64G内存，100G+1000G硬盘
TiDB两台机器，每台都是32C、64G内存，100G+1000G硬盘
TiKV五台机器，每台都是32C、64G内存，100G+1000G硬盘
TiDB版本是5.2
2 个赞
在渊49
6
这个倒是没有看到，现在是数据量大了，根本写不进去。我看了相关的日志，写入过程主要卡在了分布式事务的Prewrite阶段，查询过程主要卡在了Coprocessor阶段。
1 个赞
在渊49
7
这个还是比较明确的，所以我感觉可能是Tidb本身有什么参数没有调整好
1 个赞
在渊49
8
这个是一条查询语句的卡点，这条其实就是一个简单的 select * from sbtest01 limit 10
1 个赞
h5n1
(H5n1)
13
有缓存提升不少行能，但没缓存也不应该这么差，看下disk performance监控
1 个赞
在渊49
14
看起来disk performance里面是没有数据的，但是overview是有的
1 个赞
sysbench压测用多少线程啊？
TiDB的特点是延迟高，但是处理能力可以多节点分担，也就是吞吐可以很高。
你跑mysql用十几的线程，跑TiDB要用几百到几千的线程跑一个最优的线程数。
经验值大概一个TiDB处理500+线程最优吧。你的是hdd的，不太确定是多少，你试试调整下线程数。
1 个赞
看你的诊断信息里面，提示磁盘慢，可以适当调整下参数，把下面的参数调大一些，多用内存，避免频繁刷盘。至于最后一个wal-bytes-per-sync会不会影响数据安全，这个我也没得到准确答案。数据安全要求比较高的话，只调大write-buffer-size试试吧。
[rocksdb.defaultcf]
write-buffer-size = "512MB"
[rocksdb]
wal-bytes-per-sync = "4M"
1 个赞
在渊49
17
嗯，我们这边做的是对比试验，不同组件之间都是200线程，不过感觉可能是我们用的不对，tidb在当前条件下的TPS有点低
1 个赞
我看了下诊断报告，一个tidb有链接，一个tidb没有连接，这样其实是浪费了一个计算节点。
1 个赞
