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

4. 基线
   这里是一个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来编写大规模负载的脚本，并记录数据库的性能数据。

参考：
Regression_Testing_with_pgbench
Pgbenchtesting