【IT168技术文档】
[文章摘要]
  关于主机的性能问题，众说纷纭。尤其IBM出了POWER 5 芯片之后，跟HP和SUN等主机之间更是你来我往争得不亦乐乎。
作为我们使用者而言，到底是听谁的？每个销售或者售前都可以给你一堆对自己有利的资料，甚至说剪切了竞争对手的资料的一部分，这对于客户极具有蛊惑力。对于TPCC等相关资料他们早已经研究得很透彻，客户也难以从TPC官方站点获得对自己有区分度的信息。在这样的背景下，我们决定自己建立一个测试模型并实现，以作为挑选主机的标准。

[关键字]
  主机 性能 选型 测试 标准 TPCC

测试系统设计
  由于主机性能主要决定于 CPU 性能、内存访问速度以及系统总线带宽等。我们在主机测试中需要考虑回避因为存储能力而引起的性能差异，也就是说测试系统将产生尽量少的IO。作为DBA主要和数据库打交道，为此我选择了数据库应用来进行测试。本测试每一轮使用固定的测试数据，通过在client端循环抽取用户名登陆做一系列操作,这些操作将避免向client回送大量数据以减少网络的影响。最后我们将根据系统运行稳定后client统计得出的每秒完成任务数量来评估主机系统性能。

1：数据准备
  从真实系统收取了一个非常典型、高压力的应用在固定时间点数据，保存备份，每次测试前导入数据库。同时我们将用户ID信息倒出成文本文件，这将放置于各client端用户随机抽取用户进行压力测试。

2：应用的数据库特征
  所有对数据库的访问都通过包来进行，我们可以很清楚的知道到应用将执行什么操作，client也避免向数据库服务器发送大量的sql语句，并且在一次数据库请求中可能做出多次处理。在每个client任务中包含了大约20多条SQL(包括DML)。这些SQL的资源消耗有大有小，但DML产生的日志量相对比较小（我们为了尽可能的避免IO的影响）。

3：client 端设计
  Client 端是用C编写的一段访问数据库并发出数据库请求的代码，主要在linux环境下编译运行。Client端程序倚赖于oracle client 使用OCI驱动访问oracle数据库，并有一个数据库配置文件配置数据库连接信息。Client程序可以配置启动的进程数量以及每个进程所需要循环完成的任务数量。每个进程通过在准备好的文本文件中随机抽取一个用户id 并进行一系列的数据库调用，每完成一千次任务就将本次完成时间输出到屏幕或者文件。

4：测试的进行
  为了确保数据库服务器的性能发挥到极致，我们会采用多台client进行测试，并且client 的响应速度良好。具体来说，就是一台一台的client往上加，client上的进程数量也是逐步往上加。基本上我们发现client 机器平均一颗cpu只能支持2个进程，多余2个进程则client负载将升高响应速度反而下降。在确保client响应迅速的前提下我们逐步增加client机器数量。同时观察主机负载和响应速度。当client 机器超过一定数量之后主机响应速度将开始下降。我们将作出一组曲线，最后选取一个主机性能发挥的最高点作为测试结果。

5：测试结果的检查
  我们可以搜集每台client 端输出信息进行统计计算，看单位时间内完成了多少任务。也可以通过在数据库端启动statspack任务搜集统计数据。当然我们倾向于后者，因为一个任务对于数据库来讲我们设定的就是一个大的事务，通过数据库事务数量就可以得到结果。另外在oracle statspack report 中我们可以看到各sql的执行情况，以判定本次测试sql的执行计划是不是有偏差，如果有偏差则需要进行调整而使得所有测试sql执行计划和资源消耗保持一致。


行业借鉴经验
  本测试系统在HP rx5670(4c8G) 、SUN fire 4800(4c8G)、IBM P590(8c16G)、IBM P550(4c8G)、DELL server(2c4G)、DELL server(4c8G)等多种组合环境下进行过测试(这里4c8G表示4颗cpu8G内存)。相关的存储系统由各厂商自行提供或者我们公司拥有的EMC、HDS的各种存储。由于存储的影响很小我们基本忽略各种存储的影响，这个决定也得到了各厂商工程师的确认。

  所有厂商主机的测试实际是跨越在相当长的一段时期，我们都会将已经测试的厂商的数据如实告诉前来进行测试的厂商，并且会给厂商工程师描述我们测试的模型、原理，并最终获得他们对测试的认可。测试完毕我们不仅提供给厂商测试结论，还会提供给厂商原始报告（包括所有sql以及sql的资源消耗）让他们了解测试的公正性。如果厂商不满意可以由他们的工程师自行对系统环境进行调整（如修改数据库参数或者os 内核参数等），当然他们甚至可以提出应用的合理性问题。在某厂商的测试中，他们甚至调动了北京的oracle性能调优专家以及主机专家，对系统进行建议。当然我们必须得确保应用程序在完成这些功能的情况下已经没有再优化的可能，这必须获得厂商的认可。

  在经过大量的反复测试后。总体表现IBM Power5系列表现最好。在4c8G(4颗cpu 8G内存)的情况下IBM每秒能完成大约320个任务,HP大约能完成170个任务。SUN大约能完成180个任务，DELL server大约能完成150个任务。

   附：以上测试结论针对我所列举的机型，大家可以参考这个比例去TPC官方网站http://tpc.org 去搜索各主机厂商各机器的TPCC值，再做一个换算，然后就可考察其他机型的性能指标。我们自己经过了一系列的测试应用和其他线上应用之间的换算，购买后上线系统根据长期统计的指标反应，测试正确的反应了主机系统在真实环境的表现。


应用难点技巧
  应用的难点其实体现在为了测试的目标，需要降低非相关因素对性能的影响。所以我们采取了通过包来实现数据库应用。尽力地避免了网络传输以及使得系统降低IO而避免存储系统带来的影响。

  本系统的难点还在于如何让厂商认可我们的测试，采用了包来实现，任何数据库调用都可以在数据库中直观地看到，并且通过statspack报告分析，也能看到我们完全使用了包里面的代码都不是在client端直接通过sql进行访问。同时厂家的性能专家如果提出应用修改建议，我们也可以立即在包中进行实施（当然事实上包里面代码已经达到最优）。我们采用逐步加压的方式描绘性能曲线最终选择性能峰值的做法也让厂商无懈可击。

  当然，本系统最大的挑战是如何让人相信测试的正确性。包括我作为设计者自身，也是需要实践来证明的。所幸的是经过一年多的反复测试、论证、实践检验，逐步坚定了我的信心。我的测试系统能比TPCC等官方数据更能真实地反映主机系统在我们真实系统中的表现。并且，我根据自己测试得出的数据，可以预估主机系统什么时候需要更换以及需要重新购买什么样的主机。这是这套系统的最重要的价值。