本文使用SysBench测试PostgreSQL服务在不同并发线程数下的性能表现。
一、环境信息
被测服务器(192.168.132.167)：
- 4核8线程，32GB，1TB 7200转机械硬盘
- CentOS 7.9
- PostgreSQL 9.6.2
测试客户端(192.168.130.152)：
- 4核8线程，32GB，2TB 7200转机械硬盘
- CentOS 7.9
- SysBench 1.0.17
网络：
- 千兆以太局域网
二、测试综合性能
为了测试不同参数下数据库的性能表现，我们通常会将测试过程写成shell脚本循环执行。由于性能测试的时间可能很长，我们用tee命令将每次测试的结果保存到文件以免丢失数据。
我们用下面的脚本测试在不同线程数下的综合性能（oltp_read_write）。
#!/bin/sh
pg_host=192.168.132.167
pg_port=5432
pg_user=sbtest
pg_password=password
pg_db=sbtest
for ((threads=5; threads<=160; threads=threads+5));do
sysbench oltp_read_write \
--pgsql-host=$pg_host --pgsql-port=$pg_port \
--pgsql-user=$pg_user --pgsql-password=$pg_password \
--pgsql-db=$pg_db \
--table_size=100000 --tables=12 \
prepare
sysbench oltp_read_write \
--pgsql-host=$pg_host --pgsql-port=$pg_port \
--pgsql-user=$pg_user --pgsql-password=$pg_password \
--pgsql-db=$pg_db \
--report-interval=5 \
--table_size=100000 --tables=12 \
--threads=$threads \
--time=30 \
run | tee -a result.txt 2>&1
sysbench oltp_read_write \
--pgsql-host=$pg_host --pgsql-port=$pg_port \
--pgsql-user=$pg_user --pgsql-password=$pg_password \
--pgsql-db=$pg_db \
--tables=12 \
cleanup
done上面测试脚本的结果保存在result.txt文件里，使用下面的命令可以获取到所需的数据项，方便粘贴到excel表格里画图：
获取平均QPS值（考虑到超过100000的情况因此用两个cut实现）：
cat result.txt |grep queries:|cut -c 40-57|cut -d '(' -f 2
获取平均Latency值：
cat result_read.txt |grep avg:|cut -c 48-65为减小误差，我们把测试脚本执行了2次，将每次得到的各线程数下的QPS数值画成一条曲线并叠加，得到下面的统计图，其中横轴是并发线程数，纵轴是QPS均值：
测试结果里各个线程数下TPS数值与QPS都十分接近20:1的关系，所以这里不单独画图展示TPS了。
从图中可以看出，两次测试结果比较接近，随着线程数增加QPS指标也同步增加，在120线程左右达到峰值。
两次测试的平均请求延迟（latency，毫秒）统计如下图所示，其中横轴仍然是并发线程数，纵轴是延迟时间：
延迟基本与线程数正相关，并且在140线程以上斜率有所增加。
三、测试只读性能
我们使用sysbench oltp_read_only命令测试纯读取场景下，不同线程数的QPS表现：
#!/bin/sh
pg_host=192.168.132.167
pg_port=5432
pg_user=sbtest
pg_password=password
pg_db=sbtest
sysbench oltp_read_only \
--db-driver=pgsql \
--pgsql-host=$pg_host --pgsql-port=$pg_port \
--pgsql-user=$pg_user --pgsql-password=$pg_password \
--pgsql-db=$pg_db \
--table_size=100000 \
--tables=12 \
prepare
for ((threads=5; threads<=120; threads=threads+5));do
sysbench oltp_read_only \
--db-driver=pgsql \
--report-interval=5 \
--table-size=100000 \
--tables=12 \
--threads=$threads \
--time=30 \
--pgsql-host=$pg_host --pgsql-port=$pg_port \
--pgsql-user=$pg_user --pgsql-password=$pg_password \
--pgsql-db=$pg_db \
run | tee -a result.txt 2>&1
done
sysbench oltp_read_only \
--db-driver=pgsql \
--pgsql-host=$pg_host --pgsql-port=$pg_port \
--pgsql-user=$pg_user --pgsql-password=$pg_password \
--pgsql-db=$pg_db \
--tables=12 \
cleanup为减小误差，我们把测试脚本执行了2次，将每次得到的各线程数下的QPS数值画成一条曲线并叠加，得到下面的统计图，其中横轴是并发线程数，纵轴是QPS均值：
测试结果里各个线程数下，TPS数值与QPS都十分接近16:1的关系，所以这里不单独画图展示TPS了。
从图中可以看出，两次测试结果比较接近，都是在50个并发线程时达到QPS峰值（大约35000请求/秒）。
两次测试的平均请求延迟（latency，毫秒）统计如下图所示，其中横轴仍然是并发线程数，纵轴是延迟时间：
从图中可以看出，两次测试结果比较接近，随着线程数量的增加，平均延迟是单调上升的，即使在并发50个线程QPS已经达到峰值后，平均延迟也是上涨的。因此从这两项测试结果来看，在50线程以上继续增加线程数量是没有意义的。
