KES性能压测与容量规划

KES性能压测与容量规划前面我们把SQL调优、各类集群架构、数据库底层相关内容都梳理完了。这一章我们聊上线之前必须做的两件事也就是性能压力测试、服务器容量预估。我接触过很多国产化落地项目上线之后频繁出现CPU跑满、磁盘空间告警、接口大量超时这类问题。追根溯源大多都是上线前没做完整压测也没提前规划未来几年的资源用量。下面我结合政务、金融、能源行业上百个落地项目的实操经验把压测工具怎么用、各类压测场景怎么跑、指标怎么判断、硬件怎么估算、扩容预案怎么写全部讲清楚。文中的测算逻辑、执行脚本大家可以直接套用到自己负责的项目里。一、 本章学习导读1.1 学习目标能分清功能测试、基准压测、并发压力测试、长时间稳定性测试各自的区别知道什么阶段该跑哪一类测试。熟练使用KES自带的ksql-bench工具会自己编写贴合业务的压测脚本。看得懂压测过程里的各类指标像TPS、QPS、响应延迟、服务器资源、锁等待、主同步延迟这些都要会分析。能根据业务每日数据增量、线上峰值并发算出对应的服务器硬件配置标准。能看懂完整压测报告分辨瓶颈是SQL写得差、缺少索引、参数配置不合理还是硬件资源不够。制定分阶段扩容方案搭建日常容量巡检机制提前预判资源不足的情况。1.2 本章重点四种压力测试分别怎么执行适配什么样的业务阶段ksql-bench完整实操参数配置、自定义脚本、多并发梯度测试压测全程需要监控的指标以及达标的判断标准政务、金融两类业务对应的硬件容量计算方式压测出瓶颈之后一套完整的排查步骤中长期资源预估、分阶段扩容的落地思路二、 为什么压测和容量规划必不可少不少开发、项目负责人都会有一个误区只要功能页面能正常打开就能直接部署上线。线上真实环境和测试环境差别其实很大。测试环境可能就几个人操作数据量也很小。等到正式运行峰值并发会翻几十倍数据每天都在持续新增服务器资源会一点点被消耗掉。我实际碰到过不少踩坑的项目。有的系统刚上线早高峰CPU直接拉满所有接口全部超时有的跑了半年磁盘直接占满数据库被迫停机还有主备集群压测时同步延迟几十秒后台报表拿到的数据完全不准。上面这些问题其实都能在上线前通过完整压测、提前算好资源用量规避掉。分开说两件事的实际作用性能压测能摸清当前数据库和硬件最多能承载多少并发把系统短板在线下修复完毕容量规划预估未来1到3年的数据增量提前备好磁盘、内存、CPU资源不用中途紧急停机扩容整改。三、 四种标准压力测试分类与实施场景3.1 基准性能测试适合的阶段开发人员自测、单条SQL单独验证主要要做的事在没有并发的前提下测出单条业务SQL、单个接口的基础响应速度找出单语句本身存在的慢查询问题。执行方式单会话循环执行目标SQL记录单次运行平均耗时。合格参考标准普通增删改查语句响应控制在10毫秒以内复杂报表查询不超过500毫秒。3.2 并发压力测试适合的阶段前后端联调全部结束之后模拟早高峰、活动时段的大量用户同时访问主要要做的事混合读写脚本多线程执行慢慢拉高并发数量观察TPS、响应延迟、服务器资源变化。合格参考标准峰值并发下95%的请求延迟低于200毫秒CPU平均使用率不超过80%。3.3 长时间稳定性压测耐久测试适合的阶段上线前最终验收环节主要要做的事模拟系统7×24小时不间断运行找出内存持续上涨、磁盘无限膨胀、锁堆积、主备同步滞后、VACUUM清理失效这类不容易短期暴露的隐性问题。执行方式维持中等并发连续跑12到72小时每小时记录资源占用、慢SQL条数、数据增量。容易测出的问题长时间运行内存只增不减MVCC过期数据越堆越多磁盘占用持续暴涨。3.4 极限破坏性压测适合的阶段整体架构验收、集群故障模拟演练主要要做的事不断加大并发线程直到TPS不再上涨、延迟大幅升高、服务卡顿记录系统能承载的临界并发数值。业务用处给线上接口设置限流阈值避免突发大流量冲垮数据库。四、 KES压测工具ksql-bench实战ksql-bench是KES安装包自带的压测工具不用额外单独部署各类国产化服务器都能正常运行。支持自定义业务脚本、多并发模拟同时兼容Oracle写法国产化项目基本都会选用这个工具做压力验证。4.1 基础环境准备完整装好KES配置好环境变量终端可以直接调用ksql-bench测试库里面的数据规模尽量贴近线上三个月存量数据测试环境暂时关掉定时备份、日志自动轮转这类后台任务避免干扰压测指标压测开始前记录初始磁盘占用、空闲内存、现有数据库连接数量。4.2 基础压测命令模板# 基础只读压测开启50并发持续运行300秒ksql-bench-h127.0.0.1-p54321-Usys-dtest_db\-c50-T300-Sselect_test.sql简单说下每个参数-h 数据库IP地址-p 数据库端口-U 登录账号-d 目标数据库-c 并发线程数量-T 压测持续秒数-S 存放SQL的脚本文件4.3 混合读写压测脚本示例business.sql模拟线上八成日常操作包含查询、新增、修改三类语句-- 1. 用户基础查询读操作占70%SELECTusername,phoneFROMt_userWHEREuid:random_uid;-- 2. 新增订单写操作占20%INSERTINTOt_order(oid,user_id,amount,create_time)VALUES(seq_order.NEXTVAL,:random_uid,199.5,SYSDATE);-- 3. 更新订单状态修改操作占10%UPDATEt_orderSETorder_status2WHEREoid:random_oid;脚本里:random_uid是工具内置变量运行时会自动生成随机主键模拟真实随机访问数据的行为。4.4 阶梯并发压测用来找到性能拐点每次调整并发数单次运行180秒两组测试中间间隔五分钟释放系统资源再观察TPS变化情况# 并发20线程ksql-bench-c20-T180-Sbusiness.sql# 并发50线程ksql-bench-c50-T180-Sbusiness.sql# 并发100线程ksql-bench-c100-T180-Sbusiness.sql# 并发200线程ksql-bench-c200-T180-Sbusiness.sql正常变化趋势并发上涨TPS同步提升到达临界值之后再增加并发TPS不再上涨甚至下跌响应延迟翻倍。这个临界点就是当前硬件搭配数据库能承载的最大并发。4.5 压测结果核心输出字段解读压测结束工具会输出汇总数据重点盯下面四项TPS每秒完成事务数量交易类系统核心参考指标QPS每秒执行查询数量政务、资讯查询系统重点看avg_latency平均响应耗时单位毫秒95th_latency95分位延迟更贴近真实用户的访问感受比平均值参考价值更高。五、 压测全过程监控指标与判定标准只看工具输出的TPS数值是不够的服务器、数据库两层指标都要同步记录。我整理了线上验收通用的合格标准压测的时候直接对照查看。5.1 服务器硬件指标CPU高峰期平均占用不超过80%短时峰值不超过90%长期满载必须优化内存空闲内存持续保持2G以上不要频繁发生swap交换。一旦大量swap性能会断崖式下滑磁盘IOutil磁盘读写利用率控制在85以内IO等待数值不能长期居高不下磁盘增长速度记录每日数据新增量给后续容量测算提供依据。5.2 数据库内核指标锁等待压测全程没有持续阻塞的会话死锁报错尽量不出现慢SQL压测过程里没有频繁出现单次耗时超500毫秒的语句主备延迟集群环境流式同步延迟控制在100毫秒以内连接数峰值连接不超过max_connections配置的七成预留缓冲空间事务回滚比例异常回滚低于0.5%比例偏高说明业务逻辑或者索引存在问题。5.3 指标不达标的典型现象与背后原因TPS不跟着并发上涨延迟持续拉高SQL缺少索引大量全表扫描2 CPU长期跑满语句里复杂计算过多或是work_mem设置偏小频繁现场排序3 IO占用拉满查询速度很慢大批量删除没有执行VACUUM或是没有做表分区4 主备同步延迟持续变大单事务写入数据量太大WAL日志传输跟不上。六、 业务容量测算完整模板容量测算分成磁盘、内存、CPU三块分开计算区分政务查询业务、金融交易业务两套计算方式可以直接带入自身业务数据计算。6.1 磁盘容量测算公式总磁盘预留空间 业务原始数据 × 三年增长幅度 索引占用空间(原始数据50%) WAL归档日志 备份文件空间举个实际例子某政务办系统现有存量数据50GB每天新增0.3GB一年按365天计算规划使用三年三年原始数据总量50 0.3×365×3 378.5GB索引预估占用190GB归档和备份预留200GB整体需要磁盘≈770GB生产环境建议直接配1TB固态盘留出冗余空间。这里提一句容易忽略的点很多人只算业务表数据索引、日志、备份占用的空间往往比业务数据还要多。6.2 内存容量测算规则KES里shared_buffers一般设置为物理内存的四分之一服务器内存分档参考测试环境、小型政务系统并发不超过5016G内存中型业务、读写分离读节点并发50~20032G内存金融核心库、分布式数据节点并发20050064G128G内存大型集群主库、海量分片节点256G及以上内存。6.3 CPU核心测算规则根据峰值TPS匹配CPU配置TPS小于5004核CPUTPS 500~20008核CPUTPS 2000~500016核CPUTPS超过500032核及CPU搭配读写分离分摊压力。6.4 分阶段扩容规划设置预警阈值磁盘占用到80%、CPU长期85%、频繁触发swap交换短期扩容一个月内处理加大内存、更换高速固态盘、优化耗时SQL中期扩容半年周期搭建读写分离、大表按月归档历史数据长期扩容1至3年搭建分布式分片集群拆分超大业务表。七、 压测瓶颈标准化排查链路压测指标达不到预期按下面顺序逐层排查不用漫无目的地试错① 先看服务器资源CPU/IO/内存跑满的话优先升级硬件② 抓取压测期间的慢SQL用EXPLAIN ANALYZE查看是否存在全表扫描、缺失索引③ 查看锁相关系统视图确认是否存在长事务、行锁升级为表锁④ 核对内存、WAL、work这类核心参数配置是否过于保守⑤ 集群环境查看主备同步延迟判断是否大事务阻塞同步⑥ 数据体量过大的话评估分区、分布式分片方案。八、 真实项目压测容量规划完整案例8.1 项目背景地市一网通办政务平台预估每日办件3万笔高峰期并发120采用单实例主备架构规划三年使用周期。8.2 压测过程基准测试单用户办件查询耗时12毫秒新增办件25毫秒梯度并发压测并发12时TPS稳定42095分延迟160msCPU平均72%72小时耐久测试磁盘每日增长0.28GB没有内存持续上涨的情况主备延迟稳定50ms极限压测并发到200之后TPS下滑系统临界并发上限150。8.3 容量测算现有初始数据30GB日均新增0.28GB三年业务数据336GB索引168GB归档备份预留180GB整体需要684GB服务器配置1TB高速磁盘。峰值并发120、TPS420搭配8核32G服务器一主一备部署。8.4 落地优化与上线规范办件流水表按月分区高频查询字段补充复合索引每天凌晨归档半年前历史数据磁盘占用80%配置短信告警每月输出容量统计报表。8.5 落地效果上线运行18个月没有出现资源告警早高峰接口不会超时不用临时扩容。九、⚠️ 压测与容量规划高频踩坑点测试库数据量远小于线上真实存量压测出来的数值没有参考价值要按比例构造测试数据压测的时候没有关闭定时备份、审计后台进程占用资源导致指标失真计算磁盘空间只统计业务表忽略索引、WAL、备份很快磁盘告急只看平均延迟忽略95、99分位延迟高峰期用户体验很差耐久压测只跑几小时内存、版本堆积这类长期问题测不出来一上来就扩容硬件不去优化SQL、做表分区瓶颈依旧存在。