【 TiDB 使用环境】生产环境(伪集群)
【 TiDB 版本】v8.1.0
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】40 vcore ,amd64, 141.2Gib 1pd,1tidb,6tikv
【复制黏贴 ERROR 报错的日志】
【其他附件:截图/日志/监控】
请问这个配置,和部署情况,使用sql 批量插入,写入性能能到多少。
下面是监控界面的tikv 写入速率。(python 中四个进程进行插入,一次批量插入1000条)
30分钟,插入700万条数据,列数29,都是varchar 不超过256。
这个速度是正常的吗,或者有哪些可改善的呢?
有猫万事足
2
1 个赞
好的,我先看看您发的过一遍,写入热点,当时看过,不存在热点问题。进程当时测是开到6个写入速率就顶天了。1.3m/s 在多也上不去了。集群就是1个pd,1个tidb,6个kv 。都在一台物理服务器上。
物理服务器,这个是用的SDD还是HDD?从图上看,写入速度低,网络连接速度慢.
有没有试过先将线程弄成一个,慢慢往上加,看一下瓶颈在哪里
都是ssd, 网络是千兆的,而且是伪集群部署的。之前试过,就是逐渐加线程,在这个机器上加到8个线程写入速度就不会叠加了。但是好像每个kv节点最高不超过2m/s,再加每个线程单次插入的耗时就会随之增加。就是几乎没有提升了
有猫万事足
10
你现在这个问题,我能想到的和好几个问题可能都有相关性。
1,你的集群拓扑是什么样的?
这个最基础也最关键。一句伪集群部署是说不清楚的。
我只能说原则上如果测试阶段资源不够,pd和tidb部署在一起,tikv最好单独部署。你这个性能如果是6个tikv挤在一个ssd的盘上,就很正常。
2,你使用python来测试是缺乏比较基准的。
python里面运行的东西,写的什么样,这就能造成巨大的差距。
python的多线程和GIL密切相关,写的不好,和单线程没差别。
而多进程的话,调整并发度非常困难。
正常压力测试200并发稀松平常,但你要起200个进程来测。我估计是要花点功夫的。
这就是为什么我推荐你使用tpcc/sysbench,而不建议你使用自己写的python来测试的原因。
3,tidb的监控确实比较多,也比较碎。
建议你看一下这个视频,也许看过后,可以自己定位到问题所在。
一开始这个视频就会告诉你,要先看
https://docs.pingcap.com/zh/tidb/stable/dashboard-monitoring#connection-idle-duration
connection-idle-duration这个指标,能明确说明瓶颈在db内,还是在db外。
我看你从4个并发调到6个,再调到8个,每次其实写入都有些许提高,我感觉并发还是不够的。connection-idle-duration估计看着还是不低的。这和问题2又相关了。
1 个赞
感谢大佬码了这么多字,磁盘总共是72T 的ssd 做的raid, 挂载在一个磁盘目录。应该不是磁盘性能问题。我有时间用这个tpcc/sysbench测试工具测一下。
小龙虾爱大龙虾
(Minghao Ren)
12
看下 SQL,你这 1000 是怎么提交的
现在这效率很低,io 根本没有到瓶颈
diwing
(Ti D Ber R Qstj35v)
13
试试import into,我这边30s就导入了100万
有猫万事足
15
这个性能上限是不如每个tikv单独挂一个ssd的,tidb默认就是3副本分布式设计,所以不做raid性能更好。
如果害怕同时挂2个tikv导致的集群不可用的问题,可以把副本数调到5个。这样就是同时挂3个才会导致集群不可用了。
zhanggame1
(Ti D Ber G I13ecx U)
16
你这个绝对不可能是io瓶颈,先看看tidb-server是不是负载太高,tidb不同于mysql,只是写入io比mysql需求低,但是tidb-server对cpu需求高很多