从pgbench性能测试结果中发现SQL延迟的规律

偶然从网友的这篇博客中发现pgbench的TPC-B测试结果中有一个比较奇怪的地方
http://blog.chinaunix.net/uid-20802110-id-4889543.html
-------------------------------------------
-bash-4.1$ /usr/pgsql-9.4/bin/pgbench -c 800 -t 5 -j 4  -r pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 800
number of threads: 4
number of transactions per client: 5
number of transactions actually processed: 4000/4000
latency average: 0.000 ms
tps = 217.188339 (including connections establishing)
tps = 243.570070 (excluding connections establishing)
statement latencies in milliseconds:
0.007152 \set nbranches 1 * :scale
0.001217 \set ntellers 10 * :scale
0.000891 \set naccounts 100000 * :scale
0.001649 \setrandom aid 1 :naccounts
0.000924 \setrandom bid 1 :nbranches
0.000974 \setrandom tid 1 :ntellers
0.002318 \setrandom delta -5000 5000
43.159543 BEGIN;
67.412356 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
19.172284 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
2483.177474 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;                          -----延迟非常明显，可以从此入手
37.104961 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.466527 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
3.609726 END;
-------------------------------------------

为什么说它奇怪？因为这个大的延迟无疑应该是高并发争用导致的。但是pgbench_tellers中有10条记录，pgbench_branches中只有一条记录，按道理对pgbench_branches的争用比pgbench_tellers还厉害，为什么pgbench_branches反而很快呢？


于是，我在自己的环境中，逐步增加并发数再现了一下这个问题。

并发数为1
除了pgbench_accounts外稍微慢点以外，其它几个表的更新时间差不多。

并发数为4
现在最慢的是pgbench_branches，因为4个并发连接都要争抢它。但是总体的tps比1并发时提高了不少。

并发数为10
现在最慢的还是pgbench_branches，但pgbench_tellers也明显慢了起来。总体的tps和并发数为4时相比有所增加，但不明显。（测试用的环境是VM，分配给VM的CPU是2核)。

并发数为20
点击( 此处 )折叠或打开
现在最慢的变成 pgbench_tellers了， 总体的 tps也开始下降。

并发数为100
pgbench_tellers越发慢的明显了。

并发数为500
不仅对pgbench_tellers的更新慢的离谱，总的tps也下降的非常厉害，还不到峰值时的3分之1。（这也说明了，控制好到达DB的连接数多么重要。）

那么，为什么更新 pgbench_tellers比更新 pgbench_branches还慢呢？稍微想了想，终于明白了。
更新 pgbench_tellers的SQL语句在更新pgbench_branches的SQL语句前面执行，所以 pgbench_tellers已经帮 pgbench_branches挡住了绝大部分的并发。导致实际到达 pgbench_branches的并发数不是500而只有10，所以 pgbench_branches的更新很快。下面验证一下这个假设。

把pgbench的TCP-B测试SQL写到一个脚本里再测
测试结果和之前没有用脚本时一致。

把脚本中的 更新pgbench_branches 的SQL语句移到 更新 pgbench_tellers的SQL语句 的前面再测
现在最慢的SQL变成pgbench_branches的更新了，验证了我的猜测，也算是 真相大白了。但是，从测试结果中还可以发现，先更新 pgbench_branches比后更新pgbench_branches相比， 总体的tps又有一个大幅度的下降，从403降到233。如果反过来考虑这件事，就是， 调整SQL的执行顺序有时候也可以作为一种性能调优的手段。