TiDB 在银行业核心系统压力测试应用与POC测试参考

网友投稿 525 2024-03-23



背景

在信创和国产化的背景下,政企银行国企等会在不久的将来全面实现国产化。就银行业底层使用的数据库而言,会逐步从小***小机、***大机等国外产品逐步替换为使用国产数据库,从边缘系统开始替换积累使用经验,后逐渐全面覆盖到核心系统。

TiDB 在银行业核心系统压力测试应用与POC测试参考

在核心系统迁移到国产数据库前,需要做很多测试工作,其中很关键的一项的测试就是应用压测,应用压测可以模拟真实业务场景中用户使用,得到系统最真实的性能表现。作者在最近在某银行进行一次核心系统poc测试之后,将测试中的一些想法和调优手段进行整理之后编写这篇文章。

文章内容导读

应用压测架构

在通常的应用压测架构中,会在在压测端配置好压测任务项。

主要配置信息有:1、应用请求接口;2、模拟请求数据集;3、压测任务用户数(请求并发数)。

开始压测后,压测机根据配置的用户并发数,向应用集群发送一个或多个请求,通常在一个请求中,应用会向数据库发送多次请求,数据库也会多次向应用返回结果集,即一次压测请求,应用和数据库可能会有多次交互。

应用压测方式与目标

对于应用压测结果的考察有如下通常两种模式:

在同等机器资源下,固定压测用户并发下,测试得到TPS。

在同等机器资源下,可调整加大压测用户并发,直至测出性能拐点,取最高的TPS作为成绩。

在进行应用压测前还需要知道一些概念:

应用压测TPS不等于数据库事务TPS。应用压测TPS概括的生命周期是压测机向应用发起请求到请求回复结束,数据库事务TPS生命周期是begin和end之间

对于考察固定压测并发,通常应用和数据库都不会有资源瓶颈,最终压测结果和数据库sql执行的快慢强相关。

对于可以加大并发测出拐点性能的考察模式,理论上压测结果与sql执行快慢和sql执行成本强相关。

TPS*平均响应延时=1,系统平均响应越快,耗时越短,TPS越高。

小插曲

作者在某次poc测试时,目标是测试出拐点性能,但是压测平台显示增加了压测并发之后,TPS无明显提升,且数据库各项资源使用率<50%,后面排查到原因是应用服务器资源使用达到了瓶颈,导致的即使再增加压测并发,应用也不能处理更多的请求,这样TPS也不会有提升。

这个也给作者了一个启发,虽然压测的目标是换国产数据库去测试,想去测试国产数据库性能,但是应用压测实际上测试的是整个系统的能力,调优要把视野放大。这点很重要,后面会谈到调优排查到应用的问题。。。

tidb高性能部署原则

tikv节点部署推荐

tikv磁盘部署最佳实践是利用上服务器本地多块高速磁盘进行部署,例如nvme ssd等。在poc中,不推荐像单机数据库一样使用中心化存储,nas存储等,有多块盘也不推荐做raid,tidb原生多副本就具有高可用性

通常单台服务器如果有多块磁盘,会考虑每块磁盘上部署一个tikv节点,如果只有一块磁盘也可以考虑部署两个tikv节点

tidb server 节点部署推荐

通常建议tidb server 数据量不低于tikv节点数据量。在多次实测中表明,在平均每台服务器只部署了一个tidb节点的情况下,将tidb server 数量进行扩容,集群性能有提升。

pd 节点部署推荐

推荐pd部署在ssd上;通常无特殊要求,部署三个节点就行;如果涉及到跨中心测试,推荐参考多中心部署多pd leader 来避免tso wait过高,参考:专栏 - 三地五中心,TiDB POC最佳实践探索 | TiDB 社区

推荐组件绑定numa核心

tidb的组件绑定numa核心后,可避免cpu跨通道访问内存带来的延迟过高。但是存在的问题就是绑定核心的组件只能使用该核心分配的内存,例如tikv混布又绑定了核心,如果涉及到tikv可用内存不足够block cache使用,这就得实测判断是否绑定核心。

业务环境与部署选择

在上述部署推荐中,我有建议部署多数量节点的趋势,也推荐组件去绑定numa核心,这样会涉及到节点混布下,节点相关参数调低,或单组件可用内存上限降低,造成单组件上限瓶颈降低。

但通常而言,核心系统都是都是纯交易系统,功能模块例如:跨行转账,账户信息查询等,几乎都是低成本扁平化sql,多个节点资源使用比较均衡,所以不会存在大expensive sql造成的瓶颈问题。

连接TIDB的方式

使用mysql 8.0 驱动连接tidb

#链接需要加上预编译处理的参数url: jdbc:mysql://IP:PORT/DB_

使用tidb loadblance驱动连接tidb

在poc测试中更推荐使用该驱动去直连接tidb,多次实测表明,使用该驱动会比mysql驱动连接f5等负载均衡的方案性能要好一点。

但是该驱动暂未正式GA,作者也在使用过程中发现一些其他问题,记录一下

遇到的问题一:使用该驱动可能会导致负载不均衡

遇到的问题二:该驱动所带的负载均衡没有该可用策略,部分tidb server 节点失活后,请求还是会持续转发到失活节点,导致应用持续报错。

参考haproxy探活,检测到下游节点失活后,后续请求不会转发到不可用节点。

listen tidb-cluster # 配置 database 负载均衡。 bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 mode tcp # HAProxy 要使用第 4 层的传输层。 balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务,例如 LDAP、SQL、TSE 等,而不是短会话协议,如 HTTP。该算法是动态的,对于启动慢的服务器,服务器权重会在运行中作调整。 server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 #检测 4000 端口,检测频率为每 2000 毫秒一次。如果 2 次检测为成功,则认为服务器可用;如果 3 次检测为失败,则认为服务器不可用。 server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3

优化SQL解析、编译、优化生成执行计划时间

使用预编译+prepare plan_cache进行调优

1、连接串添加预编译的参数

useServerPrepStmts=true&prepStmtCacheSqlLimit=10000000000&prepStmtCacheSize=102400&useConfigs=maxPerformance&rewriteBatchedStatements=true

2、调整数据库prepare plan cache 参数

3、检查plan_cache效果

dashboard上能看到大部分sql解析时间为0 ,优化时间为微秒级

4、判断是否还需要调整prepare plan_cache参数

plan cache 内存使用小于参数值,且plan_cache命中率高,无需调整参数

未使用使用预编译提交sql

1、开启数据库参数

2、查看效果。

由于non prepared_plan_cache这个功能刚出,大量受到限制的sql无法走上该功能

tidb相关参数调整与建议

tidb server { #可以减少日志打印log.level: error log.slow-threshold: 3000 } tikv { gc.enable-compaction-filter = true log.level = error#如下参数不再给具体值建议,根据环境情况来,最佳性能模式下,这些参数的原则是:不会造成瓶颈。 raftstore.store-pool-size: readpool.unified.max-thread-count: server.grpc-concurrency: storage.block-cache.capacity: }

排查全局负载均衡

1、排查应用负载是否均衡

观察应用集群每台应用服务器cpu使用率和内存使用率是否均衡

2、查看tidb server 连接数和请求是否均衡

连接均衡是请求均衡的前提条件,请求均衡才是目的

3、排查tikv region和region leader 是否均衡

4、排查tikv请求是否均衡

由于请求类型与请求消耗资源关联有可能非常大,所以我一般直接去看tikv相关的线程使用率是否均衡

SQL调优与常见方向

1、补全索引等

参考:

SQL 性能调优 | PingCAP 文档中心

2、改写sql

有些sql的写法走不了plan_cache,参考:Prepare 语句执行计划缓存 | PingCAP 文档中心

有些sql如标量子查询连接没法下推等。

3、优化表结构

例如:nocluster表换成聚簇表,即找高频唯一索引查询变成clustered index

缓存表

缓存表 | PingCAP 文档中心

可以考虑给只有DQL,没有DML操作的表加缓存表

1、找到所有DQL操作的表(可借助dashboard)

2、判断这些这些表sql没有DML操作的表(可借助dashboard)

3、ALTER TABLE table_name CACHE

基于颜色优化法排查数据库瓶颈

Performance Overview 面板重要监控指标详解 | PingCAP 文档中心

TiDB 性能分析和优化方法 | PingCAP 文档中心

通过去看整个sql执行流程上各阶段耗时去整体评估系统是否存在性能问题,通常颜色深的部分占比大需要注意和排查

优化coprocessor cache

1、观察监控,miss的可能是因为region有修改,这个没办法,evict要是多可能是因为cache大小不够而产生的缓存淘汰,可以调大cop cache参数

2、调整capacity-mb的大小。

小表热点

可能会存在这样一种情况,某张表只有几万行,这个时候大概率这张表只有一个region(raft group这里先不讨论),这样对这张表所有的读写都会集中在一个tikv上,但是在进行应用压测的时候这个SQL是高频sql,热力图上也显示该sql读写流量高,这个时候会出现热点瓶颈,也导致整体延时上升

取巧方案:

pdctl tiup ctl:v<CLUSTER_VERSION> pd -u http://<pd_ip>:<pd_port>[-i] 1、临时关闭合并region的调度 config set max-merge-region-keys 50 config set max-merge-region-size 1 2、多次切割region切割region operator add split-region 1 --policy=scan

尝试开启非可重复读

在不介意幻读的情况下,可设置该参数,可显著降低tso_wait耗时

该参数是实例级别,需要依次连接每一个实例去设置 set tidb_rc_read_check_ts =on

如果应用事务里面依赖可重复读,开这个参数可能会报错,例如:在一个事务里面多次查序列

排查数据库外耗时

当整个系统响应耗时大部分不在数据库侧时,这时候即使在数据库侧优化的再好,也没办法去优化好整体性能

1、大致评估系统外耗时

TiDB 性能分析和优化方法 | PingCAP 文档中心

2、如果感觉连接空闲时间很长,即数据库外耗时多,则需要排查应用-数据库之间网络延迟,应用资源使用率等

作者在某次排查到应用集群时发现,所有的应用服务器上某个端口的应用实例没有起,所以其实应用出问题也是很正常的。

算计GC间隔与压测项时长

默认配置下,GC 每 10 分钟触发一次,每次 GC 会保留最近 10 分钟内的数据。通常而言压测环境美伦GC任务耗时<2min

常见的应用压测项耗时,10分钟、15分钟。在这种配置下,几乎每轮压测期间都会执行GC任务

为了达到更稳定优异的性能,可以把tidb_gc_run_interval 调大,例如调整到1小时做一次,大概率压测期间就不会碰到在做GC了

手动进行compaction

可以手动对TIKV进行compact操作后再进行压测,谋求更优异的性能

TiKV Control 使用说明 | PingCAP 文档中心

写在最后

1、应用系统压测是对一个系统性能的检验,调优会涉及到方方面面,软件、cpu、内存、网络等等。

2、带你重走 TiDB TPS 提升 1000 倍的性能优化之旅 | PingCAP,写完文章后找到了一篇官方在V5时代出的一篇性能压测的文章,分析的更细致和循序渐进,可以看一看,其中思想和我的文章有重复的,但是我最佳poc大多是基于V6和V7版本做的,有一些新特性。官方文章更侧重讲思路和推理分析,而我这更侧重可行性实操分享。

作者介绍:BraveChen,来自神州数码钛合金战队,是一支致力于为企业提供分布式数据库TiDB整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景,全部拥有TiDB高级资格证书,并活跃于TiDB开源社区,是官方认证合作伙伴。目前已为10+客户提供了专业的TiDB交付服务,涵盖金融、证券、物流、电力、政府、零售等重点行业。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:云原生数据库概念,简化数据管理的未来
下一篇:TiDB 在长银五八消费金融核心系统的适配与实践分享
相关文章