【SysBench】从零到一：在Linux上部署sysbench-1.20进行数据库压测

1. 为什么你需要sysbench如果你正在使用MySQL或PostgreSQL这类数据库迟早会遇到一个灵魂拷问我的数据库到底能扛住多少并发请求这时候sysbench就该登场了。这个工具就像数据库的体能测试仪能模拟真实业务场景的压力帮你发现数据库的性能瓶颈。我去年给一个电商项目做性能优化时用sysbench发现了MySQL在高并发下单时的响应时间突然飙升。后来发现是索引没建对优化后QPS每秒查询数直接翻倍。这种问题光靠人眼读代码根本看不出来必须靠压测工具。sysbench有三大杀手锏多面手不仅能测数据库OLTP还能测CPU、内存、文件IO、线程调度低开销哪怕开上千个并发线程监控开销也很小可编程用Lua脚本自定义测试场景想测什么就测什么2. 两种安装方式怎么选2.1 二进制安装适合快速上手如果你只是想快速体验sysbench用二进制安装最省事。这就像下载一个现成的APP解压就能用。以CentOS为例curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash sudo yum -y install sysbench但二进制安装有个小缺点版本可能不是最新的。我有次需要测试PostgreSQL 14的新特性结果二进制版还不支持只能自己编译。2.2 源码编译适合定制化需求想要最新版本或者特殊功能比如PostgreSQL支持就得自己编译。这就像自己下厨材料新鲜还能加配料。先装依赖包yum -y install make automake libtool pkgconfig libaio-devel yum -y install mysql-community-devel.x86_64 openssl-devel yum -y install postgresql-devel这里有个坑要注意安装mysql-community-devel时可能会报GPG密钥错误。这是因为MySQL的密钥文件过期了。解决办法是手动更新密钥rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022然后就可以愉快地编译了./autogen.sh ./configure --with-pgsql # 需要PostgreSQL支持就加这个参数 make -j4 # -j后面跟你的CPU核数编译更快 make install编译完默认安装到/usr/local/bin可以用which sysbench确认位置。我习惯把编译好的二进制文件备份到云存储换机器时直接下载就能用。3. 常见安装问题排雷3.1 依赖包冲突有次在Ubuntu上编译时遇到libmysqlclient版本冲突报错信息看得一头雾水。后来发现是系统自带的MariaDB库在搞鬼。解决办法是先卸载冲突的包apt remove libmariadb-dev3.2 权限问题如果make install时报权限拒绝别急着用sudo。先试试指定安装目录./configure --prefix$HOME/.local这样就不用root权限所有文件都会安装到用户目录下。3.3 版本验证安装完一定要验证版本我有次发现sysbench --version输出不对结果发现是系统自带的旧版本在PATH里优先级更高。用绝对路径执行就正常了/usr/local/bin/sysbench --version4. 第一次压测该注意什么虽然下一篇才会详细介绍压测方法但新手常犯的几个错误我得提前预警不要一上来就开1000线程先从10-20线程开始慢慢加压测试时间别太短建议至少跑5分钟短时间测试可能有误差关注延迟而不只是吞吐量我见过QPS很高但99%延迟超过1秒的系统记得预热数据库冷启动时性能不稳定先跑1分钟预热5. 进阶技巧自定义Lua脚本sysbench自带的OLTP测试脚本在/usr/local/share/sysbench目录下。想自定义测试逻辑的话可以复制一个现有脚本修改。比如模拟电商下单场景function event() -- 模拟查询商品 db_query(SELECT * FROM products WHERE id .. random_id()) -- 模拟下单 db_query(BEGIN) db_query(INSERT INTO orders VALUES(...)) db_query(COMMIT) end这种灵活性是其他压测工具很难比拟的。去年我们就是用自定义脚本发现了Redis集群在跨机房调用时的性能瓶颈。6. 性能数据怎么看sysbench输出的报告里这几个指标最关键指标说明健康参考值QPS每秒查询量越高越好平均延迟请求平均响应时间100ms较理想99%延迟99%请求的响应时间上限不能超过SLA要求错误率失败请求占比必须接近0%我一般会把这些数据导入Grafana做趋势分析比单次测试更有参考价值。7. 真实案例一次OOM排查上个月用sysbench压测时遇到一个典型问题测试开始很顺利5分钟后MySQL突然挂掉。查看日志发现是OOM内存不足。但服务器明明有64G内存啊用sysbench的memory测试模块单独检测sysbench memory --memory-block-size1K --memory-total-size100G run发现内存带宽只有预期的一半。最后查出是NUMA配置问题加上numactl --interleaveall启动MySQL后就稳定了。这种底层问题不靠工具根本发现不了。