Russell M. Clapp
2003 年 10 月 本文展示了在小部分系统上收集到的性能数据，如何用于为已规划的 IDS Enterprise Replicaiton 网络预测可扩展性和系统使用情况。
简介
评估新应用所需要的计算资源通常是一件非常困难的任务，因为规划这些资源的获得及部署必须与应用程序的开发平行进行。这个任务对于使用单一中央服务器的客户/服务器应用已经相当困难，对于有多个服务器的分布式系统，比如企业复制网络（ER），就更困难了。虽然使用凭经验得来的配置规则和/或当前在企业中运行的其他类似应用程序的知识可以对一些较小规模的系统进行评估，但是要规划一个成功的 ER 网络应用程序，则需要一些可以用来对可衡量的需求进行准确预测的性能特征数据。
本文将展示如何使用在少数系统上收集到的性能数据预测所计划的 ER 网络的可扩展性和系统使用率。用一个经过修改的 TPC-C 工作负载作为在 集中的 和 分散的ER 使用模型中的应用程序。本文展示了启用和没有启用 ER 的系统的性能水平，以及将服务器加入到 ER 网络中时资源使用率的变化。最后的结果是对使用这个工作负载时 ER 可以扩展到什么程度的评估，并讨论了如何通过增加更多的计算资源来提高性能。
案例分析
使用经过修改的 TPC-C 应用程序作为工具，我们将给出在一个小规模的系统上收集数据的测试案例的结果，然后用它预测一个 ER 网络的可扩展性。特别是，我们将考察如何利用收集到的数据来规划有大量节点的网络的需求，以达到所希望的性能和可扩展性水平。尽管这里所举出的例子是相当简单的，但我们的目的是帮助您深入了解这个过程，以便可以将其应用到其他更复杂的网络拓扑和使用模型中。下面是对我们测试案例的每一部分的特定细节和要求。
应用程序
我们使用了一个从 TPC-C 基准测试程序 ( www.tpc.org/tpcc/)变化而来的应用程序进行性能测试工作，TPC-C 基准测试程序是一个著名的、用于联机事务处理(OLTP)使用模型的性能基准测试程序。它有几种特性是性能测试所需要的，可以利用这些特性对它进行扩展和分割。但是，为了在 ER 环境下使用这个应用程序，需要在模式级别和应用程序级别上对源代码进行一些修改。
首先，我们需要对模式中的每一个表引入主键。这使表可以通过 ER 复制（在3.9 版的 Informix? Dynamic Server? (IDS)中为 ER 设计了一个增强，它将消除让用户指定主键的需要。相反每一行都将有一个服务器指定的惟一识别符，ER 可以使用这个惟一标识符作为主键）。其次，我们需要增加一些外键约束以保证引用完整性，因为这样更能代表真实世界应用程序架构。主键和外键约束产生了一些隐含索引，这影响了不同事务的性能。只要多创建两个显式索引就可以提供与真正的 TPC-C 基准测试程序模式相等的一组索引。然而，增加的引用完整性约束对性能有显著的影响，所以不应该将测试结果与任何发表的基准测试结果进行比较。
集中和分散模型
在本案例分析中使用的集中模型利用了 ER 的层次路由（HR）功能（在 IDS 7.31.UC4 、9.20.UC2，以及以后的版本中提供）。这里假定有一个大的根服务器带有很多叶子节点，它们通过 ER 向它传送事务。在我们的案例中，数据库在逻辑上分到了很多叶子上，根服务器包含数据库中所有数据的拷贝。这样，事务应用到叶子上，然后复制到根上。这样，根就是这个应用程序的"集中的"服务器。集中模型的反面是分散模型。在 分散模型下，根服务器将事务应用到数据库上，然后再通过 ER 复制到叶子节点。对于这两种模型， 图 1 显示了这种分布式系统的连接情况。
图 1. 简单的集中或分散使用模型的典型节点布置
对于这些简单的集中和分散模型可以有很多种变化，其中包括：
- 使用多个根服务器以得到冗余
- 同时将事务应用到根服务器和叶子服务器上，以得到结合的效果
- 在层次中加入非根服务器，以便在更多的地点（可能是一个区域总部）提供数据库（或子集）的副本。
有关对 HR 功能的更完全的描述请阅读本文的姊妹篇"Deployment Planning for Informix Enterprise Replication" （Informix企业复制的部署计划），该文作者为 Steven Miller，刊登在《 Tech Notes》1999 年第 4 期第 9 卷上。在本文中，我们将让被检查的工作负载和使用模型尽量简单，以便使分析更加直观。然而，可以将这篇文章所描述的技术推广到更复杂的使用模型和网络拓扑上。
业务问题
出于本文的目的，我们需要回答与分布式系统应用程序有关的两个主要问题：
- 对于集中的和分散的服务器模型，根节点服务器分别可以支持多少叶子节点？
- 如何配置这两服务器类型以得到所需要的可扩展性结果，同时使成本尽可地降低并为将来的发展提供空间？
这些是设计和部署支持 ER 的应用程序的人所遇到的典型问题。
测试环境
为了提供有用的性能特征数据，很重要的一点是，我们的测试要在一个合理的程度上耗用每一个硬件子系统，同时不能突出占用某一个子系统。这是必要的，这样：
- 我们的分析就不会被非正常的极端情况或行为所扭曲；
- 在启用像 ER 这样的功能时，我们可以测量并分离所需要的额外资源；
- 我们可以预测当工作负载增加或减少时资源的消耗。
耗尽任何特定的硬件资源都会妨碍我们分离不同功能的需求和做出准确的预测。这是因为这种耗尽会限制性能并限制其他未耗尽资源的使用。正因为这一点，我们的测试需要小心地扩展以避免出现资源耗尽，同时又可以提供对所有硬件资源的"合理程度"的使用。不过应当注意，这种方法意味着在我们的测试中，对于所有测试的工作负载，都没有达到最大吞吐能力。只要任何一种资源都没有被耗尽，那么总是有达到更高水平的吞吐能力的可能性。这是我们在这里进行特性测试所使用的方法与高性能基准测试所使用的方法之间的一个重要区别。
我们的测试的另外一个重要特点是所测量的吞吐水平对于应用程序级的事务和复制的事务是类似的。也就是说，复制的事务的吞吐量与由应用程序提交的事务的吞吐量保持了同样水平。这一点很重要，因为它使我们能够对事务提交周期长于在测试环境中使用的9分钟的工作环境做出预测。如果在我们的测试测量间隔期间达到稳定状态，那么我们就可以放心地延长所要预测的工作负载的时间周期。
事务
在 TPC-C 工作负载中定义了 5 种事务类型：New-Order、Payment、Order-Status、Delivery 和 Stock-Level。New-Order 事务平均在 8 个表中进行 2*k+2 次选择、k+1 次更新和 k+2 次插入，其中 k 是在新订单中的行数，是一个在 5 到 15 之间平均分布的随机数（平均为 10）。Payment 事务小一些，平均有在 4 个表中进行大约 5.3 次选择、3 次更新和 1 次插入。Order-Status 和 Stock-Level 事务是只读的，分别平均在 3 个表中进行 14 次选择和在 3 个表中进行 401 次选择。Delivery 事务在 4 个表中进行 120 次选择、120 次更新和 10 次删除。可以在 TPC-C 规范中找到带有嵌入 SQL 调用的示例 C 代码实现，可以在 TPC Web 站点 www.tpc.org/tpcc/上找到该规范。
标准的 TPC-C 基准测试运行混合的事务，其中 45% 是 New-Order，至少 43% 是 Payment，Order- Status、Delivery 和 Stock-Level 分别至少是 4%。这样，这个混合事务的大约 8% 是只读事务。当报告结果时，TPC-C 仅提供执行混合事务时 New-Order 事务的吞吐能力。结果是以基准测试 C 每分钟执行的事务量(TPM-C)来报告的。
对于我们的测试来说，吞吐能力是以所有类型的事务每分钟执行的事务量来报告的，而不仅仅是 New-Order事务。这样做有几条理由。首先，我们不是运行正式的 TPC-C 基准测试程序（甚至不是它的优化版本），所以我们的结果与在官方 TPC Web 站点上报告的任何结果没有可比性。其次，我们在我们的环境下进行了很多种测试，经常用一种事务类型作为"混合事务"。对于这些测试，我们不得不对 New-Order 以外的其他事务进行统计。所以，在本案例分析中，我们统计了所有测试中执行的所有事务，不管使用的是什么混合事务。不过，我们很小心地用"tPM"而不是"tPM-C"来报吞吐能力。我们还将工作负载称为"经过修改的TPC-C"而不是"tPC-C"。
客户/服务器模型
TPC-C 事务是作为数据库中的存储过程而编写的，它们由 ESQL/C 程序中的客户调用来调用。客户进程通过 TCP 连接与 Informix 后端进程通信。不过，假设硬件资源受到限制的话，我们就在运行 Informix 后端进程的同一个系统上运行客户进程。与由后端进程处理的事务相比，这些客户进程都是非常轻量级的。所以，本文中展示的系统级性能数据主要是由事务处理所决定的。
复制
TPC-C 数据库模式由 9 个表组成。在我们的测试案例中，我们对其中 7 个表上定义了复制。HISTORY 表和 STOCK 表没有复制。HISTORY 表之所以没有复制是因为该表基本是作为 Payment 事务的应用级日志来使用的。同样，它也没有定义主键（或索引）。加上一个主键会严重影响性能，而且没有任何实际的好处。STOCK 表没有复制的原因是：在我们的分区架构下没有必要访问一个远方仓库的库存数据。
除了 ITEM 表（在这个基准测试中，该表具有静态大小并且是只读的）之外，复制都是用 WHERE 子句定义的，这些子句覆盖了表的 4 仓库（warehouse）分区。对于我们的应用来说，没有必要对 ITEM 表进行复制。但是它的存在对性能没有影响，因为该表是只读的。使用这种方法，每一个叶子服务器都有效地拥有自己的一组复制，覆盖了数据库的 4 个仓库子集。这也意味着，每一个复制（除了在 ITEM 上定义的那个以外）都只有两个参与者：根服务器和一个叶子服务器。
扩展
在我们的测试中，TPC-C Warehouse (W)被用来作为扩展和分区的单位。通常，叶子节点配置 4 仓库，而根节点配置 4*L 个仓库，其中 L 是叶子节点的数量。虽然您可以想像这样一种业务模型，其中每个"仓库"都有自己的叶子服务器。但为了方便，TPC-C 基准测试使用"仓库"进行扩展，并且一个叶子服务器使用多个仓库来表示数据库的合理分区。
同时，ONCONFIG 的参数 BUFFER被固定为每 4 个仓库 15000。这样，内存中缓冲高速缓存就与整个数据库的大小同时扩展。例如，一个系统有一个根节点和 8 个叶子节点，在每个叶子节点上 W=4 和 BUFFERS=15000，因此在根节点上就是 W=32 和 BUFFERS=120000。在我们的测试中，这种 BUFFERS 和数据库大小之间的固定比例使得缓存未命中率相当恒定，并且使得数据库磁盘的使用率与吞吐能力几乎成线性关系。在根据我们的测试进行预测时这种关系是要考虑的一个重要的因素。
硬件资源
为了得到在本文中描述的结果，我们仅仅使用了两个系统，它们都是 Sun Ultra 60 双处理器工作站。每个系统都有两个 360MHz Ultra-SPARC II 的处理器，每个处理器都带有 4MB 外部处理器缓存。每个系统都有 1.5GB 的内存，以及 18 个 7200RPM、4.5G 的硬盘驱动器，平均地分布在 3 条 UltraSCSI 总线上。两个系统之间的网络通信是通过标准的共享以太网进行的。
为了模拟一个大的服务器集合，一台机器被用来运行若干个 Informix 数据库服务器。这些服务器在我们的测试中是叶子节点。第二台机器运行根服务器的工作负载。第二台机器使用了两块硬盘作为根数据库空间、物理日志空间和逻辑日志空间，其中逻辑日志单独使用了一个硬盘。其余 12 块硬盘被用来创建多个"条带化的"逻辑卷。每一个逻辑卷由 2GB 的空间组成，该空间被分成跨 12 个硬盘（spindle ）的条带（ striped），每个条带 32KB。条带化的卷为在不分割表的情况下将 TPC-C 数据库的 I/O 操作均匀地分布到多个硬盘上提供了简便的方法。
在节点的数目增加时，为了获得合理的叶子性能，硬盘资源被静态地分割到 8 个叶子服务器区。每个服务器指定了一个硬盘专门用作根数据库空间、物理日志空间和逻辑日志空间。这是足够的，因为以前的测试证明，在根数据库空间或物理日志空间中的操作非常少。12 块硬盘中剩下的 8 块用于 TPC-C 表，每个服务器一个。
即使在分割硬盘资源的情况下，随着在一个单独的系统上运行更多的服务器，每个服务器的性能都有所下降。这是由于处理器资源、系统内存总线、PCI I/O总线等的争用造成的。下面介绍在进行预测时如何克服这种扩展限制。
结果和分析
在这一部分，我们对集中和分散两种复制模型的测试结果进行分析。在对结果进行了分析并对所配置的系统的可扩展性进行预测之后，我们将看一看如何修改硬件配置以达到一定的性能和可扩展性目标。我们还将探讨用这种方法来预测资源需求的某些限制。
集中模型的测试结果
图 2. 在集中的使用模型中，加入叶子节点时预测的资源利用情况
图 2显示了在集中复制模型中，加入叶子节点时根节点的资源消耗情况。X 轴代表叶子节点的数量，Y 轴表示的是在根服务器上每种主要的可用资源的使用率百分比（网卡和以太网的实际使用率是未知的。但测量到的总体包传送率表明这些资源没有使用得很多）。每条曲线上的 5 个符号代表实际的测量值。曲线本身是"趋势线"，是通过使用线性的或二次多项式的方程与测量的点进行拟合得到的。图中的虚线表示的是，对于按上面的描述配置的服务器，在主要资源--在这里是处理器--接近耗尽的情况下，预期能够支持 17 个叶子节点。
有效的叶子节点
图 2展示了用于实际测量的符号。注意，这些点与叶子数量的整数值不一致。这是因为测试是在载有所有叶子服务器的一台计算机上进行的。因为这些服务器必须共享资源，所以当叶子节点增加时它们的整体吞吐量不是线性增长。采取了减少上面所描述的硬盘分区所造成的性能下降的措施，但是其影响不能被完全排除。所以 图 2的 X 轴上表示的是"有效的"的叶子服务器的数量。这个数是通过将在一个特定的测试中所有叶子节点的总吞吐量除以叶子服务器的数量 L、再乘以一个为叶子节点测量的吞吐量而确定的。应该注意，这个方法在某种程度上是不准确的，它会给出保守的预测。由于假设在叶子节点增加时可以得到理想的吞吐能力，我们应该不会高估根服务器支持的叶子节点的数量。
曲线拟合
图 2中的预测是通过让曲线与测量的数据拟合做出的。尽管看起来这是一项复杂而费时的任务，但实际是非常简单的--只要您可以使用一些合适的 PC/工作站工具即可。我们使用 Microsoft Excel 来准备图表和进行曲线拟合。我们简单地使用线性的或二次多项式来拟合我们的点并进行预测。总之，我们使用了最适合我们的点的曲线，并且做出了看起来很直观的预测。在大多数情况下，我们放弃预示资源消耗量减少的曲线，因为我们对测量值的解释是不会符合这种情况的。虽然这种预测方法可能似乎有点像"变魔术"，但将若干种不同类型的曲线与可用的测量值拟合使得预测在系统规模扩展时资源的消耗如何变化相当容易。
预测可扩展性
再一次注意这一点是很重要的，即在 图 2中的预测是针对当前这种系统配置的。如果根服务器是另一种带有更多的处理器和更少的内存的计算机，那么扩展的限制将会由耗尽的内存所决定，它将只能支持较少的叶子节点。我们将在下面的"预测资源需求"一节中讨论使用 图 2中的数据来为其他的系统配置做预测的方法。
同时也要注意，这些预测都是假设当叶子节点增加时，系统行为方面没有激烈的变化。这对于我们的预测所关注的性能范围是成立的。对于测量的点，保持 BUFFERS 的数量与仓库（W）的数量有一个固定的关系使得缓冲高速缓存的未命中率保持相对恒定。对数据库硬盘（spindle）的 I/O 操作的增加几乎与吞吐量的增加成线性关系，而与缓存未命中率增加没有关系。所以，当我们继续扩展 W 和 BUFFERS 时，内存使用和数据库 I/O 的使用都将随着图 2 的曲线变化。对于数据库的大小和缓冲高速缓存的大小都没有扩展的系统，在增加叶子服务器时，曲线可能会表现出数据库 I/O 操作的非线性增加。同时，对锁和锁定等待（在我们的图中没有显示）也必须充分注意，以观察当增加更多的服务器时，是否有互斥性需求引起的瓶颈。简而言之， 图 2中显示的曲线高度依赖于增加节点时测试配置的扩展方式，不同的方式会导致不同的结果。
分散模型的测试结果
图 3与 图 2类似，都是表示在分布式系统中增加叶子服务器时预测的主要资源的使用率以及整体吞吐能力的增加。但是在这里，工作负载代表了一种分散的模型，在这种模型下事务被应用到根服务器上，然后使用 HR 传播到相应的叶子服务器上。同时， 图 3描述了资源使用率如何随着吞吐量、而不是 X 轴上的叶子服务器的数量的增加而增加。因为吞吐量并不是完全随着为处理到达叶子节点的事务而增加的工作负载流而增加的，所以绘制相对于吞吐量的资源消耗图提供了关于根服务器使用限度的更好图景。这也简化了曲线拟合过程。这里我们预计在超过 3500TPM（每分钟执行的事务）时处理器接近饱和。
图 3. 在分散的使用模型中当叶子节点增加时资源使用率的预测
虽然整个系统的吞吐量不完全随着流的大小和数量的增加而扩展，但 图 3确实显示了性能的增加和支持更多叶子节点的能力。我们需要确定的是在根服务器的某种资源耗尽之前可以支持的叶子节点的数量。我们通过预测根服务器相对于叶子节点数量的吞吐量做到这一点。回想一下对于我们的测试环境来说，叶子节点的数量也意味着数据库的大小，BUFFERS 的数量和事务流的数量等于叶子数量。在这一方面，我们是使用获得的测量数据,预测系统相对所有这些变量的吞吐量。这个预测使用了 图 4中所示的一个对数函数。根据 图 4在大约 15 个叶子时可得到最大吞吐量。
图 4. 预测根服务器相对于分布式系统大小的事务吞吐量
很明显， 图 4表明在超过 8 个叶子节点的情况下扩展的效用非常有限。在真实世界中，系统的设计者必须决定这个水平的吞吐量是不是足够。另外一方面，在真实世界中可能有一些扩展的经济性问题是我们的测试方法把握不了的。例如，如果数据库的规模不随着节点的增加而增加，那么就有可能使用更多的可用内存并且实现更低的缓冲高速缓存未命中率，这样就在曲线的所有点上减少了 I/O 率并提高了性能。同时，在一个拥有更多处理器和更多内存带宽、而这些资源没有被充分使用的系统中，有可能更有效地进行扩展。在下一节，我们将讨论使用来自我们"合成"测试的数据来尝试扩展系统以达到预测的目的。
预测资源需求
在这一节，我们将使用上面描述的性能数据来估量一个分布式的系统。这个系统将被设计为支持集中和分散这两种模型，使用类似于 图 1中的系统配置。让我们假定有一个在主要城市社区的连锁商店，每一个商店都有自己的存货"仓库"。在正常的营业期间，这些商店对其数据库运行 TPC-C，如 order-entry 事务。并且每一个商店都将它们的事务复制到作为它们企业总部的中心站点。在营业结束后，事务被送到中心站点的数据库中，并被复制到零售商店。这些事务代表的是库存商品的补充和配平、定单的撤回，等等。为了简单，让我们假设这个事务流也以 TPC-C 混合事务的形式出现。这样，我们就有了一个分布式系统，它某些时候使用集中模型，在另外一些时候使用分散模型。同样，这个系统也代表一个"工作流"系统的类型。
让我们进一步假定我们的虚构企业有 12 个零售商店。每一个商店都有一个数据库，其大小等于 4 个 TPC-C 仓库，并且每一个商店的事务要求为 900TPM。对于分散阶段，事务在小于 2 小时内以 3500TPM 的速率被批量地加到根节点上。该系统的配置要求如下：
- 为了允许进一步的扩展，在集中阶段，所有的节点都必须不能使用超过 50% 的资源；
- 在分散阶段，80% 的资源使用率是允许的，如果对于将来的扩展必要的话，可以提供长于 2 小时的时间窗口。
集中阶段：叶子服务器的配置
有了这些性能需求和我们拥有的数据，我们就可以设计一个满足企业需要的系统。首先，让我们来考虑集中阶段的情况。 图 5显示了在我们的测试环境的叶子服务器配置下的吞吐量和资源消耗。这种配置仅仅提供了所需要的吞吐量的一半，但资源消耗大大低于目标（数据库硬盘资源除外）。这个测试是使用单个事务流进行的。假设我们的零售店有多个事务流，代表多个同时发生的订货和查询，我们可以考虑进行并行处理，以达到 900 TPM 的要求。
在这种吞吐量的水平上，假设缓冲高速缓存的未命中率保持恒定的话，我们可以将所有资源消耗的值增加大约一倍。这是一种合理的假设，因为数据库的规模并不随着我们扩展吞吐量而增长。甚至加倍以后，我们还是有富余的处理器、内存和日志磁盘资源能力。我们的网络的包传输率大约是 50 包/秒（图中没有显示），这也不用担心。我们需要做的是增加数据库磁盘资源和对其他资源做必要的减少。
图 5. 用于向外复制的单个叶子服务器的吞吐量和资源消耗
处理器资源：叶子服务器
如果我们将系统从双处理器系统转换为具有同样内核速度、外部处理器缓存和存储器结构的单处理器系统，我们可以预期处理器的使用率在目标吞吐率下达到 40%。还可以使用具有稍做修改的存储器结构和可能更低的处理器内核速度的更低一些的系统，但是这些计算通常是错误的，除非可以得到有关硬件的性能特性的更详细的资料。而且，尽管可以测量外部处理器缓存的未命中率和缓存未命中的延迟以判断是否可以接受比较小的缓存，但是这种程度的细节分析超出了这个简单练习的范围。我们将使用同样配置的单处理器，因为 40% 的使用率已经相当接近我们的目标。
存储器资源：叶子服务器
对于内存消耗，我们显然可以从所提供的 1.5GB 减少一些配置并仍然可以满足我们的要求。但是，我们必须确定当事务的吞吐量加倍的时候如何扩展这 13% 的存储器使用率。在 图 3中我们可以看到，随着流的增加（和 BUFFERS 的增加），内存的增长开始时是温和的，然后增长得更快了。在接近我们的 900TPM 要求的曲线范围内，在 TPM 加倍的时候，存储器的增长是 20%。特别是，在这些点之间，存储器的增长是 32MB，其中 30MB 被消耗在 BUFFERS 的增加上。所以我们可以得出结论，对于这种吞吐量的范围，在我们将事务处理速度扩展到 900TPM 的时候，存储器需求不会明显地增长。1.5GB 的 13% 大约是 200MB，我们可以为叶子服务器配置大约 400MB 的内存，这可以满足使用率的要求。假如随着时间推移内存尺度加大，那么我们可以为系统配置 512MB 的内存。
日志设备：叶子服务器
要考虑的下一个资源是日志设备。在这里我们看到了它在 450TPM 下的非常低的使用率，而我们预计它的使用率随吞吐量线性增长。为了保持这种低的使用率，并且可以以较低的延迟对它进行写操作，我们就像在测试情况下所做的那样来配置叶子服务器，将一个硬盘用来做物理的和逻辑的日志，同时也作为根数据库空间（dbspace）。
数据库硬盘：叶子服务器
我们需要增加的惟一资源是数据库的硬盘（spindle）。假定当我们扩展吞吐量时，缓冲高速缓存的未命中率保持恒定，我们需要的磁盘 I/O 能力至少是测试情况的 320%，以便达到我们的性能目标。我们可以假设，在每块磁盘的使用率低于 50%（这是我们的目标）时，磁盘的访问延迟足够低，可以满足我们的整体 TPM 要求。这是肯定的，因为使用率在 50% 时磁盘访问延迟将会小于在测试时使用率为 80% 时的延迟。如果我们为叶子服务器配置了 4 块硬盘用于存放数据库的表，那么在 900TPM 时每一块都将有 40% 的使用率。在使用条带卷或表碎片的情况下，我们可以确保均匀的使用率。
小结：叶子服务器集中阶段
总之，使用带有 360MHz Ultra-SPARC II 处理器、4MB 的外部处理器缓存、512MB 内存和 5 块（4 块用于数据库，1 块用于日志）至少 7200 RPM 的硬盘的单处理器 Ultra 60 级别的机器，在集中阶段我们可以满足叶子服务器性能目标。在我们的分析中硬盘的容量不是问题。如果需要额外的硬盘容量，则硬盘的使用率将会进一步减少。I/O 带宽消耗是这样的，即所有的硬盘都可以被连接在同一条 UltraSCSI 总线上。为了处理日志转换和档案以及实现数据库磁盘镜像或 RAID-5 卷（如果希望的话），可能会要求额外的硬盘。这些配置需求都超出了本性能分析的范围。但为了管理、可靠性或可用性的目的 增加资源应该不会对性能造成负面影响。接下来让我们把注意力转到根服务器的配置上。
集中阶段：根服务器的配置
如上所述，根服务器的配置目标是，当任何叶子节点运行在 900TPM 时，每一种资源的使用率都不能超过 50%。我们可以根据在 图 2中所做的预测来扩展所要求的资源。 图 2显示了在 Ultra 60 服务器上相对"有效的"叶子节点的资源消耗情况，其中每一个有效叶子执行与单叶子情况下同样的 TPM。在测试案例中，单独的叶子节点以 451 TPM 运行。因为我们对 12 个叶子节点中的每一个的要求都是 900TPM，所以在 图 2的修改版 图 6中，我们可以简单地将资源消耗值用于 24 个有效的叶子节点。这种方法隐含地假定，进来的复制事务在根节点上引起的资源消耗仅仅取决于事务，而不取决于为支持所有的叶子节点所需要的连接。就像本文没有介绍的其他测试中所表明的一样，这一点并不是完全对的。但这是一个较小的错误来源，会导致我们对资源的稍微过度配置，因为我们仅仅需要 12 个而不是 24 叶子节点。
图 6. 对支持 24 个有效叶子节点(451 TPM)的根服务器资源消耗的预测
使用 图 6作为向导，我们看到，需要比测试机器上所配置的更多的处理器和内存资源。我们也可以看到，日志磁盘资源使用率超过了 50%，但这个预测可能过分悲观。我们将在下面对此进行讨论。对于数据库磁盘来说，我们可能可以减少数量，但仍然可以达到 50% 的使用率的目标。
处理器资源：根服务器
在如 图 6那样有 24 个有效叶子节点的情况下，处理器资源使用率大约是 145%。为了达到 50%的使用率，我们需要将处理器的数量增加到大约 6 个，并使用与前面所描述的同样的内核速度和外部缓存配置。当我们开始将处理器的数量增加到一个相当的程度的时候，有可能每一个处理器的效率都会变得稍微有些低。这是由处理处理器缓存的未命中时增加的延迟造成的。而这个缓存未命中要么是由于锁变量的争用，要么是由于因更高带宽的消耗引起的存储器延迟的增加造成的。因为有对带有 20 以上处理器的系统的基准测试结果，我们可以假定锁的争用不是问题。我们也可以假定，缓存未命中造成的延迟不会显著增加，因为上支持多处理器的系统上的可用带宽一般都比较大。在这种情况下，假定使用的是 Sun Enterprise 3500。所以，我们可以利用这样的事实，即要么我们将达到 50%使用率的目标，要么这个特殊的 6 处理器的系统可以接纳 8 个处理器，作为一种相对于效率低的扩展的一种"保险策略"。
内存资源：根服务器
图 6向我们显示，对于 24 个有效叶子节点来说，1.5GB 存储器的消耗大约是 125%，或者说是 1920MB。通过为服务器配置 4GB 的存储器可以容易地达到 50% 使用率的目标，但也可以使用更少的存储器。回想一下，我们的测试方法为每个叶子节点增加了 15000 BUFFERS，并且为每个叶子节点的数据库增加了 4 个仓库。因为我们的预测使用 24 个有效的叶子节点而不是 12 个叶子节点，能力是原来的 2 倍，所以如果我们使用 4GB 的存储器，肯定是过度配置了。相反，我们将 1920MB 的数量减去 12*15000 BUFFERS （大约是 360MB）。这就使得存储器的需求大约是 1560MB，或者使用大约 3GB 存储器就可以达到 50% 的使用率的目标。
日志设备：根服务器
图 6显示，在我们所希望的根服务器的吞吐量水平，日志设备的使用率大约是 90%。这个预测是基于一条非线性的曲线做出的。这意味着，某些少量的日志写操作将随着吞吐量的增加而结合起来。虽然这通常是缓冲日志的优点，在高吞吐速率的时候它也会在非缓冲日志的情况下出现。对于高日志使用率来说，可能有比我们的预测显示的更多的日志写操作的结合发生，但是必须做更多的测试才能完全描绘这种行为。在没有这些测试结果的情况下，让我们假定在这个练习里我们的预测是准确的。因此，90% 的使用率没有达到我们的 50%的目标。
为了达到目标，我们首先必须考虑使用缓冲日志。这可以主动地使日志写操作结合起来，这样可以显著降低日志设备的使用率。但是，通过缓冲日志来提交一个事务而没有日志写操作的发生是可能的。如果系统崩溃时日志记录仍然在存储器的缓存中，事务就会丢失。这对于应用有明显的影响，同时也会影响 ER，因为对内部表的更新可能会丢失，在系统崩溃后无法进行完美的恢复。很明显，应用程序的设计者必须在选择缓冲日志之前就这个后果和性能需求之间进行权衡。
出于这个案例分析的目的，我们要注意当在我们建议的配置下日志接近饱和的时候，资源仍然能够提供我们需要的东西以达到我们的性能目标。不过，这是一个需要在最终部署之前通过更多的测试进一步分析的领域。
数据库的硬盘：根服务器
与日志设备使用率预测相对照，所期望的数据库硬盘（spindle）的使用率是相当低的，大约是 30%。很明显，对于我们所期望的工作负载，一个 12 路的条带卷是完全足够了。这里的主要原因是在应用端服务器上， ER 传递的事务的数据库 I/O 需求减少了。这主要是由没有为我们的应用程序复制 STOCK 表这个事实造成的。然而，就像在其他的情况下所看到的，一个通过 ER 传递的事务被有效地减少到进行必要的表修改所要求的行访问。换句话说，除去了一个典型事务的只读部分，该事务做一些查询来确定哪些行需要修改和它们的新值是什么。通过 ER 进行的事务处理的这种优化减少了应用端对 BUFFERS 的使用，因而减少了缓冲高速缓存的未命中率，并最终减少了 I/O 操作的数量。
虽然这种减少 I/O 数量的行为很普通，但不会总是出现，这取决于事务的类型。例如，使用 ER 时，删除事务会导致向内部表写入内容，因此，在这种情况下 I/O 率增加了。然而，我们采用 TPC-C 混合事务的测量会捕获到这些效果，因此我们的预测应能指出这种工作负载的后果。
对于我们所提出的根服务器，可以将逻辑卷中数据库硬盘的数量从 12 减少到 8，同时每个磁盘的使用率保持在 50% 以下。这种使用率不足以影响磁盘反应时间，因而不会对我们的吞吐量预测造成任何重大影响。但如上所述，为了执行镜像和/或记录归档等操作，可能需要在系统上再安装一些硬盘。
摘要：根服务器集中阶段
在日志设备可能发生异常的情况下，我们可以规划使用 Sun Enterprise 3500 系统来满足根服务器的性能需要，该系统包含 6 个 360MHz 的 Ultra-SPARC II 处理器，每个处理器具有 4MB 的外部处理器高速缓存，至少 9 个（8 个用于数据库，1 个用于日志）最低转速为 7200 RPM 的磁盘。如上所述，添加一些磁盘来条带化日志设备，或者至少添加额外的磁盘用于日志归档，这样做也许是必要的。也可能存在如下要求：添加磁盘以允许镜像，或实现 RAID-5 方案以增加可靠性。这里规划的需求是满足上述性能目标的最低需求。
分散阶段配置
现在我们已经确定了最低系统需求，它满足工作负载的集中阶段的性能需求，我们可以把注意力转到分散阶段。为简化这个过程，我们将确定为集中阶段建议的系统配置在哪些地方不符合分散阶段的要求，然后在必要的地方做出调整。
节点服务器：分散阶段
给定分散/集中模型（其中企业数据库逻辑地划分到全部的 12 个叶子服务器上），在根服务器上执行的每个事务只会复制到单个叶子上。在分散阶段中，当根服务器上存在 3500 TPM 的性能需求时，每个叶子服务器需要执行大约 290 TPM。上面建议的叶子服务器配置能够容易地处理这样的事务率，利用率低于规定的 80%。这是一个有效的对比，因为我们假设这两个阶段的事务混合都是完全相同的，只要我们假设每个事务所必需的资源是相同的，就可以直接比较这两个阶段的 TPM 速率。而且，正如上面所讨论的，在某个目标节点上应用一个事务的代价，通常比原始事务在源节点上的代价更低廉，所以假设源和应用服务器上的资源需求相同是稳妥的。因此，不需要改变建议的叶子服务器配置来满足分散阶段的需要。
根服务器：分散阶段
当在分散阶段中，在根节点上应用的事务本质上是以批处理模式进行时，我们可以假设能够应用任意数目的并行流来达到希望的吞吐量水平。给定这个假设，我们可以使用 图 3来规划 3500 TPM 的目标吞吐量水平在根服务器上的资源消耗。关于这点，我们看到试验台配置支持这样的性能水平，但是没有提供充足的服务器资源来满足 80% 的利用率需求。然而，我们建议的根服务器配置应该很容易通过 6 个处理器提供足够的 CPU 周期。
除了处理器需求外，我们惟一还需要考虑的另一个方面是数据库磁盘数，其中我们为集中阶段建议的根服务器配置包括磁盘减少（相比于试验台系统而言）。如果我们把数据库磁盘数目从 12 减少到 8，分散阶段将导致每个磁盘超过 80% 的利用率，这与我们的性能需求相冲突。只需向逻辑卷添加一个额外的磁盘，将磁盘利用率降低到 80% 的水平。对于比集中阶段的建议配置高的叶子服务器和根服务器来说，这是惟一的资源要求。
结束语
本文档介绍一个关于在分布式系统中扩展服务器的案例，这个分布式系统设计用于支持一个集中/分散事务复制应用程序。我们的方法使用了基于性能数据的规划，这些性能数据是根据一个小规模试验台再结合一家虚构的企业的高级性能需求收集而来的。虽然这个方法要求做出许多假设和有根据的猜测，但它展示了这样一种方法，即利用有限的信息并使用该信息来合理估计一个"企业复制（Enterprise Replication）"系统的硬件需求。
当然，可能会存在一些无法预料的情形，使得我们规划的性能水平无法实现。例如，我们的分析基本上忽略了网络性能因为预期的低包速率而带来的潜在影响。很长的网络延迟影响已实现的性能并改变资源消耗需求，例如需要更多的内存来将事务排入队列，这种情况是可能发生的。而且，出现互斥瓶颈也是可能的，这会限制性能在服务器内的扩展。在大多数情况下，这样的瓶颈是应用程序相关的。然而，尽管存在这些可能的问题，在设计新的分布式事务复制系统时，尽可能周密地规划资源需求是必要的。为此，本文档中描述的方法提供了一些可供应用的技术。这些规划还提供了性能和利用率指标，您可以在评估和/或诊断已部署的系统时使用它们。
本文档中分析的场景是相当简单的。当然还存在其他许多需要更复杂的分析的应用模型。这里的目标是提供一种解决比较简单的问题的方法，以便我们能够更清楚地展示所使用的方法。对于更复杂的应用需求，可以通过某种适当的方式对上述技术进行扩展。我们以后还会提供类似本文的文档来讨论其他复制模型。
今后的工作
今后，ER 团队打算提供更多的文档，介绍对试验台系统上的 ER 性能的更详细分析。这些文档将考虑其他复制模型，包括所谓的"everything everywhere"，其中系统中的每个节点都有整个数据库的一份拷贝，所有事务都被复制到所有站点上。要研究的其他模型包括更精细的分层模型，其中有些服务器是同时直接与叶子节点和根节点通信的集线器节点。
除了考虑不同的复制模型外，这些文档还将更详细地分析复制系统的行为。例如，我们不仅要阐述服务器在特定的配置中使用了多少内存，而且还要阐述那些内存被用于什么用途。除了对硬件资源利用情况进行更详细的分析外，我们还会更详细地考察 Informix 服务器和"企业复制"行为。这将包括某些事件的发生速率，以及它们与应用程序和应用程序性能的相互关系。
我们的性能描述工作对于产生分析文档和识别有待改进的领域非常有用，同时，它对于提供可在模拟模型开发中使用的基线也是很有必要的。我们的意图是开发这样一个模型，该模型将使我们能够预测大型分布式系统上的 ER 的可伸缩性和性能。性能描述数据使我们能够根据较小规模的配置检验模型的精确性，这些较小的配置可在实验室中建立和测量。
当前正在开发中的模拟模型将允许我们根据对表和索引的访问和修改来指定应用程序行为。该模型然后将根据这些事件使用的资源和它们使用资源的顺序来对事件建模，从而模拟服务器性能。我们还会对互斥需求建模，以便能够识别任何可能的锁定瓶颈。我们还将实现 Infromix 服务器上的 ER 实现事件建模，以便能够确定分布式系统性能和可伸缩性的总体情况。此外，与任何模拟环境一样，这个模拟环境将会生成丰富的统计数据，这些数据将允许我们隔离性能问题。
致谢 |
