1.9.?uxbench

1.9.1. 用法
1.9.2. 描述
1.9.3. 选项
1.9.4. 注解

uxbench — 在UXDB上运行一个基准测试

1.9.1.?用法

uxbench -i [option...] [dbname]

uxbench [option...] [dbname]

1.9.2.?描述

uxbench是一种在UXDB上运行基准测试的简单程序。它可能在并发的数据库会话中一遍一遍地运行相同序列的SQL命令,并且计算平均事务率(每秒的事务数)。默认情况下,uxbench会测试一种基于TPC-B但是要更宽松的场景,其中在每个事务中涉及五个SELECTUPDATE以及INSERT命令。但是,通过编写自己的事务脚本文件很容易用来测试其他情况。

uxbench的典型输出像这样:

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 85.184871 (including connections establishing)
tps = 85.296346 (excluding connections establishing)

前六行报告一些最重要的参数设置。接下来的行报告完成的事务数以及预期的事务数(后者就是客户端数量与每个客户端事务数的乘积),除非运行在完成之前失败,这些值应该是相等的(在-T模式中,只有实际的事务数会被打印出来)。最后两行报告每秒的事务数,分别代表包括和不包括开始数据库会话所花时间的情况。

默认的类型TPC-B事务测试要求预先设置好特定的表。可以使用-i(初始化)选项调用uxbench来创建并且填充这些表(当你在测试一个自定义脚本时,不需要这一步,但要按自定义测试的需要做一些设置工作)。初始化方法如下:

uxbench -i [ other-options ] dbname

dbname是要在其中进行测试的预先创建好的数据库的名称(你可能还需要-h-p-U选项来指定如何连接到数据库服务器)。

注意

uxbench -i会创建四个表uxbench_accountsuxbench_branchesuxbench_history以及uxbench_tellers,如果同名表已经存在会被先删除。如果你已经有同名表,一定注意要使用另一个数据库!

在默认的情况下比例因子为 1,这些表初始包含的行数为:

table                   # of rows
---------------------------------
uxbench_branches        1
uxbench_tellers         10
uxbench_accounts        100000
uxbench_history         0

你可以使用-s(比例因子)选项增加行的数量。-F(填充因子)选项也可以在这里使用。

完成了必要的设置后,就可以用不包括-i的命令运行基准,也就是:

uxbench [ options ] dbname

在近乎所有的情况中,你将需要一些选项来做一次有效的测试。最重要的选项是-c(客户端数量)、 -t(事务数量)、-T(时间限制)以及-f(指定一个自定义脚本文件)。

1.9.3.?选项

下面分成三个部分:数据库初始化期间使用的选项、运行基准测试时使用的选项、两种情况下都有用的选项。

1.9.3.1.?初始化选项

uxbench接受下列命令行初始化参数:

-i
--initialize

要求调用初始化模式。

-F fillfactor
--fillfactor=fillfactor

用给定的填充因子创建表uxbench_accountsuxbench_tellers以及uxbench_branches。默认是100。

-n
--no-vacuum

初始化后不执行清理。

-q
--quiet

把记录切换到安静模式,只是每 5 秒产生一个进度消息。默认的记录会每 100000 行打印一个消息,导致每秒输出很多行消息(特别是硬件设备好的情况下)。

-s scale_factor
--scale=scale_factor

将生成的行数乘以比例因子。例如,-s 100将在uxbench_accounts表中创建 10,000,000 行。默认为 1。当比例为 20,000 或更高时,用来保存账号标识符的列(aid列)将切换到使用更大的整数(bigint),这样才能足以保存账号标识符。

--foreign-keys

在标准的表之间创建外键约束。

--index-tablespace=index_tablespace

在指定的表空间而不是默认表空间中创建索引。

--tablespace=tablespace

在指定的表空间而不是默认表空间中创建表。

--unlogged-tables

把所有的表创建为非日志记录表而不是永久表。

--column-tables

把所有的表创建为列存表。

1.9.3.2.?基准选项

uxbench接受下列命令行基准参数:

-b scriptname[@weight]
--builtin=scriptname[@weight]

把指定的内建脚本加入到要执行的脚本列表中。@之后是一个可选的整数权重,它允许调节抽取该脚本的可能性。如果没有指定,它会被设置为1。可用的内建脚本有:tpcb-likesimple-updateselect-only。这里也接受内建名称无歧义的前缀缩写。如果用上特殊的名字list,将会显示内建脚本的列表并且立刻退出。

-c clients
--client=clients

模拟的客户端数量,也就是并发数据库会话数量。默认为1。

-C
--connect

为每一个事务建立一个新连接,而不是只为每个客户端会话建立一个连接。这对于度量连接开销有用。

-d
--debug

打印调试输出。

-D varname=value
--define=varname=value

定义由自定义脚本使用的变量。允许多个-D选项。

-f filename[@weight]
--file=filename[@weight]

把一个从filename读到的事务脚本加入到被执行的脚本列表中。@后面是一个可选的整数权重,它允许调节抽取该测试的可能性。

-H password
--hidden=password

启动uxbench时在当前目录生成日志文件,文件名为uxbenchxxxxx.log(xxxxx为距离1970年1月1日的秒数)。password为服务器密码。

-j threads
--jobs=threads

uxbench中的工作者线程数量。在多CPU机器上使用多于一个线程会有帮助。客户端会尽可能均匀地分布到可用的线程上。默认为1。

-l
--log

把每一个事务的信息写到日志文件中。

-L limit
--latency-limit=limit

对持续超过limit毫秒的事务进行独立的计数和报告,这些事务被认为是迟到了的事务。

在使用限流措施时(--rate=...),滞后于计划超过limit毫秒并且因此没有希望满足延迟限制的事务根本不会被发送给服务器。这些事务被认为是被跳过的事务,它们会被单独计数并且报告。

-M querymode
--protocol=querymode

要用来提交查询到服务器的协议:

  • simple:使用简单查询协议。

  • extended使用扩展查询协议。

  • prepared:使用带预备语句的扩展查询语句。

默认是简单查询协议。

-n
--no-vacuum

在运行测试前不进行清理。如果你在运行一个不包括标准的表uxbench_accountsuxbench_branchesuxbench_historyuxbench_tellers的自定义测试场景时,这个选项是必需的。

-N
--skip-some-updates

运行内建的简单更新脚本。这是-b simple-update的简写。

-P sec
--progress=sec

sec秒显示进度报告。该报告包括运行了多长时间、从上次报告以来的tps、事务延迟的平均值和标准偏差。如果低于限流值(-R),延迟会相对于事务预定的开始时间(而不是事务实际的开始时间)计算,因此其中也包括了平均调度延迟时间。

-r
--report-latencies

在基准结束后,报告每个命令的每条语句的平均等待时间(从客户端的角度来说是执行时间)。

-R rate
--rate=rate

按照指定的速率执行事务而不是尽可能快地执行(默认行为)。该速率以tps(每秒事务数)形式给定。如果目标速率高于最大可能速率,则该速率限制不会影响结果。

该速率的目标是按照泊松分布的调度时间线开始事务。预计的开始时间表会基于客户端第一次开始的时间(而不是上一个事务结束的时间)前移。这种方法意味着当事务超过它们的原定结束时间时,更迟的事务有机会再次追赶上来。

当限流措施被激活时,运行结束时报告的事务延迟是从预订的开始时间计算而来的,因此它包括每一个事务不得不等待前一个事务结束所花的时间。该等待时间被称作调度延迟时间,并且它的平均值和最大值会被单独报告。关于实际事务开始时间的事务延迟(即在数据库中执行事务所花的时间)可以用报告的延迟减去调度延迟时间计算得到。

如果把--latency-limit--rate一起使用,当一个事务在前一个事务结束时已经超过了延迟限制时,它可能会滞后非常多,因为延迟是从计划的开始时间计算得来。这类事务不会被发送给服务器,而是一起被跳过并且被单独计数。

调度延迟时间较长时表示系统无法用选定的客户端和线程数按照指定的速率处理事务。当平均的事务执行时间超过每个事务之间的调度间隔时,每一个后续事务将会落后更多,并且随着测试运行时间越长,调度延迟时间将持续增加。发生这种情况时,将不得不降低指定的事务速率。

-s scale_factor
--scale=scale_factor

uxbench的输出中报告指定的比例因子。对于内建测试,这并非必需;正确的比例因子将通过对uxbench_branches表中的行计数来检测。不过,当只测试自定义基准(-f选项)时,比例因子将被报告为1。

-S
--select-only

执行内建的select-only脚本。是-b select-only简写形式。

-t transactions
--transactions=transactions

每个客户端运行的事务数量。默认为10。

-T seconds
--time=seconds

运行测试seconds秒,而不是为每个客户端运行固定数量的事务。-t-T是互斥的。

-v
--vacuum-all

在运行测试前清理所有四个标准的表。在没有用-n以及-v时,uxbench将清理uxbench_tellersuxbench_branches表,并且截断uxbench_history

--aggregate-interval=seconds

聚集区间的长度(以秒计)。可以只与-l选项一起使用。通过这个选项,日志会包含每个区间的总结。

--log-prefix=prefix

为由--log创建的日志文件的文件名前缀。默认是uxbench_log

--progress-timestamp

当显示进度(选项-P)时,使用一个时间戳(Unix 时间)取代从运行开始的秒数。单位是秒,在小数点后是毫秒精度。这可以有助于比较多种工具生成的日志。

--sampling-rate=rate

采样率,在写入数据到日志时被用来减少日志产生的数量。如果给出这个选项,只有指定比例的事务被记录。1.0表示所有事务都将被记录,0.05表示只有5%的事务会被记录。

在处理日志文件时,记得要考虑这个采样率。例如,当计算tps值时,你需要相应地乘以这个数字(例如,采样率是0.01,你将只能得到实际TPS的1/100)。

1.9.3.3.?普通选项

uxbench接受下列命令行普通参数:

-h hostname
--host=hostname

数据库服务器的主机名。

-p port
--port=port

数据库服务器的端口号。

-U login
--username=login

要作为哪个用户连接。

-V
--version

打印uxbench版本并退出。

-?
--help

显示有关uxbench命令行参数的信息,并且退出。

1.9.4.?注解

1.9.4.1.?在uxbench中实际执行的事务是什么?

uxbench执行从指定列表中随机选中的测试脚本。它们包括带有-b的内建脚本和带有-f的用户提供的自定义脚本。每一个脚本可以在其后用@指定一个相对权重,这样可以更改该脚本的抽取概率。默认权重是1。权重为0的脚本会被忽略。

默认的内建事务脚本(也会被-b tpcb-like调用)会在每个事务上发出七个从aidtidbidbalance中随机选择的命令。该场景来自于TPC-B基准,但并不是真正的TPC-B,只是名称类似。

  1. BEGIN;

  2. UPDATE uxbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;

  3. SELECT abalance FROM uxbench_accounts WHERE aid = :aid;

  4. UPDATE uxbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;

  5. UPDATE uxbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;

  6. INSERT INTO uxbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);

  7. END;

如果选择simple-update内建脚本(还有-N),第4和5步不会被包括在事务中。这将避免更新那些表中的内容,但是会让该测试用例更符合TPC-B基准。

如果选择select-only内建脚本(还有-S),只会发出SELECT

1.9.4.2.?自定义脚本

uxbench支持通过从一个文件中读取事务脚本替换默认的事务脚本(-f选项)来运行自定义的基准场景。在这种情况中,一个事务就是一个脚本文件的一次执行。

脚本文件包含一个或者多个被分号终结的SQL命令。空行以及以--开始的行会被忽略。脚本文件也可以包含元命令。

注意

需要用分号来分隔连续的SQL命令(如果SQL命令后面跟着一个元命令则不需要一个分号)。

脚本文件有一种简单的变量替换功能。变量名必须由用命令行的-D选项设置,或者按下文所说的使用元命令设置。除了用-D命令行选项预先设置的任何变量之外,还有一些被自动预先设置的变量,如下表所示。一个用-D为这些变量值指定的值会优先于自动的预设值。一旦被设置,可以在SQL命令中写:variablename来插入一个变量的值。当运行多于一个客户端会话时,每一个会话拥有它自己的变量集合。

表?1.1.?自动变量

变量描述
scale 当前的缩放因子
client_id 标识客户端会话的唯一数字(从零开始)

脚本文件元命令开始于一个反斜线(\)并且通常延伸到行的末尾,尽管可以通过写入反斜杠-返回继续附加行。一个元命令和它的参数用空白分隔。支持的元命令如下:

\set varname expression

把变量varname为一个从expression计算得到的值。该表达式可以会包含整数常量、(例如5432)、双精度常量(例如3.14159)对变量:variablename的引用、一元(+、-)或者二元运算符(+、-、*、/、%)(保留它们通常的优先级、结合性和圆括号)。

示例:

\set ntellers 10 * :scale
\set aid (1021 * random(1, 100000 * :scale)) % \
           (100000 * :scale) + 1
\sleep number [ us | ms | s ]

导致脚本执行休眠指定的时间,时间的单位可以是微妙(us)、毫秒(ms)或者秒(s)。如果单位被忽略,则默认值是秒。number要么是一个整数常量,要么是一个引用了具有整数值的变量的:variablename

示例:

\sleep 10 ms
\setshell varname command [ argument ... ]

用给定的argument设置变量varname为shell命令command的结果。该命令必须通过它的标准输出返回一个整数值。

command和每个argument要么是一个文本常量,要么是一个引用了一个变量的:variablename。如果你想要使用以冒号开始的argument,需要在argument的开头写一个额外的冒号。

示例:

\setshell variable_to_be_assigned command literal_argument :variable ::literal_starting_with_colon
\shell command [ argument ... ]

\setshell相同,但是结果被抛弃。

示例:

\shell command literal_argument :variable ::literal_starting_with_colon

1.9.4.3.?内建函数

下表列出的函数被编译在uxbench中,并且可能被用在出现于\set的表达式中。

表?1.2.?uxbench 函数

函数返回类型描述示例返回值
abs(a)a相同绝对值abs(-17)17
debug(a)a相同a打印到stderr,并且返回adebug(5432.1)5432.1
double(i)double转换成doubledouble(5432)5432
greatest(a [, ... ] )如果任喊拿庞蜗菲教ㄗ⒉嵬净个a是double则为double,否则为integer参数中的最大值greatest(5, 4, 3, 2)5
int(x)integer造型成intint(5.4 + 3.8)9
least(a [, ... ] )如果任喊拿庞蜗菲教ㄗ⒉嵬净个a是double则为double,否则是integer参数中的最小值least(5, 4, 3, 2.1)2.1
pi()double常量PI的值pi()3.141592654
random(lb, ub)integer[lb, ub]中均匀分布的随机整数random(1, 10)110之间的一个整数
random_exponential (lb, ub, parameter)integer[lb, ub]中指数分布的随机整数,见下文random_exponential (1, 10, 3.0)110之间的一个整数
random_gaussian (lb, ub, parameter)integer[lb, ub]中高斯分布的随机整数,见下文random_gaussian (1, 10, 2.5)110之间的一个整数
sqrt(x)double平方根sqrt(2.0)1.414213562

random函数使用均匀分布生成值,即所有的值都以相等的概率从指定的范围中抽出。random_exponentialrandom_gaussian以及random_zipfian函数要求一个额外的 double 参数,它决定分布的精确形状。

  • 对于指数分布,parameter通过在parameter处截断一个快速下降的指数分布来控制分布,然后投影到边界之间的整数上。确切地来说,

    f(x)?=?exp(-parameter?*?(x?-?min)?/?(max?-?min?+?1))?/?(1?-?exp(-parameter))

    然后minmax之间(包括两者)的值i会被以概率f(i) - f(i + 1)抽出。

    直观上,parameter越大,接近min的值会被越频繁地访问,并且接近max的值会被越少访问。parameter越接近0,访问分布会越均匀。该分布的近似值是范围中当时被抽取 parameter%次接近min的最频繁的1%值。parameter值必须严格为正。

  • 对于高斯分布,区间被映射到一个在左边-parameter和右边+parameter截断的标准正态分布(经典钟型高斯曲线)。区间中间的值更可能被抽到。准确地说,如果PHI(x)是标准正态分布的累计分布函数,均值mu定义为(max + min) / 2.0,有

    f(x)?=?PHI(2.0?*?parameter?*?(x?-?mu)?/?(max?-?min?+?1))?/
    ???????(2.0?*?PHI(parameter)?-?1)

    minmax(包括两者)之间的值i被抽出的概率是:f(i + 0.5) - f(i - 0.5)。直观上,parameter越大,靠近区间终端的值会被越频繁地抽出,并且靠近上下界两端的值会被更少抽出。大约 67% 的值会被从中间1.0 / parameter的地方抽出,即均值周围0.5 / parameter的地方。并且 95% 的值会被从中间2.0 / parameter的地方抽出,即均值周围1.0 / parameter的地方。例如,如果parameter是 4.0,67% 的值会被从该区间的中间四分之一(1.0 / 4.0)抽出(即从3.0 / 8.05.0 / 8.0)。并且 95% 的值会从该区间的中间一半(2.0 / 4.0)抽出(第二和第三四分位)。为了 Box-Muller 变换的性能,parameter最小为 2.0。

  • 作为一个示例,内建的类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 uxbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
    SELECT abalance FROM uxbench_accounts WHERE aid = :aid;
    UPDATE uxbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
    UPDATE uxbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
    INSERT INTO uxbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
    END;

    这个脚本允许该事务的每一次迭代能够引用不同的、被随机选择的行(这个示例也展示了为什么让每一个客户端会话有自己的变量很重要—否则它们不会独立地接触不同的行)。

1.9.4.4.?为每个事务创建日志

使用-l选项但是不使用--aggregate-interval选项时,uxbench会把每一个事务的信息写入到一个日志文件。该日志文件将被命名为prefix.nnn,其中prefix默认为uxbench_log,而nnnuxbench进程的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)超过了 5ms限制。接下来的两个事务被跳过,因为它们在开始之前就已经迟到了。

在能够处理大量事务的硬件上运行一次长时间的测试时,日志文件可能变得非常大。--sampling-rate选项能被用来只记录事务的一个随机采样。

1.9.4.5.?聚合日志记录

通过--aggregate-interval选项,日志文件会使用一种不同的格式:

interval_start num_of_transactions latency_sum latency_2_sum min_latency max_latency [lag_sum lag_2_sum min_lag max_lag]

其中interval_start是区间的开始(作为一个Unix纪元的时间戳)、num_transactions是该区间中的事务数、sum_latency是该区间中事务时延的总量、sum_latency_2是该区间中事务时延的平方和、min_latency是该区间中的最小时延、max_latency是该区间中的最大时延。接下来的字段sum_lagsum_lag_2min_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

注意

请注意,普通(未聚合)的日志文件显示每个事务使用了哪个脚本,聚合日志不包含索引。因此如果你需要针对每个脚本的数据,你需要自行聚合数据。

1.9.4.6.?语句延迟

通过-r选项,uxbench收集每一个客户端执行的每一个语句花费的事务时间。然后在基准完成后,它会报告这些值的平均值,作为每个语句的延迟。

对于默认脚本,输出看起来会像这样:

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)
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 uxbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
        0.454  SELECT abalance FROM uxbench_accounts WHERE aid = :aid;
        5.528  UPDATE uxbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
        7.335  UPDATE uxbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
        0.371  INSERT INTO uxbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        1.212  END;

如果指定了多个脚本文件,会为每一个脚本文件单独报告平均值。

注意为每个语句的延迟计算收集额外的时间信息会增加一些负荷。这将拖慢平均执行速度并且降低计算出的TPS。降低的总量会很显著地依赖于平台和硬件。对比使用和不适用延迟报告时的平均TPS值是评估时间开销是否明显的最佳方法。

1.9.4.7.?解决办法

使用uxbench产生各种完全没有意义的数据很容易,通过下面的方法可以帮你得到有意义的结论:

首先,永远不要相信任何只运行了几秒的测试。使用-t-T选项让运行持续至少几分钟,这样可以用平均值去掉噪声。在一些情况中,你可能需要数小时来得到能重现的数字。多运行几次测试是一个好主意,这样可以看看数据能否重现。

对于默认的类TPC-B测试场景,初始化的比例因子(-s)应该至少和你想要测试的最大客户端数量一样大(-c),否则你将主要在度量更新争夺。在uxbench_branches表中只有-s行,并且每个事务都想更新其中之一,因此-c值超过-s将毫无疑问地导致大量事务被阻塞,等待其他事务处理。

默认的测试场景对初始化表的耗时非常敏感:表中死亡行和死亡空间的累积会改变结果。要理解结果,必须跟踪更新的总数以及何时发生清理。如果开启了自动清理,它可能会在度量的性能上产生不可预估的改变。

uxbench的一个限制是在尝试测试大量客户端会话时,它自身可能成为瓶颈。这可以通过在数据库服务器之外的一台机器上运行uxbench来缓解,不过必须是具有低网络延迟的机器。甚至可以在多个客户端机器上针对同一个数据库服务器并发地运行多个uxbench实例。

XML 地图 | Sitemap 地图