1. assert带来的性能影响
非正式版本的pgbench打开了assert。通过以下命令来确定:
postgres=# show debug_assertions;
debug_assertions
------------------
off
(1 row)
如果该设置是关闭的(编译时决定是否打开),则这里看不到什么内容。
2. 默认配置不是最佳性能
默认的配置postgresql.conf
会使得pgbench的性能很差。可以重点修改这两个配置,能够带来明显的性能提升:
- shared_buffers
这个对读和写都有很明显的性能影响。使用最少256MB的大小可以得到很大部分的性能提升。 - checkpoint_segments
如果你使用了默认的配置或者其他写操作比例很大的测试配置,你需要把这个调大一点来得到更好的性能结果。至少16。这是一个经验值。
还有很多其他参数可以影响基本的性能,包括effective_cache_size
和work_mem
,但他们对简单的测试配置是没有影响的。
可以参考这样一个配置,它创建了一个数据库集群。假设你已经设置了PGDATA
和PGLOG
来保存集群相关日志和启动相关日志。
initdb
SHARED_BUFFERS="256MB"
WAL_BUFFERS="16MB"
CHECKPOINT_SEGMENTS="16"
echo \# Changes for pgbench testing >> $PGDATA/postgresql.conf
echo shared_buffers=$SHARED_BUFFERS >> $PGDATA/postgresql.conf
echo wal_buffers=$WAL_BUFFERS >> $PGDATA/postgresql.conf
echo checkpoint_segments=$CHECKPOINT_SEGMENTS >> $PGDATA/postgresql.conf
pg_ctl start -l $PGLOG
3. 正确创建pgbench sample数据库
最简单的方法是使用一个小数据库(刚好适合shared_buffers
),然后scale
大于核心数,然后负载只有select:
- 设置
shared_buffers='256MB'
- 创建一个scale为10的数据库(大概160MB大小)
createdb pgbench
pgbench -i -s 10 pgbench
- 基线
这里是一个2job4client跑30秒的示例,适合一个2核的系统:
pgbench -T 30 -j 2 -S -c 4 pgbench
注意clients必须是核心数的整数倍,所以对于-j 2
,我们不能只使用一个client进行测试。
这是一个在多个client上的负载示例:
CORES="2"
CLIENTS="2 4 8 16 32"
for c in $CLIENTS; do
pgbench -T 30 -j $CORES -S -c $c pgbench
done
4. 缓存问题
注意如果你在初始化步骤之后立刻用只有select的负载来跑pgbench,你很大可能用到了warm cache
。这会使得你所有需要的数据都是在内存中的。如果你做些事情来清理pg库和OS的缓存,比如重启,pgbench就会变的慢了。因为它会从表(特别是accounts表)读每一个block到内存中来,这样会导致seeks而不是顺序读。
有缓存性能
无缓存性能 --> 更难系统的比较
--
相关资源:
PostgreSQL Performance Pit Stop: Determining the right pgbench database scale size and the presentation Using and abusing pgbench cover many aspects of getting useful results from pgbench.
你可以使用pgbench-tools来编写大规模负载的脚本,并记录数据库的性能数据。