初始化选项

pgbench 接受以下用于初始化的命令行参数：

基准测试选项

pgbench 接受以下用于基准测试的命令行参数：

公共选项

pgbench 接受以下通用命令行参数：

实际执行的“事务”在pgbench中是什么？

pgbench会从指定列表中随机选取测试脚本来执行。 这些脚本既可以是用-b指定的内置脚本，也可以是用-f指定的用户脚本。 每个脚本都可以在其后加上一个以@引出的相对权重，以改变其被选中的概率。 默认权重为1。权重为0的脚本会被忽略。

默认的内置事务脚本（也可通过-b tpcb-like调用）会针对随机选取的aid、 tid、bid和delta在每个事务中发出七条命令。 该场景受 TPC-B 基准启发，但并不是真正的 TPC-B，因此才取了这个名字。

如果选择simple-update内置脚本（也就是-N），事务中将不包含第 4 步和第 5 步。这会避免在这些表上发生更新争用，但也会让该测试场景更不像 TPC-B。

如果选择select-only内置脚本（也就是-S），则只执行SELECT。

自定义脚本

pgbench支持自定义基准测试场景：只需用从文件中读取的事务脚本（-f选项）替换默认事务脚本（见上文）即可。在这种情况下，一个“事务”就表示脚本文件的一次执行。

脚本文件包含一个或多个以分号结束的 SQL 命令。空行以及以--开头的行会被忽略。脚本文件还可以包含“元命令”，它们由pgbench自身解释，详见下文。

脚本文件提供了简单的变量替换功能。变量可以通过前面介绍的命令行-D选项设置，也可以通过下面介绍的元命令设置。除了由-D命令行选项预设的变量外，还有一些自动预设的变量，列于Table 242中。使用-D为这些变量指定的值优先于自动预设值。设置变量后，就可以通过书写:variablename将变量值插入 SQL 命令。在运行多个客户端会话时，每个会话都有自己的一组变量。

脚本文件中的元命令以反斜线（\）开头，通常延伸到行尾，不过也可以通过写反斜线换行继续到后续行。元命令及其参数之间以空白分隔。支持的元命令如下：

内置函数

Table 243中列出的函数都内置于pgbench，可用于\set中的表达式。

random函数使用均匀分布生成值，即指定范围内所有值被抽到的概率相等。random_exponential和random_gaussian函数需要一个额外的 double 参数，用来决定分布的具体形状。

作为一个示例，内置的类 TPC-B 事务的全部定义是：

\set aid random(1, 100000 * :scale)
\set bid random(1, 1 * :scale)
\set tid random(1, 10 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;

该脚本允许事务的每次迭代都引用不同的随机选中行。（这个示例也说明了为什么每个客户端会话都必须拥有自己的变量 — 否则它们就无法彼此独立地访问不同的行。）

逐事务日志记录

使用-l选项时（但未指定--aggregate-interval选项），pgbench会将每个事务的信息写入日志文件。日志文件名为prefix.nnn，其中prefix默认为pgbench_log，nnn是pgbench进程的 PID。可以用--log-prefix选项修改此前缀。如果-j选项为 2 或更大，即存在多个工作线程，则每个工作线程都有自己的日志文件。第一个工作线程的日志文件名与标准单工作线程情况相同。其他工作线程的附加日志文件名为prefix.nnn.mmm，其中mmm是每个工作线程从 1 开始的顺序编号。

日志格式如下：

client_id transaction_no time script_no time_epoch time_us [ schedule_lag ]

其中， client_id 表示运行该事务的客户端会话， transaction_no 记录该会话已运行的事务数， time 是事务经过的总时间，单位为微秒， script_no 标识使用的脚本文件（在通过 -f 或 -b 指定多个脚本时很有用），而 time_epoch/time_us 分别是 Unix 纪元时间戳和以微秒计的偏移量（适合用来生成带小数秒的 ISO 8601 时间戳），表示事务完成的时间。 schedule_lag 字段是事务计划开始时间与实际开始时间之间的差值，单位为微秒。它仅在使用 --rate 选项时出现。如果同时使用 --rate 和 --latency-limit，则被跳过事务的 time 将报告为 skipped。

下面是单个客户端运行时生成的日志文件片段：

0 199 2241 0 1175850568 995598
0 200 2465 0 1175850568 998079
0 201 2513 0 1175850569 608
0 202 2038 0 1175850569 2663

下面是另一个使用 --rate=100 和 --latency-limit=5 的示例（请注意额外的 schedule_lag 列）：

0 81 4621 0 1412881037 912698 3005
0 82 6173 0 1412881037 914578 4304
0 83 skipped 0 1412881037 914578 5217
0 83 skipped 0 1412881037 914578 5099
0 83 4722 0 1412881037 916203 3108
0 84 4142 0 1412881037 918023 2333
0 85 2465 0 1412881037 919759 740

在这个示例中，事务 82 超时了，因为其延迟（6.173 ms）超过了 5 ms 的限制。接下来的两个事务被跳过，因为它们在开始前就已经超时。

在能够处理大量事务的硬件上运行长时间测试时，日志文件可能会变得非常大。可以使用--sampling-rate选项，仅记录事务的随机样本。

聚合日志记录

使用 --aggregate-interval 选项时，日志文件采用另一种格式：

interval_start num_transactions sum_latency sum_latency_2 min_latency max_latency [ sum_lag sum_lag_2 min_lag max_lag [ skipped ] ]

其中， interval_start 是时间区间的开始时间（以 Unix 纪元时间戳表示）， num_transactions 是区间内的事务数， sum_latency 是区间内事务延迟的总和， sum_latency_2 是区间内事务延迟的平方和， min_latency 是区间内的最小延迟，而 max_latency 是区间内的最大延迟。接下来的字段 sum_lag， sum_lag_2， min_lag 和 max_lag 仅在使用 --rate 选项时出现。它们提供各事务等待前一事务完成的时间统计，即各事务计划开始时间与实际开始时间之间的差值。最后一个字段 skipped 仅在还使用 --latency-limit 选项时出现。它记录因开始时间过晚而被跳过的事务数。每个事务都计入其提交时所在的时间区间。

下面是一些输出示例：

1345828501 5601 1542744 483552416 61 2573
1345828503 7884 1979812 565806736 60 1479
1345828505 7208 1979422 567277552 59 1391
1345828507 7685 1980268 569784714 60 1398
1345828509 7073 1979779 573489941 236 1411

请注意，普通（未聚合）日志格式会显示每个事务所使用的脚本，而聚合格式不会。因此，如果需要按脚本区分的数据，就必须自行聚合。

逐语句报告

使用-r选项时，pgbench会收集每个客户端执行的每条语句所经过的事务时间。基准测试完成后，它会报告这些值的平均值，称为每条语句的延迟。

对于默认脚本，输出与下面类似：

starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
latency average = 15.844 ms
latency stddev = 2.715 ms
tps = 618.764555 (including connections establishing)
tps = 622.977698 (excluding connections establishing)
script statistics:
 - statement latencies in milliseconds:
        0.002  \set aid random(1, 100000 * :scale)
        0.005  \set bid random(1, 1 * :scale)
        0.002  \set tid random(1, 10 * :scale)
        0.001  \set delta random(-5000, 5000)
        0.326  BEGIN;
        0.603  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
        0.454  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
        5.528  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
        7.335  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
        0.371  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        1.212  END;

所有数值都是针对每个客户端执行的每条语句计算的，并在基准测试完成后报告。

请注意，收集计算每条语句延迟所需的额外计时信息会增加一些开销。这会降低平均执行速度，使计算出的 TPS 下降。减速程度因平台和硬件而异，差别可能很大。比较启用和未启用延迟报告时的平均 TPS 值，是衡量计时开销是否显著的好方法。

良好实践

很容易用pgbench得出完全没有意义的数字。下面给出一些有助于获得有用结果的准则。

首先，绝不要相信任何只运行了几秒钟的测试。使用-t或-T选项让测试至少持续几分钟，以便平滑掉噪声。在某些情况下，可能需要数小时才能得到可复现的结果。一个好做法是把同一测试运行几次，看看结果是否可复现。

对于默认的类 TPC-B 测试场景，初始化比例因子（-s）应至少与计划测试的最大客户端数（-c）一样大；否则，测到的主要将是更新争用。pgbench_branches表中只有-s行，而每个事务都要更新其中一行，因此-c超过-s时，必然会有大量事务阻塞等待其他事务。

默认测试场景还会对表初始化后的时间长短非常敏感：表中死元组和空闲空间的累积会改变结果。要理解这些结果，必须跟踪更新总数以及何时发生清理。如果启用了自动清理，它可能会给测得的性能带来不可预测的变化。

pgbench的一个局限是：在尝试测试大量客户端会话时，它自己也可能成为瓶颈。可以通过在与数据库服务器不同的机器上运行pgbench来缓解这一点，不过网络延迟必须足够低。甚至可以在多台客户端机器上同时运行多个pgbench实例，对同一台数据库服务器施压。

安全性

如果不可信用户能够访问尚未采用模式的安全使用方式的数据库，就不要在该数据库中运行pgbench。pgbench使用非限定名称，并且不会更改搜索路径。