1. 压测工具选型指南

第一次接触PostgreSQL性能测试时，我面对十几种工具直接懵圈。经过多年实战，发现sysbench和pgbench这对组合能解决90%的压测需求。它们就像数据库性能测试的"瑞士军刀"——sysbench是多面手，支持多种数据库；pgbench则是PostgreSQL专属利器。

sysbench的优势在于场景丰富，内置了20+测试脚本，从纯读写到混合负载都能模拟。去年我们做电商系统优化时，就用它的oltp_read_write.lua脚本完美复现了"双十一"流量高峰。而pgbench的强项是轻量级，作为PostgreSQL原生工具，连安装步骤都省了，特别适合快速验证配置调整效果。

这里有个新手容易踩的坑：不要用sysbench测试MySQL的指标直接对比PostgreSQL！我见过团队因此得出错误结论。不同数据库的存储引擎和锁机制差异很大，必须用相同工具在相同环境下测试才有可比性。

2. sysbench实战全攻略

2.1 快速安装指南

在CentOS上安装sysbench只需三条命令：

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
sudo yum -y install sysbench
sysbench --version

如果遇到"SCRAM authentication requires libpq version 10"报错，这是缺少PostgreSQL开发库导致的。解决方法：

yum install -y postgresql12-devel

2.2 测试脚本详解

sysbench的精华在于lua脚本，/usr/share/sysbench/目录下有这些宝藏文件：

• oltp_read_write.lua：读写混合（14:1:1:1:1的比例）
• oltp_point_select.lua：主键查询
• bulk_insert.lua：批量插入
• select_random_ranges.lua：范围扫描

去年优化订单查询时，我发现select_random_points.lua脚本能完美模拟用户随机查看历史订单的场景。通过调整--range-size参数，可以控制查询范围的大小。

2.3 完整测试流程

准备测试数据（10张表，每表10万行）：

sysbench oltp_common.lua \
--db-driver=pgsql \
--pgsql-host=192.168.1.100 \
--pgsql-port=5432 \
--pgsql-user=test \
--pgsql-password=123456 \
--pgsql-db=sbtest \
--table-size=100000 \
--tables=10 \
--threads=32 prepare

执行压测（关键参数说明）：

sysbench oltp_read_write.lua \
--db-driver=pgsql \
--pgsql-host=192.168.1.100 \
--report-interval=10 \
--threads=64 \
--time=300 \
--percentile=99 \
--db-ps-mode=disable \
run

--percentile=99 这个参数特别有用，它能显示99%请求的响应时间，比平均延迟更能反映真实体验。上周我们通过这个指标发现，虽然平均TPS很高，但长尾请求导致部分用户超时。

3. pgbench深度解析

3.1 数据初始化技巧

初始化1000万测试数据（-s 100表示100倍基准数据量）：

pgbench -i -s 100 -U postgres testdb

有个性能优化技巧：先设unlogged table再转普通表。在大数据量初始化时能快3-5倍：

CREATE UNLOGGED TABLE pgbench_accounts(...);
-- 导入数据后
ALTER TABLE pgbench_accounts SET LOGGED;

3.2 高级测试模式

除了默认的TPC-B模式，pgbench还支持：

• -N：跳过分支和柜员表更新
• -S：纯SELECT测试
• -M prepared：使用预处理语句

这是我常用的混合测试命令：

pgbench -M prepared -c 64 -j 8 -T 600 -P 10 \
-r -D scale=100 -D range=10000000 testdb

-D参数是隐藏法宝，可以动态传参给测试脚本。去年我们用它模拟了不同热数据比例的测试场景。

4. 结果分析与优化

4.1 关键指标解读

• TPS波动分析：用--report-interval=10查看每10秒的TPS，突然下跌可能触发锁等待
• 延迟百分位：99%延迟≤50ms比平均延迟≤10ms更有参考价值
• 连接时间：initial connection time过大要检查认证或网络

这是我设计的监控命令组合：

watch -n 1 'psql -c "SELECT wait_event_type, count(*) FROM pg_stat_activity GROUP BY 1"'

4.2 典型优化案例

遇到TPS瓶颈时，我通常会检查这些参数：

max_connections = 500
shared_buffers = 8GB
work_mem = 16MB
random_page_cost = 1.1

有个真实案例：把max_wal_size从1GB调到4GB后，批量导入性能提升40%。WAL配置对写密集型负载影响巨大。

最后提醒：压测后一定要执行pgbench -i -s 0清理测试数据，我见过测试表把生产存储撑爆的悲剧。