如何正确地进行pgbench

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_sizework_mem,但他们对简单的测试配置是没有影响的。
    可以参考这样一个配置,它创建了一个数据库集群。假设你已经设置了PGDATAPGLOG来保存集群相关日志和启动相关日志。
 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
  1. 基线
    这里是一个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

你可能感兴趣的:(如何正确地进行pgbench)