将 IBM Informix Innovator-C

将 IBM Informix
Innovator-C 推向极限
英文原文：
http://ibmdatamag.com/2012/05/pushing-ibm-informix-innovator-c-to-its-limits/
基于 TPC-C 的 Linux 压力测试
作者：Eric Vercelletto
发表日期：2012 年 5 月 8 日
眼看巨浪来袭，生还的惟一希望是相信直觉，这样才能安然度过灾难。当处理令人头疼的应
用程序响应时间时，具有数百名终端用户的企业或许会发现自身正处于上文所述的类似境
况。应用程序部署以后随时可能会出现用户不满浪潮，特别是在您对自身的基础架构不自信，
并且部署前没有花时间运行相关压力测试的情况下。
近期的趋势和技术文章 1 表明，如果企业选择关系数据库管理系统 (RDBMS) 但却不了解
RDBMS 如何或者是否能够正常升级，随着用户负载的不断增加问题可能会接踵而至。然
而，许多软件编辑器（包括 Cisco Systems 和 SugarCRM）现已考虑向自身支持的平台
添加 IBM® Informix®，因为其他 RDBMS 编辑器已无法提供足够的性能和稳定性。如今
在技术论坛中，有关将各种 RDBMS 实施项目迁移至 Informix 的相关问题出现得越来越
频繁。
运行 IBM Informix 的企业发现产品升级行之有效，但事实上还有一些用户从未留意过饱受
压力的 Informix 服务器的 CPU 消耗量，近年来也未发布过真实的统计数据。为什么不
呢？是由于竞争对手要“埋没”Informix、缺乏与竞争对手产品的实际性能对比数据，还是
普遍而言的市场冷漠性？答案无关紧要；重要的是要确定基础版本的 IBM Informix 的每个
联机事务处理 (OLTP) 应用程序平均能够承受多少个终端会话。
事务处理性能 (TPC) 委员会负责发布 DBMS 基准评估的规范、场景和结果。该机构会遵
循“尽可能贴近现实生活”的准则，制定不同类型的 DBMS 基准以设置等级。
当前的 TPC 基准包括 TPC-C、TPC-E 和 TPC-H，但 TPC-C 是最具代表性的 OLTP 活
动基准。虽然用户可以在 Internet 上找到大量开源 TPC-C 运行程序，但其中绝大部分均
以 Java 语言编写。下列测试采用的运行程序由西班牙巴利亚多利德大学团队开发、由
Diego Llanos 教授负责管理，用来与 IBM Informix 执行运行对比测试。
测试目标
由于未采用 TPC 委员会颁发的正式 TPC-C 副本且未获 TPC 委员会批准，因此这项测
试不能作为 TPC-C 官方基准。然而，测试过程中严格遵循 TPC-C 基准制定的所有规则。
基本上，这项操作已对 Informix Innovator-C 运行压力测试，以便指出单一 Informix 服务
器上能够同时运行多少个终端会话（即事务监视器中运行的 TPC-C 用户会话）。
预备步骤与选定配置
首先使用源代码启动操作，只需很少成本。以下是基准测试的必要准备步骤：
1)
依据以下规格安装基于 Linux 的服务器（Fedora 14，内核 2.6.35.14 x86_64）：

单插座 Intel 四核 Q9400（四个 2.66 Ghz 处理器）

16 Gb DDR-2 RAM

四个 500 Gb SATA II，7,200 rpm 磁盘驱动器
请注意，上述配置成本低于 900 欧元。
2)
在 Linux 服务器上安装和配置 IBM Informix Innovator-C Edition。
Innovator-C Edition 是免费的，所以没有成本。所选的版本是 11.70 FC4。
3)
采用巴利亚多利德大学推出的 TPC-C 应用程序（最初在 PostgreSQL ESQL/C 开
发）以运行 IBM Informix。这项任务相对轻松，因为根据 Informix 服务器机制调整对
PostgreSQL 进行修改是整个任务的主要修改。此外，最初的数据库创建语句已经过优化，
以便充分利用 RAW 表和预处理语句。同样，这项基准测试不会测量数据库加载语句，因
此加载时间越短越好。
4)
编译和调试应用程序。
5)
优化 Informix。
6)
运行测试，逐渐增加压力直到出现系统性能下降。严格遵循 TPC-C 规则，确保测试
通过。
基准规则
即使是开展非官方测试，也必须遵循以下规则：

不要修改数据库模式。TPC-C 数据库包含九个表，每个表均包含预定义结构、经过
确认的索引和完整性约束。不得修改、添加或删除其中任何元素。

不要修改表的基数。表基数均存在严格的规则限定；例如，一个仓库将托管 100,000
个项目，一个区将包含 3,000 名客户等。

不要修改事务的应用程序代码。TPC-C 采用五个不同的事务，旨在反映典型 OLTP
应用程序的运行状况：新订单、付款、交货、订单状态和库存水平。最后一项指标包含
非索引列的查询数量（不同的）和 WHERE 子句，因此需要施加少许压力放置数据库引
擎。

各事务类均规定了最大允许响应时间。对于各事务类，至少有 90% 的事务必须按
照如下方法执行。如果出现负值，则测试失败。

各项测试均包含等候（或预热）时间和测量时间（性能测量间隔）。等候时间有助
于服务器适应不断增长的负载，这样即可在性能稳定时过渡至测量时间。

检查点间隔没有制定确切的规则，只是规定测量时期内必须至少测试一个检查点。
这在使用 Informix Innovator-C 时根本无关紧要，因为检查点仅会阻止极少量的事务。
本测试采用 15 分钟间隔，现实系统也是采用这一间隔。

磁盘实施也没有任何规则。同一 SATA 控制器上的全部四个 SATA II 7,200 rpm
磁盘全部得到应用，从而尽量准确地平衡各表和索引的位置。

同一台计算机上的所有 Informix Innovator-C 实例共享内存量均限制在 2 Gb。此
项测试完全使用这 2 Gb，同时还要预留 SHMVIRTSIZE 空间，以便执行排序及类似操
作。
如何测量这项压力测试？
这项测试将测量五项不同的典型 OLTP 事务的响应时间。如果各事务类型返回的响应时间
处于可接受范围的比例低于 90%，则测试失败。各事务均会提供最短、最长、平均及第 90
百分位的响应时间，但不会就失败测试提供任何相关细节信息。最终，系统将会以
tpmC-UVA 形式提供测试整体结果，也就是每分钟执行的有效事务数。
运行测试
按照行动计划步骤 6 执行操作，其目的在于确定测试失败的断点位置。该测试通过 50 个
数据仓库启动，每个数据仓库具有 10 个终端，因而共有 500 个用户终端。
第一次运行：以下是原始性能参数：

数据仓库数：50

每个数据仓库的终端数：10

预热时间：30 分钟

测量时间：60 分钟
测试结果：通过 tpmC-UVA：590.208
仔细查看测试结果细节不难看出，还有一些空间可供添加更多数据仓库（虽然“工作台”二
进制文件显示 CPU 使用率已达 100%），但此时还无法解决这个问题。常规 vmstat 输
出的平均时间为 38% 的用户时间，最短时间为 31%，最长时间为 49%。而 I/O 等待的
平均时间为 11%，最长时间为 25%，最短时间为 6%。这与最初的估计时间很接近，但还
存在一些剩余功率，因此将数据仓库的数量增加至 55 个。
第二次运行：此配置得出的结果最佳：

数据仓库数：55

每个数据仓库的终端数：10

预热时间：45 分钟

测量时间：240 分钟
测试结果：通过 tpmC-UVA：610.728
Informix Innovator-C 依然通过了测试，但服务器速度有所减慢。增加 50 个终端的整体收
益只有 20 tpmC，这表明下次运行很可能会失败。此次测试表明，检查点最终会影响 I/O 等
待系统计数器（多达 50% 的等待 I/O），虽然检查点并不阻止 Informix 事务，但等待 I/O
几乎不会对整个系统造成任何影响。
第三次运行：此配置导致 Informix Innovator-C 到达转折点：

数据仓库数：60

每个数据仓库的终端数：10

预热时间：45 分钟

测量时间：60 分钟
测试结果：通过 tpmC-UVA：497.567
此结果在预料之内。该配置已达到 Informix Innovator-C 的能力极限。
结束语
本测试成功实现 55 个数据仓库正常运行，每个数据仓库运行 10 个终端，因此共有 550
个终端会话，这对于在同一客户端托管应用程序和数据库服务器的测试而言足以令人惊叹。
为继续测试 Informix Innovator-C，我们采用了另一种更加高级的客户端-服务器配置，但出
乎意料的是，测试结果相同。尽管数据库服务器系统监控表明 550 个终端的用户 CPU 平
均使用率只有 15% 至 20%，但这项测试检测发现驱动整个基准测试的“工作台”二进制
文件承受不住 550 以上的终端会话的系统负载，这样会致使重要事务产生长时间等待。
此外，系统还会再次检查 SQLTRACE，以确保数据库服务器内的几乎所有查询任务的执行
响应时间均不超过 20 秒。解决这一问题或许会成为该项目下一阶段的主要任务；另外，
用户还可以咨询官方 TPC 委员会了解同一基准。
最后，这些测试表明 IBM Informix Innovator-C Edition 是启动部门级应用程序部署项目的
明智选择，尽管这项基准测试还运用了某些限制规范。虽然本文并未加以核算，但基础架构
成本与 tpmC 数量比率必然极具竞争力，如果将 IBM Informix Innovator-C 的低管理成本
考虑在内则会更高，这种组合在有限的预算内提高了功能和稳定性。虽然这项测试并没有在
大面积基础架构内运用大量 CPU、RAM 和磁盘阵列，但却在单一服务器的入口点级别论
证了 IBM Informix 数据库服务器的功能和可扩展性。如果测试纳入 Informix 弹性网格功
能（Innovator-C Edition 也提供这项功能）将会怎样？这将是未来面临的又一项挑战。
“免费 RDBMS 的重要替代方案”，Eric Vercelletto 著，2011 年 9 月 30 日，
http://en.vercelletto.com/2011/09/30/a-serious-alternative-to-free-rdbms
1
———-
55 个数据仓库（每个数据仓库运行 10 个终端）的详细测试结果
测试结果计数时间：2012-02-23 (19:17:31)，共运用 55 个数据仓库。
开始测量间隔：45.016333 m
结束测量间隔：225.016333 m
计算吞吐量：610.728 tpmC-uva，使用 55 个数据仓库。
共处理 252680 项事务。
新订单事务：
测量时间内完成 109931 项事务（共 130117 项事务）。
比例：43.506%
“出色完成”的事务比例：94.221%
响应时间（最短/平均/最长/第 90 百分位）：0.008 / 3.327 / 107.466 / 2.920
回滚事务比例：0.967%
每个订单的平均项目数：14859.225
远程项目比例：0.001%
思考时间（最短/平均/最长）：0.000 / 12.060 / 120.000
付款事务：
测量时间内完成 109824 项事务（共 130300 项事务）。
比例：43.464%
“出色完成”的事务比例：95.213%
响应时间（最短/平均/最长/第 90 百分位）：0.001 / 2.664 / 107.702 /
远程事务比例：14.105%
C_ID 选择的客户比例：39.337%
思考时间（最短/平均/最长）：0.000 / 12.038 / 120.000
订单状态事务：
测量时间内完成 10963 项事务（共 13012 项事务）。
比例：4.339%
“出色完成”的事务比例：95.457%
响应时间（最短/平均/最长/第 90 百分位）：0.007 / 2.545 / 105.946 /
C_ID 选择的客户端比例：39.770% .
思考时间（最短/平均/最长）：0.000 / 10.096 / 93.000
交付事务：
测量时间内完成 10982 项事务（共 13042 项事务）。
比例：4.346%
“出色完成”的事务比例：96.767%
响应时间（最短/平均/最长/第 90 百分位）：0.000 / 1.114 / 99.241 / 0.080
执行时间 < 80 秒的事务比例：99.727%
最短/平均/最长执行时间：0.023/2.518/101.781
跳过的区数：0
跳过的区比例：0.000%.
思考时间（最短/平均/最长）：0.000 / 5.038 / 47.000
库存查询事务：
测量时间内完成 10980 项事务（共 13025 项事务）。
比例：4.345%
“出色完成”的事务比例：97.304%
响应时间（最短/平均/最长/第 90 百分位）：0.003 / 2.630 / 98.372 / 2.720
思考时间（最短/平均/最长）：0.000 / 5.023 / 47.000
耗时最长的检查点：
开始时间 自测试开始的运行时间（秒） 执行时间（秒）
未执行任何空检查。
>> 测试通过
依据 TPC 委员会方法进行结果分析
TPC 第 5.6.1 条
Response Time Distribution, New Order Transactions：响应时间分布，新订单事务
Number of Transactions：事务数
Response Time(s)：响应时间
Response Time Distribution, New Order Transactions：响应时间分布，新订单事务
Number of Transactions：事务数
Response Time(s)：响应时间
Response Time Distribution, Order Transactions：响应时间分布，订单事务
Number of Transactions：事务数
Response Time(s)：响应时间
Response Time Distribution, Payment Transactions：响应时间分布，付款事务
Number of Transactions：事务数
Response Time(s)：响应时间
Response Time Distribution, Stock Level Transactions：响应时间分布，库存查询事务
Number of Transactions：事务数
Response Time(s)：响应时间
TPC 第 5.6.2 条
Response Time versus Throughput, New-Order Transaction：响应时间与吞吐量，新订单
事务
90th Percentile Response Time (seg)：第 90 百分位的响应时间（段）
TPC 第 5.6.3 条
Frenquency Distribution of Think Times for the New Order Transaction：新订单事务思考
时间频率分布
Think Times Frenquency：思考时间频率
Think Times (seg)：思考时间（段）
TPC 第 5.6.4 条
Throughput of the New Order Transaction versus Elapsed Time：新订单事务与运行时间
吞吐量
Throughput (tpmC-uva)：吞吐量 (tpmC-uva)
Elapsed Time (seg)：运行时间（段）
笔者要感谢巴利亚多利德大学的 Diego R. Llanos 教授，感谢他允许我在此次测试中采用
他的研究成果。