达梦数据库JMeter压测与故障切换测试实战本文详细记录了达梦数据库相关集群的部署与测试过程包括环境准备、配置步骤、验证方法及踩坑记录。文章目录达梦数据库JMeter压测与故障切换测试实战概述测试目标测试环境测试工具测试方法测试表设计JDBC连接配置测试计划结构梯度加压法性能摸高测试测试结果总览性能阶段分析低压阶段10~25线程饱和阶段25~50线程过载阶段500~1000线程系统稳定性单节点vs主备集群性能对比测试结果对比性能差异分析备机宕机恢复测试测试目的测试过程与现象现象分析主备故障切换测试测试目的测试过程切换过程分析切换结果验证测试结果汇总与分析关键指标汇总关键发现性能优化建议心得体会概述测试目标本次JMeter压测测试旨在全面评估达梦数据守护集群的性能表现和高可用能力。主要包括三部分内容一是性能摸高测试通过梯度加压找到数据库的性能拐点和最大吞吐量二是单节点与主备集群的性能对比量化数据守护的性能开销三是故障切换测试验证主库故障时的自动切换能力和业务恢复情况。通过本次测试可以深入了解达梦数据库在不同压力下的性能表现验证数据守护集群的高可用性为生产环境的容量规划和性能优化提供数据支撑。测试环境测试工具Apache JMeter是一款开源的压力测试工具可以用于测试静态和动态资源、Web动态应用程序的性能。本次测试使用JMeter通过JDBC驱动连接达梦数据库执行自定义SQL压测。主要组件● JDBC Connection Configuration配置JDBC连接池设置连接URL、驱动类、用户名密码、最大连接数等参数。● JDBC RequestJDBC请求执行具体的SQL语句。● 聚合报告统计测试结果包括样本数、平均响应时间、中位数、90%/95%/99%响应时间、吞吐量、异常率等。● jpgc - Transactions per SecondTPS趋势图插件实时展示每秒事务数变化。● jpgc - Response Times Over Time响应时间趋势图插件实时展示响应时间变化。测试方法测试表设计创建PRESS_TEST测试表用于压测CREATE TABLE BENCHMARKSQL.PRESS_TEST (ID INT PRIMARY KEY,NAME VARCHAR(100),VALUE INT,UPDATE_TIME DATETIME);– 插入1万条测试数据BEGINFOR I IN 1…10000 LOOPINSERT INTO BENCHMARKSQL.PRESS_TEST VALUES (I, ‘test’||I, I, SYSDATE);END LOOP;COMMIT;END;/使用随机ID的更新操作模拟真实的OLTP写业务场景UPDATE PRESS_TEST SET VALUEVALUE 1WHERE IDFLOOR(RAND()*10000)1;使用随机ID是为了避免行锁冲突模拟真实业务中不同用户操作不同数据的场景。如果所有线程都更新同一行会导致严重的行锁竞争测不出数据库的真实性能。JDBC连接配置测试计划结构测试计划└── 线程组├── JDBC Connection Configuration├── JDBC Request - 更新请求├── 常数吞吐量定时器可选├── 察看结果树├── 聚合报告├── jpgc - Transactions per Second└── jpgc - Response Times Over Time梯度加压法性能摸高采用梯度加压法从低并发开始逐步增加线程数观察TPS和响应时间的变化找到性能拐点。测试线程数从10线程逐步增加到1000线程覆盖从低压到过载的完整范围。判断性能拐点的标志● TPS不再增长甚至开始下降● 响应时间急剧上升● CPU使用率达到90%以上● 开始出现错误异常率0性能摸高测试测试结果总览采用梯度加压法从10线程逐步增加到1000线程测试主备集群在不同压力下的性能表现性能阶段分析低压阶段10~25线程10到25线程TPS从1278上升到1515平均响应时间从7ms增加到15ms。这个阶段系统处于低负载状态增加并发可以线性提升吞吐量响应时间增长缓慢。25线程时TPS达到峰值约1515这是系统的最佳性能点。此时CPU利用率较高但还没有打满系统还有一定余量。饱和阶段25~50线程25到50线程TPS基本持平从1515微降到1479.8平均响应时间从15ms增加到31ms。这个阶段系统已经接近性能上限增加并发不会提升吞吐量只会增加响应时间。这是典型的饱和阶段特征吞吐量基本不变响应时间线性增长。生产环境中建议将系统运行在这个阶段的前段既保证吞吐量又控制响应时间。过载阶段500~1000线程超过500线程后系统进入过载状态。TPS持续下降响应时间急剧上升。700线程时TPS降到640.9平均响应时间超过1秒1000线程时TPS降到386.2平均响应时间接近2.5秒。过载阶段的特征是吞吐量下降响应时间指数级增长。这是因为过多的并发请求导致大量的上下文切换、锁竞争和资源争抢反而降低了系统的整体处理能力。生产环境中一定要避免系统运行在过载状态否则不仅性能差还可能导致系统不稳定。系统稳定性值得注意的是从10线程到1000线程所有测试场景的异常率都是0%。即使在1000线程的严重过载状态下数据库也没有出现任何错误所有请求都成功执行只是响应时间变长。这说明达梦数据库的稳定性非常好即使在严重过载的情况下也不会崩溃或报错只是性能下降。这对于生产环境来说非常重要——过载时系统变慢但不挂比直接崩溃好得多。单节点vs主备集群性能对比测试结果对比在25线程最佳性能点下对比单节点和主备集群的性能差异性能差异分析主备集群的TPS比单节点低了约47.4%响应时间增加了近一倍。这个差异比预期的要大主要原因是● 实时归档同步开销主库每笔事务都要把日志发送给备库等待备库确认后才能提交。这增加了一次网络往返和备库的日志写入开销。● MAL系统开销主备之间的MAL通信系统本身也有一定的CPU和内存开销。● 守护进程开销守护进程持续监控集群状态也会消耗一定的系统资源。● 2核CPU限制2核CPU的机器同步开销占比更高。如果是多核机器这个比例可能会小一些。这也说明了数据守护集群的性能代价为了高可用和数据安全需要牺牲约一半的写性能。在实际生产环境中需要根据业务对性能和可用性的要求进行权衡。如果业务对性能要求很高可以考虑使用读写分离集群将读请求分发到备库提升整体的读吞吐量。写性能的损耗是无法避免的因为数据同步必然有开销。备机宕机恢复测试测试目的测试备机宕机和恢复过程中主库的性能变化验证数据守护集群在备库故障时的表现以及备库恢复后的性能恢复情况。测试过程与现象在主备集群正常运行的情况下突然杀掉备库进程观察主库的TPS变化。等待一段时间后重启备库观察备库恢复过程中的TPS变化。测试过程中观察到的TPS变化趋势● 主备正常运行TPS约1500左右处于正常水平。主库需要同步日志到备库有一定的同步开销。● 备机宕机瞬间TPS立即飙升到3000几乎翻了一倍。因为不用同步日志了主库全部资源用来处理业务。● 备机宕机期间TPS稳定在3000左右与单节点的性能基本一致。这也反向验证了同步开销的大小。● 备机开始恢复TPS逐渐回落备库开始追赶日志同步开销逐渐增加。● 备机完全恢复TPS回到约2500左右比原本的主备运行水平高这是缓存预热效应——宕机期间主库处理了大量请求数据都在内存里了。现象分析备机宕机后主库性能提升这个现象直观地展示了实时归档的性能开销。备库挂了之后主库不用同步日志了少了一份开销性能自然就上去了。缓存预热效应也很明显。备库恢复后TPS比宕机前还要高这是因为宕机期间主库处理了大量的请求热点数据都加载到内存里了物理读减少性能自然提升。这个测试也验证了数据守护集群的一个重要特性备库故障不影响主库的正常运行主库可以继续提供服务只是失去了高可用保护。主备故障切换测试测试目的测试主库故障时的自动切换过程验证数据守护集群的高可用能力测量故障切换的RTO恢复时间目标和业务中断时间。测试过程在主备集群正常运行、JMeter持续压测的情况下突然杀掉主库进程模拟主库宕机观察业务恢复情况。测试步骤● T0时刻主库正常运行TPS约1600系统处于稳定状态。● T1时刻kill -9杀掉主库dmserver进程模拟主库宕机。● T2时刻TPS降到0应用开始报错业务中断。● T3时刻备库接管升主TPS开始恢复。● T4时刻TPS恢复到正常水平切换完成业务恢复。切换过程分析从TPS曲线上可以清晰地看到故障切换的全过程TPS从正常水平突然降到0然后经过一段时间后恢复到正常水平。中间的掉坑时间就是业务中断时间。整个切换过程包括以下几个阶段● 故障检测守护进程检测到主库故障这个过程需要一定时间取决于检测间隔和超时设置。● 故障确认确认监视器确认主库故障触发切换。● 备库升主备库从Standby模式切换到Primary模式打开数据库提供服务。● 应用重连应用端通过服务名自动重连到新主库这个过程由JDBC驱动和dm_svc.conf自动完成。切换结果验证切换完成后验证以下内容● 服务名自动切换应用端不需要修改任何配置通过dm_svc.conf服务名自动路由到新主库。● 数据一致性切换后数据完整没有丢失。实时归档模式下RPO0不丢失数据。● 业务恢复正常切换完成后TPS恢复到正常水平业务完全恢复。● 新主库状态正常新主库原备库状态正常可以正常提供服务。测试结果汇总与分析关键指标汇总关键发现● 性能拐点明显25线程左右达到性能峰值之后增加并发不会提升TPS反而增加响应时间。● 过载后性能下降超过500线程后系统进入过载状态TPS持续下降响应时间急剧上升。● 主备同步开销大高压力下主备集群的写性能只有单节点的一半左右实时归档同步的开销非常显著。● 备机宕机性能反升备机宕机后主库不用同步日志性能反而提升约一倍。这也反向验证了同步的开销。● 故障切换可靠主库故障后备库自动接管业务自动恢复无数据丢失RPO0。● 系统稳定性好所有压力测试场景下异常率始终为0%数据库稳定性良好。● 过载不崩溃即使在1000线程的严重过载状态下数据库也不会崩溃只是响应变慢。● 缓存预热效应备库恢复后性能比宕机前更高因为宕机期间主库处理了大量请求热点数据都在内存中。性能优化建议● 控制并发数应用端连接池不要设置过大超过数据库的处理能力后增加并发只会增加响应时间不会提升吞吐量。建议将并发控制在性能拐点附近。● 使用连接池使用连接池复用数据库连接减少连接建立的开销。连接池大小建议设置为性能拐点对应的并发数。● 读写分离读多写少的场景可以使用读写分离集群将读请求分发到备库提升整体吞吐量。● 合理配置服务名使用dm_svc.conf服务名配置实现自动故障切换和负载均衡。● 监控性能指标持续监控CPU、内存、IO、TPS、响应时间等指标及时发现性能瓶颈和异常情况。● 容量规划留有余量生产环境容量规划要留有余量不要让系统运行在饱和或过载状态。建议峰值使用率不超过70%。心得体会本次JMeter压测和故障切换测试是一次非常有价值的实践不仅掌握了JMeter工具的使用方法更重要的是对数据库性能测试方法论和高可用集群的工作原理有了更深入的理解。梯度加压法让我直观地看到了系统从低压到过载的完整过程。TPS从上升到平稳再到下降响应时间从线性增长到指数增长这些曲线让我对系统的容量规划有了更具体的认识。以前对性能拐点只是一个概念上的理解现在通过实际测试对它有了直观的感受。过载阶段的现象也很有意思——并发越高吞吐量反而越低。这是因为过多的并发导致大量的上下文切换和锁竞争系统把大部分时间都花在调度上真正处理业务的时间反而少了。这让我理解了为什么生产环境一定要控制并发数不是越多越好。主备性能对比测试让我对数据守护的性能代价有了量化的认识。以前只知道主备同步会有开销但不知道具体有多大。实际测试后发现在2核机器上写性能差了将近一半这个开销比我想象的要大。这也让我明白架构设计是一个权衡的过程高可用是有性能代价的。故障切换测试是最直观的——TPS曲线的那个坑就是RTO的可视化表现。虽然只有几秒的中断但对于核心业务来说每一秒都是损失。这也让我理解了为什么高可用方案这么重要以及为什么企业愿意为了几秒的RTO付出巨大的成本。最有意思的发现是备机宕机时主库性能反而提升这个现象。它用最直观的方式告诉我们世界上没有免费的午餐高可用是有性能代价的。在做架构设计时需要在性能和可用性之间做权衡根据业务的实际需求选择合适的方案。系统稳定性也给我留下了深刻印象。从10线程到1000线程异常率始终是0%即使在严重过载的情况下数据库也不会崩溃只是变慢。这种降级但不挂的特性对于生产环境来说非常重要它意味着系统在面对突发流量时虽然会变慢但不会彻底不可用。总结一下这次测试的核心收获一是性能测试要用数据说话不能凭感觉二是容量规划要留有余量不能让系统运行在过载状态三是架构设计要权衡取舍没有完美的方案只有最合适的方案。这些经验不仅适用于达梦数据库也适用于所有系统的性能测试和架构设计工作。项目配置数据库版本DM8主库IP10.0.0.100备库IP10.0.0.101压测客户端IP10.0.0.103服务器CPU2核服务器内存2GB客户端内存1.9GB测试用户BENCHMARKSQL数据库端口5236守护组名GRP1OGUID45331压测工具JMeter 5.6.3JDK版本JDK 21JDBC驱动DmJdbcDriver11.jar参数配置值说明Variable NameDM_POOL连接池变量名Database URLjdbc:dm://DM_TPCC使用服务名连接集群JDBC Driver classdm.jdbc.driver.DmDriver达梦JDBC驱动类UsernameBENCHMARKSQL数据库用户名PasswordZz200066!数据库密码Max Number of Connections100连接池最大连接数Connection Validation勾选启用连接验证Validation QuerySELECT 1验证查询语句线程数平均响应时间(ms)TPS90%响应(ms)99%响应(ms)异常率1071278.117250.00%15101353.023370.00%25151515.735510.00%50311479.869800.00%100186530.02904300.00%3002441198.65466380.00%5004821009.2106813170.00%7001007640.9232227510.00%10002495386.2683577750.00%测试场景线程数平均响应时间(ms)TPS性能差异单节点2582883.2基准主备集群25151515.7-47.4%测试项目关键指标测试结果性能峰值峰值TPS约151525线程主备性能峰值峰值响应时间15ms平均性能峰值单节点峰值TPS约288325线程主备性能损耗TPS差异主备比单节点低约47.4%主备性能损耗响应时间差异主备响应时间约为单节点的2倍备机宕机影响性能提升备机宕机后主库TPS提升约一倍备机宕机影响业务影响备机宕机不影响主库业务故障切换业务中断有短暂中断自动恢复故障切换数据丢失无数据丢失RPO0系统稳定性异常率0%所有测试场景系统稳定性最大并发1000线程仍稳定运行无报错