October 18, 2004
如何实施Benchmark测试-你需要怎样的测试
作者:eygle
出处:http://blog.eygle.com
理解Benchmark测试的过程是非常重要的，即使你不需要进行测试.
即使在今天通常也很少有厂商会主动进行标准测试(benchmark),甚至大多数时候,设备厂商会试图躲避测试.因为标准测试的代价实在高昂.
前面我们提到TPC组织是一个非盈利性组织，但是实施该组织的标准测试，得出标准的结果却实在是成本巨大.
我们以存储测试为例,你不仅需要为服务器、HBA、光纤交换机、RAID承担开销，而且还需要承担诸如文件系统、卷管理器等大量软件费用.
有了软硬件是不足够的,你还需要在人员上有良好的配备，你需要一个好的应用分析员来理解标准测试的I/O访问模型及方式(前面我们说过，
你可以构造最优的满足测试的系统，所以很多厂商用来测试的都是超豪华架构);一个优秀的系统管理员;一个Raid大师;此外还得有人来写报告;
你还需要一个项目经理。和TPC组织和第三方认证机构打交道还要花费你大量的时间和精力.而且，完成一个全面的测试本身就不是一件简单
的事，一旦厂商们不得不卷入这个战场，他们就必须全力以赴，以期获得最优的测试结果.
在没有第三方认证机构之前，一度这个测试结果是非常混乱的.
由于各个参加测试的厂商都希望把最好的性能展现出来，所以通常我们看到的公布结果都是以惊人豪华的组建来架构的，比如Oracle和HP公布
的Oracle10g在Linux上的测试指标,目前仍然是最高的TPC-C的最高性能指标.我们看一下这个测试结果:
|
Benchmark Stats |
System Information | ||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||
|
Server Information |
Client Information | ||||||||||||||||||||||||||||
|
|
该测试结果可以在TPC组织的官方网站上获得，你可以在如下链接找到:
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=103120803
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
我们看到该系统以6,541,770美元的造价获得了过百万(1,184,893)的TPC-C值.
服务器配备了64颗1.5GHz的安腾2处理器.
想想这样的指标对我们来说，最终就只能是指标而已，很少有人会构建这样的系统来用户业务生产。而各厂商只会使用最优的系统来获得最好的测试结果.
显然厂商不可能对所有产品都进行标准测试，通常他们会提供换算方式，对于不同机型和产品进行TPC-C换算. 而这些转化指标对我们的意义就又差了一个
层次.
那么对于我们自己的系统，如何构建合适的模型进行有效的测试呢?
我们要谈的就是这个.
在开始之前你可能需要回答以下几个问题:
1.你的测试目的如何?
2.你最关心的是哪些指标?
3.你将如何获得这些指标?
对于不同的用户可能会给出不同的答案，比较普遍的看法可能包含如下内容:
1.测试获得性能指标以满足方案及系统设计需求
2.系统的并发数量、响应时间、性价比等通常是最关心的性能指标
3.获得这些指标的方法将是本文重点讨论的内容.
显然我们无法通过标准的TPC组织定义的标准测试，我们需要自己的方法.
同样的，使用自己的方法也需要统一的标准和严格的规范，使用统一规范得出的测试结果才具有比较意义.
我见到很多人经常感叹无法获得更有效的工具，无法进行更精确的测试.实际上我们说,工具在标准测试里面的地位是次要的,最重要的是:标准.
只要拥有统一的标准，你的结果就具有比较意义，即使这个意义只对你存在.当然，如果大家都能使用同一标准进行自我测试，那么这些结果
也就同样拥有比较意义.TPC也就是这样发展起来的.
所以注意，实际上我们真正需要的是在自定义标准之下的比较意义.
如果系统需要升级扩容，或者出现性能问题，就可以使用测试结果进行比较，发现性能变化或问题所在.
有了这些前提以后，我们下一节就将进入工具选择及模型定义部分.
Posted by eygle at 12:35 PM | Comments (0)
如何安装和使用orabm
作者:eygle
出处:http://blog.eygle.com
1.首先下载orabm包
你可以从以下地址下载:
http://www.linxcel.co.uk/orabm/orabm.tar
也可以从本地下载.
[gqgai@eygle gqgai]$ wget http://www.linxcel.co.uk/orabm/orabm.tar
--17:46:55-- http://www.linxcel.co.uk/orabm/orabm.tar
=> `orabm.tar'
Resolving www.linxcel.co.uk... done.
Connecting to www.linxcel.co.uk[212.227.127.109]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,280,000 [application/x-tar]
100%[========================================================================================>] 1,280,000 26.53K/s ETA 00:00
17:47:43 (26.53 KB/s) - `orabm.tar' saved [1280000/1280000]
|
2.查看相关文件
|
$ tar -xvf *.tar
x orabm, 0 bytes, 0 tape blocks
x orabm/src, 0 bytes, 0 tape blocks
x orabm/src/orabmload.pc, 24200 bytes, 48 tape blocks
x orabm/src/orabm.c, 9346 bytes, 19 tape blocks
x orabm/src/init.ora, 1442 bytes, 3 tape blocks
x orabm/src/BUILD_FROM_SOURCE.txt, 863 bytes, 2 tape blocks
x orabm/install, 0 bytes, 0 tape blocks
x orabm/install/orabm_analyze.sql, 1068 bytes, 3 tape blocks
x orabm/install/orabm_cache.sql, 1116 bytes, 3 tape blocks
x orabm/install/orabm_ind.sql, 1124 bytes, 3 tape blocks
x orabm/install/orabm_query_cache.sql, 497 bytes, 1 tape blocks
x orabm/install/orabm_serverside_stress.sql, 8528 bytes, 17 tape blocks
x orabm/install/orabm_tab.sql, 2321 bytes, 5 tape blocks
x orabm/install/orabm_tab_rm.sql, 197 bytes, 1 tape blocks
x orabm/install/orabm_user.sql, 233 bytes, 1 tape blocks
x orabm/bin, 0 bytes, 0 tape blocks
x orabm/bin/orabm_tps.awk, 182 bytes, 1 tape blocks
x orabm/bin/orabm_tps.sh, 70 bytes, 1 tape blocks
x orabm/bin/solaris, 0 bytes, 0 tape blocks
x orabm/bin/solaris/orabmload, 85940 bytes, 168 tape blocks
x orabm/bin/solaris/orabm, 53140 bytes, 104 tape blocks
x orabm/bin/linux, 0 bytes, 0 tape blocks
x orabm/bin/linux/orabm, 42332 bytes, 83 tape blocks
x orabm/bin/linux/orabmload, 50741 bytes, 100 tape blocks
x orabm/bin/orabm.linuxd2.log, 559 bytes, 2 tape blocks
x orabm/bin/windows, 0 bytes, 0 tape blocks
x orabm/bin/windows/orabm.exe, 196653 bytes, 385 tape blocks
x orabm/bin/windows/orabmload.exe, 233525 bytes, 457 tape blocks
x orabm/orabm.pdf, 239954 bytes, 469 tape blocks
x orabm/orabm.htm, 200488 bytes, 392 tape blocks
x orabm/orabm_files, 0 bytes, 0 tape blocks
x orabm/orabm_files/image001.jpg, 46143 bytes, 91 tape blocks
x orabm/orabm_files/image002.jpg, 8437 bytes, 17 tape blocks
x orabm/orabm_files/_vti_cnf, 0 bytes, 0 tape blocks
x orabm/orabm_files/_vti_cnf/image002.jpg, 724 bytes, 2 tape blocks
x orabm/orabm_files/_vti_cnf/image001.jpg, 725 bytes, 2 tape blocks
x orabm/orabm_files/_vti_cnf/image003.gif, 699 bytes, 2 tape blocks
x orabm/orabm_files/_vti_cnf/editdata.mso, 708 bytes, 2 tape blocks
x orabm/orabm_files/_vti_cnf/filelist.xml, 707 bytes, 2 tape blocks
x orabm/orabm_files/_vti_cnf/header.htm, 1264 bytes, 3 tape blocks
x orabm/orabm_files/_vti_cnf/.fp_folder_info, 58 bytes, 1 tape blocks
x orabm/orabm_files/editdata.mso, 2976 bytes, 6 tape blocks
x orabm/orabm_files/filelist.xml, 289 bytes, 1 tape blocks
x orabm/orabm_files/image003.gif, 14667 bytes, 29 tape blocks
x orabm/orabm_files/header.htm, 4705 bytes, 10 tape blocks
$ ls
orabm orabm.tar
$ cd orabm
$ ls
bin install orabm.htm orabm.pdf orabm_files src
$ ls
bin install orabm.htm orabm.pdf orabm_files src
$ cd install
$ ls
orabm_analyze.sql orabm_ind.sql orabm_serverside_stress.sql orabm_tab_rm.sql
orabm_cache.sql orabm_query_cache.sql orabm_tab.sql orabm_user.sql
|
注意:缺省的orabm测试用用户会建立在tools表空间,如果你想把数据放在其他表空间可以修改orabm_user.sql来调整.
3.安装的步骤如下:
|
# |
Operation |
Command |
|
1 |
create the ORABM user (assumes TOOLS tablespace, TEMP temporary tablespace) |
sqlplus system/pwd @orabm_user |
|
2 |
create the tables |
sqlplus system/pwd @orabm_tab |
|
3 |
load the data |
$ orabmload Warehouses 1 |
|
4 |
create the indexes |
sqlplus system/pwd @orabm_ind |
|
5 |
analyze the tables and indexes |
sqlplus system/pwd @orabm_analyze |
|
6 |
create the stress-test PL/SQL procedures |
sqlplus system/pwd @orabm_serverside_stress |
|
7 |
cache the table and index data in the SGA |
sqlplus system/pwd @orabm_cache |
4.安装日志及如下
|
$ sqlplus "/ as sysdba" @orabm_user
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Sep 25 17:55:40 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
User created.
Grant succeeded.
User altered.
User altered.
Revoke succeeded.
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
$ sqlplus "/ as sysdba" @orabm_tab
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Sep 25 17:55:56 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Table created.
Table created.
Table created.
Table created.
Table created.
Table created.
Table created.
Table created.
Table created.
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
$ cd ..
$ ls
bin install orabm.htm orabm.pdf orabm_files src
$ cd bin
$ ls
linux orabm.linuxd2.log orabm_tps.awk orabm_tps.sh solaris windows
$ cd solaris
$ ls
orabm orabmload
$ ./orabmload Warehouse 1
ld.so.1: ./orabmload: fatal: /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0: wrong ELF class: ELFCLASS64
Killed
$ LD_LIBRARY_PATH=${ORACLE_HOME}/lib32:${LD_LIBRARY_PATH} export LD_LIBRARY_PATH
$ ./orabmload Warehouses 1
Connected to ORACLE as user: ORABM
using timestamp=20040925181524
TPCC Data Load Started...
Loading Item
.................... 20000
.................... 40000
.................... 60000
.................... 80000
.................... 100000
Item Done.
Loading Warehouse
Loading Stock Wid=1
.................... 20000
.................... 40000
.................... 60000
.................... 80000
.................... 100000
Stock Done.
Loading District
Loading Customer for DID=1, WID=1
...Customer Done.
Loading Customer for DID=2, WID=1
...Customer Done.
Loading Customer for DID=3, WID=1
...Customer Done.
Loading Customer for DID=4, WID=1
...Customer Done.
Loading Customer for DID=5, WID=1
...Customer Done.
Loading Customer for DID=6, WID=1
...Customer Done.
Loading Customer for DID=7, WID=1
...Customer Done.
Loading Customer for DID=8, WID=1
...Customer Done.
Loading Customer for DID=9, WID=1
...Customer Done.
Loading Customer for DID=10, WID=1
...Customer Done.
Loading Orders for D=1, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=2, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=3, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=4, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=5, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=6, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=7, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=8, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=9, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=10, W= 1
. 1000
. 2000
. 3000
Orders Done.
...DATA LOADING COMPLETED SUCCESSFULLY.
$ cd ../../install
$ ls
orabm_analyze.sql orabm_ind.sql orabm_serverside_stress.sql orabm_tab_rm.sql
orabm_cache.sql orabm_query_cache.sql orabm_tab.sql orabm_user.sql
$ sqlplus "/ as sysdba" @orabm_ind
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Sep 25 18:31:05 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
DOC> *
DOC> * same indexes as used by Oracle record breaking 32-CPU
DOC> * RAC TPC-C benchmark on Linux - Sept 2002
DOC> *
DOC> * Geoff Ingram (geoff@dbcool.com)
DOC> */
Session altered.
Index created.
Index created.
Index created.
Index created.
Index created.
Index created.
Index created.
Index created.
Index created.
Index created.
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
$ sqlplus "/ as sysdba" @orabm_analyze
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Sep 25 18:32:17 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Session altered.
Table analyzed.
Table analyzed.
Table analyzed.
Table analyzed.
Table analyzed.
Table analyzed.
Table analyzed.
Table analyzed.
Table analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Index analyzed.
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
$ sqlplus "/ as sysdba" @orabm_serverside_stress
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Sep 25 18:35:50 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
DOC> *
DOC> * v2.0
DOC> *
DOC> * Copyright (c) 2002, Geoff Ingram (geoff@dbcool.com) - Proton Technology Ltd
DOC> *
DOC> * orabm_serverside_stress.sql: Oracle package for CPU stress test benchmark
DOC> *
DOC> * You may distribute orabm_serverside_stress.sql under the terms of either the
DOC> * widely available GNU General Public License or the Artistic License
DOC> * with the exception that it cannot be placed on a CD-ROM or similar media
DOC> * for commercial distribution without the prior approval of the author.
DOC> *
DOC> */
Procedure created.
Procedure created.
Procedure created.
Procedure created.
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
$ sqlplus "/ as sysdba" @orabm_cache
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Sep 25 18:36:07 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Table altered.
COUNT(*)
----------
30000
Table altered.
COUNT(*)
----------
10
Table altered.
COUNT(*)
----------
30000
Table altered.
COUNT(*)
----------
299952
Table altered.
COUNT(*)
----------
100000
COUNT(*)
----------
30000
COUNT(*)
----------
30000
COUNT(*)
----------
100000
COUNT(*)
----------
299952
COUNT(*)
----------
30000
COUNT(*)
----------
30000
COUNT(*)
----------
100000
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
|
至此安装完成.
Posted by eygle at 12:35 PM | Comments (0)
使用Bonnie++进行系统IO性能测试
作者:eygle
出处:http://blog.eygle.com
由于Bonnie存在一些众所周知的问题,比如>2G的文件支持.
Russell Coker (russell@coker.com.au) 开发了一套新的代码,用以支持>2G的文件等.
得到Tim Bray (tbray@textuality.com)的许可之后,Russell把他的软件命名为bonnie++,在网上发布,并开始流行起来.
目前的版本已经更新到了1.03a,你可以到以下地址下载:
http://www.coker.com.au/bonnie++/
你也可以点击这里下载,这个版本需要编译,如果你没有编译环境,可以点击这里下载我编译好的,适用于SUN Solaris环境(Solaris8测试通过)
Russell Coker的个人主页是:
http://www.coker.com.au/
Bonnie++ 与 bonnie的区别主要是:
http://www.coker.com.au/bonnie++/diff.html
我简单介绍一下Bonnie++的编译及使用:
1.编译
你需要把以上下载的源码编译以后才能使用,如果你没有编译环境,可以点击这里下载我编译好的,适用于SUN Solaris环境(Solaris8测试通过)
当然你需要安装make,及gcc等必要编译器.在编译过程中,如果遇到以下错误,可能是因为你没有设置正确的环境变量
$ ./configure |
设置环境变量后继续编译,一般可以成功.
|
# export LD_LIBRARY_PATH=/usr/lib:/usr/local/lib |
编译完成之后会生成bonnie++,可以用来测试了.
2.下面是一些测试结果
a.T3大文件读写测试
# ./bonnie++ -d /data1 -u root -s 4096 -m billing
Using uid:0, gid:1.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
billing 4G 9915 87 30319 56 11685 38 9999 99 47326 66 177.6 3
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 639 19 +++++ +++ 1258 22 679 16 +++++ +++ 1197 27
billing,4G,9915,87,30319,56,11685,38,9999,99,47326,66,177.6,3,16,639,19,+++++,+++,1258,22,679,16,+++++,+++,1197,27
|
b. EMC CLARiiON CX500 禁用写Cache的测试数据
这个是在我禁用了写Cache以后的测试数据:
4块盘的Raid1+0测试:
# ./bonnie++ -d /eygle -u root -s 4096 -m jump
Using uid:0, gid:1.
File size should be double RAM for good results, RAM is 4096M.
# ./bonnie++ -d /eygle -u root -s 8192 -m jump
Using uid:0, gid:1.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
jump 8G 12647 36 13414 8 7952 13 33636 97 146503 71 465.7 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 86 1 +++++ +++ 161 1 81 1 +++++ +++ 163 1
jump,8G,12647,36,13414,8,7952,13,33636,97,146503,71,465.7,5,16,86,1,+++++,+++,161,1,81,1,+++++,+++,163,1
|
4块盘的Raid5,禁用写Cache后的速度:
# ./bonnie++ -d /eygle -u root -s 8192 -m jump
Using uid:0, gid:1.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
jump 8G 10956 30 10771 6 3388 5 34169 98 158861 75 431.1 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 81 1 +++++ +++ 160 1 82 1 +++++ +++ 109 1
jump,8G,10956,30,10771,6,3388,5,34169,98,158861,75,431.1,5,16,81,1,+++++,+++,160,1,82,1,+++++,+++,109,1
|
对比这两个结果我们发现(单位K/sec):
|
字符写 |
Block写 |
字符读 |
Block读 | |
| Raid10 |
12,647 |
13,414 |
33,636 |
146,503 |
| Raid5 |
10,956 |
10,771 |
34,169 |
158,861 |
| Diff |
1,691 |
2,643 |
-533 |
-12,358 |
我们看到,在直接读写上,写Raid10会略快于Raid5;而在读取上,Raid5会略快于Raid10,这符合我们通常的观点.
这里需要提一下的是,通常我们建议把RedoLog file存放在Raid10的磁盘上,因其具有写优势.
c.EMC CLARiiON CX500 启用1G写Cache的测试数据
这是4块盘的Raid10的测试数据:
# ./bonnie++ -d /eygle -u root -s 8192 -m jump |
这是4块盘的Raid5的测试数据:
# ./bonnie++ -d /eygle -u root -s 8192 -m jump
Using uid:0, gid:1.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
jump 8G 34620 98 103440 65 35756 61 33900 97 160964 76 495.4 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 788 12 +++++ +++ 1503 14 783 11 +++++ +++ 1520 15
jump,8G,34620,98,103440,65,35756,61,33900,97,160964,76,495.4,6,16,788,12,+++++,+++,1503,14,783,11,+++++,+++,1520,15
|
我们再来对比一下这个结果(单位K/sec):
|
字符写 |
Block写 |
字符读 |
Block读 | |
| Raid10 |
31,447 |
73,130 |
33,607 |
144,470 |
| Raid5 |
34,620 |
103,440 |
33,900 |
160,964 |
| Diff |
-3,173 |
-30,310 |
-293 |
-16,494 |
Raid5在启用了大的Write Cache下,性能全面超过了Raid10
3.对T3和Emc做个对比
都是4块盘的Raid5的情况下:
|
字符写 |
Block写 |
字符读 |
Block读 | |
| T3 |
9,915 |
30,319 |
9,999 |
47,326 |
| EMC |
34,620 |
103,440 |
33,900 |
160,964 |
| Diff |
-24,705 |
-73,120 |
-23,901 |
-113,638 |
| Emc/T3 |
3.49 |
3.41 |
3.39 |
3.40 |
4.对ATA Raid10的测试
开有1G Cache的测试结果:
# ./bonnie++ -d /eygle -u root -s 8192 -m jump
Using uid:0, gid:1.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
jump 8G 34299 97 84734 54 30960 53 33918 97 155474 74 575.0 7
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 786 12 +++++ +++ 1525 13 783 11 +++++ +++ 1508 15
jump,8G,34299,97,84734,54,30960,53,33918,97,155474,74,575.0,7,16,786,12,+++++,+++,1525,13,783,11,+++++,+++,1508,15
|
关闭Cache后的测试数据:
# ./bonnie++ -d /eygle -u root -s 8192 -m jump
Using uid:0, gid:1.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
jump 8G 15587 44 16282 10 6433 10 33863 97 153921 73 538.8 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 99 1 +++++ +++ 161 1 91 1 +++++ +++ 180 1
jump,8G,15587,44,16282,10,6433,10,33863,97,153921,73,538.8,6,16,99,1,+++++,+++,161,1,91,1,+++++,+++,180,1
|
Posted by eygle at 12:35 PM | Comments (1)
使用Bonnie进行系统IO性能测试
作者:eygle
出处:http://blog.eygle.com
Bonnie是一款极小的测试系统IO性能的工具,源代码公开.作者主页:
http://www.textuality.com/bonnie/
你也可以点击这里下载
编译Bonnie极其简单,但是需要你安装了make及gcc (或cc)
# make
Options are "make bsd" and "make SysV" - the default is "bsd".
If you get messages about missing functions, try "make SysV."
make Bonnie
make[1]: Entering directory `/export/home/gqgai/bonnie'
cc -O Bonnie.c -o Bonnie
make[1]: Leaving directory `/export/home/gqgai/bonnie'
|
其使用手册在:
http://www.textuality.com/bonnie/advice.html
测试IO速度:
1.T3阵列速度测试(raid5)
|
# df -k
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s0 1018382 117711 839569 13% /
/dev/dsk/c0t0d0s6 2055705 1177602 816432 60% /usr
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
mnttab 0 0 0 0% /etc/mnttab
/dev/dsk/c0t0d0s1 1448911 772148 618807 56% /var
swap 4770120 8 4770112 1% /var/run
swap 4958928 188816 4770112 4% /tmp
/dev/dsk/c5t1d0s0 51634648 35154404 15963898 69% /data1
/dev/dsk/c5t1d1s1 25816144 21498881 4059102 85% /data3
/dev/dsk/c5t1d1s0 25816144 14650723 10907260 58% /data2
/dev/dsk/c0t2d0s1 15483618 1074317 14254465 8% /temp
/dev/dsk/c0t2d0s0 7136886 2824586 4240932 40% /varlink
/dev/dsk/c0t2d0s5 8258597 5868224 2307788 72% /opt
/dev/dsk/c0t2d0s7 2053605 1281342 710655 65% /export/home
/dev/dsk/c0t2d0s6 2053605 178151 1813846 9% /usr/local
# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0 |
简要介绍一下输出:
这里Sequential Output指写入速度,Char指按字符方式写入,Block指按块方式写入,Rewrite指顺序改写速度(也就是数据修改)
Sequential Input指读取速度
CPU,指该操作占用的CPU资源.
此处T3 Raid5的写入达到 10251 K/sec
2.本地磁盘速度
# ./Bonnie -d /opt/oracle -s 1024 -m billing-center
File '/opt/oracle/Bonnie.8545', size: 1073741824
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker Seeker 2...1...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
billing- 1024 9582 85.0 15928 29.8 6900 20.3 11735 96.5 46098 67.2 256.6 8.8
|
后面会逐渐添加一些其他硬件的测试数据.
3. EMC CLARiiON CX500 测试数据
系统环境:
# /usr/platform/sun4u/sbin/prtdiag -v
System Configuration: Sun Microsystems sun4u Sun Fire 480R
System clock frequency: 150 MHz
Memory size: 4096 Megabytes
========================= CPUs ===============================================
Run E$ CPU CPU
Brd CPU MHz MB Impl. Mask
--- --- --- ---- ------- ----
A 0 1050 8.0 US-III+ 11.0
A 2 1050 8.0 US-III+ 11.0
========================= Memory Configuration ===============================
Logical Logical Logical
MC Bank Bank Bank DIMM Interleave Interleaved
Brd ID num size Status Size Factor with
--- --- ---- ------ ----------- ------ ---------- -----------
A 0 0 512MB no_status 256MB 8-way 0
A 0 1 512MB no_status 256MB 8-way 0
A 0 2 512MB no_status 256MB 8-way 0
A 0 3 512MB no_status 256MB 8-way 0
A 2 0 512MB no_status 256MB 8-way 0
A 2 1 512MB no_status 256MB 8-way 0
A 2 2 512MB no_status 256MB 8-way 0
A 2 3 512MB no_status 256MB 8-way 0
========================= IO Cards =========================
Bus Max
IO Port Bus Freq Bus Dev,
Type ID Side Slot MHz Freq Func State Name Model
---- ---- ---- ---- ---- ---- ---- ----- -------------------------------- ----------------------
PCI 8 B 2 33 33 2,0 ok SUNW,XVR-100 SUNW,375-3126
PCI 8 B 4 33 33 4,0 ok fibre-channel-pci10df,f900.10df.+
PCI 8 B 5 33 33 5,0 ok fibre-channel-pci10df,f900.10df.+
PCI 8 A 0 66 66 1,0 ok pci-pci8086,b154.0/pci108e,1000 PCI-BRIDGE
PCI 8 A 0 66 66 0,0 ok pci108e,1000-pci108e,1000.1 device on pci-bridge
PCI 8 A 0 66 66 0,1 ok SUNW,qfe-pci108e,1001 SUNW,pci-qfe/pci-bridg+
PCI 8 A 0 66 66 1,0 ok pci108e,1000-pci108e,1000.1 device on pci-bridge
PCI 8 A 0 66 66 1,1 ok SUNW,qfe-pci108e,1001 SUNW,pci-qfe/pci-bridg+
PCI 8 A 0 66 66 2,0 ok pci108e,1000-pci108e,1000.1 device on pci-bridge
PCI 8 A 0 66 66 2,1 ok SUNW,qfe-pci108e,1001 SUNW,pci-qfe/pci-bridg+
PCI 8 A 0 66 66 3,0 ok pci108e,1000-pci108e,1000.1 device on pci-bridge
PCI 8 A 0 66 66 3,1 ok SUNW,qfe-pci108e,1001 SUNW,pci-qfe/pci-bridg+
========================= Environmental Status =========================
System Temperatures (Celsius):
-------------------------------
Device Temperature Status
---------------------------------------
CPU0 50 OK
CPU2 52 OK
DBP0 28 OK
=================================
Front Status Panel:
-------------------
Keyswitch position: NORMAL
System LED Status:
LOCATOR FAULT POWER
------- ------- -------
[OFF] [OFF] [ ON]
=================================
Disk Status:
------------
DISK 0: [NO_FAULT]
DISK 1: [NO_FAULT]
=================================
Fan Status:
-----------
Bank RPM Status
---- ----- ------
CPU0 5660 [NO_FAULT]
CPU1 3896 [NO_FAULT]
CPU2 3797 [NO_FAULT]
IO0 3947 [NO_FAULT]
IO1 4166 [NO_FAULT]
=================================
Power Supplies:
---------------
Supply Status
------ ------
PS0 [NO_FAULT]
PS1 [NO_FAULT]
=================================
========================= HW Revisions =======================================
System PROM revisions:
----------------------
OBP 4.10.8 2003/07/25 08:44
IO ASIC revisions:
------------------
Port
Model ID Status Version
-------- ---- ------ -------
Schizo 8 ok 7
Schizo 9 ok 7
|
阵列为CLARiiON CX500,以下分别是4块盘的Raid1+0及Raid5的测试数据:
Raid1+0测试
# ./Bonnie -d /eygle -s 2046 -m jump
File '/eygle/Bonnie.460', size: 2145386496
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker Seeker 2...1...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
jump 2046 37438 88.8 111172 63.8 75940 90.0 43495 99.7 322153 99.9 17747.8 177.5
|
这里EMC CX500的速度达到了,37438K/sec,比T3的性能强了很多
下面是Raid5的测试数据:
# ./Bonnie -d /eygle -s 2046 -m jump
File '/eygle/Bonnie.473', size: 2145386496
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker Seeker 2...1...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
jump 2046 40652 95.5 106768 56.1 75673 90.9 43356 99.4 314381 99.8 17347.3 160.5
|
Raid5这里的字符写速度达到了40652K/sec,较Raid1+0稍快,而Block方式写Raid1+0较Raid5稍快.
实际上EMC一直强调其Raid5读写性能较Raid1+0相差无几.
Posted by eygle at 12:35 PM | Comments (0)
使用orabm进行CPU压力测试...
作者:eygle
出处:http://blog.eygle.com
orabm是一个开源的系统CPU性能测试工具.
作者Geoff Ingram曾经为Oracle工作数年,是High Performance Oracle" (ISBN: 0471224367)一书的作者.
orabm的安装你可以参考:
作者原网页如下:
http://linxcel.co.uk/orabm/orabm.htm
我们接下来看一下怎样使用orabm通过Oracle数据库来测试CPU性能.
1.首先我们先要了解一下orabm的原理使用:
How Orabm Works
Orabm works by running a user-specified number of database transactions in each of a user-specified number of concurrent database sessions.
Orabm通过在用户指定的并发下运行指定数量的事务来测试系统性能.
The transactions are executed by the ORABM_SERVERSIDE_STRESS stored procedure, under the schema ORABM.
事务通过执行orabm用户的ORABM_SERVERSIDE_STRESS过程来实现.
For each concurrent session, ORABM_SERVERSIDE_STRESS runs the number of transactions specified on the orabm command line, and returns the transactions per second (TPS) value for that session during the sampling interval on completion.
对于每个并发session,ORABM_SERVERSIDE_STRESS运行在orabm命令行指定数量的事务.
并返回在完成所有任务的采样间隔内每秒的事务数量.
To ensure that all concurrent sessions are processing transactions during the sampling interval, the TPS value only includes results from the middle 80% of transactions: the first 10% and last 10% are ignored.
为了保证准确性,TPS值只取中间的80%数据,头尾的10%都将被忽略.
The transactions are loosely based on the TPC-C Order-Status and Stock-Level transactions, using a predefined distribution of transactions.
事务是松散的,基于标准的TPC-C测试的订单、库存事务模型,使用预定义的事务分布.
The transaction split, which is based on data returned by the DBMS_RANDOM package, should be:
事务基于DBMS_RANDOM包的返回值进行分割,应该是:
Stock-Level:Order-by-Customer-Name:Order-by-Customer-Id
50% :30% :20%
The string returned by ORABM_SERVERSIDE_STRESS includes the transaction split during the test, to ensure that the transaction distribution is correct, subject to random fluctuations e.g.:
为了确保事务分布的正确性,ORABM_SERVERSIDE_STRESS的输出包含事务分割比例,输出结果具有随机波动,例如:
...sl=4042(50.5%) on=2384(29.8%) oi=1573(19.7%)...
Orabm Command Line
Once you have set up the test tables, data, and indexes, you're ready to run orabm. The following command shows orabm running 20000 transactions in a single session against the Oracle database identified by ORACLE_SID in the UNIX environment:
在成功安装了orabm之后,在UNIX下定义好了ORACLE_SID环境变量之后,我们可以如下运行orabm命令进行测试:
$ orabm 1 20000
This command line runs the same workload against a remote database identified by the Oracle Net alias linxceld1.co.uk from a Windows command box:
以下是在WINDOWS下远程运行方式:
C:\> orabm 1 20000 linxceld1.co.uk
Note: running against a remote database has little (if any), affect on the transaction throughput, because all processing takes place on the DBMS server.
Execution of a single Orabm session should show a single CPU at close to 100% utilization, provided that all table and index data is present in the Oracle block buffer cache and no other workload is running on the database server. On UNIX or Linux, you can use the “top” command to confirm this, or check that no "db file sequential read" event waits are taking place for the Oracle session using info in the V$SESSION_EVENT view - these indicate waits for physical I/O.
如果所有的测试表和相关索引都已经Cache到内存中,系统上没有其他任务运行,那么你可以看到单个Orabm Session会使用将近100%的CPU资源.在Linux或者Unix上，可以使用Top来查看CPU使用情况,或者检察数据库中不存在"db file sequential read"等待事件.
Alternatively, if your Oracle DBMS is running on Linux, you can use the gkrellm performance monitor to show that CPU utilization of a single CPU is at ~100% and no physical I/O is taking place. Gkrellm can be downloaded from:
http://web.wt.net/~billw/gkrellm/gkrellm.html
Here's an example of the command line you would use to run 10000 transactions against a local Oracle database for three iterations. In the first iteration, one session runs, in the second iteration two concurrent sessions run, and in the third iteration, six concurrent sessions run:
以下是一个测试例子,对本地数据库进行三个阶段测试,分别以1,2,6个并发执行10000个事务.
$ orabm 1,2,6 10000
Keep in mind that the specified number of transactions is run in each concurrent session.
注意,这里定义的10000个事务是对每个session来说的.
Note: you should specify sufficient transactions such that the TPS results produced don't fluctuate significantly between runs for a given number of sessions; 100000 is a good value to choose.
Note:你应该定义足够的事务以便TPS结果在不同数量并发下波动尽量小,通常100,000是一个好的选择.
Results Output
Output is appended to a log file orabm.database.log, where database is either the ORACLE_SID or TNS alias that identifies the database where the test was run e.g. orabm.t92.log. For each iteration, the TPS value for each concurrent session appears between begin and end markers. For example, the following shows the contents of the log for two concurrent sessions - in this case the second iteration for the previous command line example - where txn(all) displays the total transaction count, and xn(sam) and t(sam) show the total transactions and time for the middle 80% of transactions for which sampling took place:
输出结果的说明:
txn(all)----代表Total transaction Count,总的事务数量.
xn(sam)-----采样的事务数量
t(sam)------采样事务运行的时间.
---begin sess=2 txn=10000 ORACLE_SID=t92 Fri Nov 8 20:31:48 2002
T92.WORLD txn(all)=10000 xn(sam)=7999 t(sam)=44 tps=182 ...
T92.WORLD txn(all)=10000 xn(sam)=7999 t(sam)=45 tps=178 ...
---end - Fri Nov 8 20:32:46 2002
The total TPS for this iteration is the sum of the TPS for the two concurrent sessions (182+178=360).
对于以上输出,在2个并发下,TPS值为182+178=360
A shell script (orabm_tps.sh) can be used to process output from the log on UNIX and Linux. The script aggregates the TPS values for concurrent sessions in a single iteration into a total TPS value for that iteration. The output based on the log info from the previous command line (3 iterations with 1, then 2, then 6 concurrent sessions) shows:
也可以用shell script(orabm_tps.sh)进行输出日志分析.
$ orabm_tps.sh orabm.t92.log
ORACLE_SID=t92 sess=1 tps=182
ORACLE_SID=t92 sess=2 tps=360
ORACLE_SID=t92 sess=6 tps=364
In this example the server was a 2 CPU model - as a result, 2 concurrent sessions running in orabm are enough to completely utilize all available CPU capacity.
在这个例子中,Server有两个CPU,测试中两个并发足以消耗所有的CPU资源.
Additional sessions should result in the total TPS remaining unchanged, or even falling slightly as the operating system performs context switches to share the overloaded CPU resource between more ready-to-run sessions than available CPUs.
继续增加并发并不会导致TPS值得增加,甚至有可能会下降.
2.看一下我的一个测试结果
$ orabm 1,2,6,10,15,20,25,30 10000 ---begin sess=1 txn=10000 ORACLE_SID=hsbill Sun Sep 26 00:51:34 2004 |
3.使用脚本格式化输出
|
$ orabm_tps.sh ./solaris/bm.hsbill.log |
这里我们可以看出,这台服务器的CPU性能tps值应该在310左右.
Posted by eygle at 12:35 PM | Comments (0)
使用orastress!进行数据库压力测试
作者:eygle
出处:http://blog.eygle.com
Orastress!的作者是Geoff Ingram,也就是我们前面介绍的orabm的作者,他曾经为Oracle工作数年,是High Performance Oracle" (ISBN: 0471224367)一书的作者.
该书现在你可以在本站下载.
关于该工具的官方网页在这里可以找到:
http://www.linxcel.co.uk/orabm/index.html
该工具不是开源的,缺省的只能使用一个session测试,你可以从作者那里申请临时Key,通过以下页面我们可以获得7天的无功能限制使用版:
http://www.linxcel.co.uk/7505/10218_trialkey_orastress!.html
Orastress!需要在windows上运行,你需要安装Oracle客户端.
收到Key以后，注册方式如下:
C:\orabm>orastress!
|
Orastress!需要的数据和orabm类似,你可以参考Orabm的安装方式.
|
# |
Operation |
Command |
|
1 |
create the ORABM user (assumes TOOLS tablespace, TEMP temporary tablespace) |
sqlplus system/pwd @orabm_user |
|
2 |
create the tables |
sqlplus system/pwd @orabm_tab |
|
3 |
load the data |
$ orabmload Warehouses n |
|
4 |
create the indexes |
sqlplus system/pwd @orabm_ind |
|
5 |
analyze the tables and indexes |
sqlplus system/pwd @orabm_analyze |
|
6 |
Ensure ORABM can run the DBMS_LOCK package |
As SYS run: GRANT EXECUTE ON DBMS_LOCK TO ORABM |
注意:这里构建的如果是10个Warehouses的数据,那么大约需要1G的空间.
这里我建议对单节点数据库分别采用1,2,3,5,10个Warehouses进行1,2,4,6,10个并发的50000个事务的测试.
对于多节点RAC建议采用1,2,3,5,10个Warehouses进行1,3,4,7,10个并发的50000个事务的测试.
这一部分安装日志可以参考:安装日志
得到测试数据以后,还需要运行如下脚本:
sqlplus orabm/orabm@<your-TNS-alias> @orastress_tab.sql
sqlplus orabm/orabm@<your-TNS-alias> @orastress.plh
日志参考:windows日志
命令行执行方式如下:
orastress! –s sess-iterations-list –t transacts-per-sess –c tns-alias-list –m mode [ -s batchsize]
-s 指定session数量
-t 指定每个session执行的事物数量.
-c 指定联结串
-m 指定运行模式.包括Read OLTP INS DIO
-s 指定对于INS或DIO模式下提交批量,缺省是10000里
Note: 如果 Orastress! 对单个Warehouse运行在read模式，那么代码执行和orabm相同.
Example 1:
orastress! –s 1 –t 50000 –c inst1.world –m oltp
Example 2:
orastress! –s 2 –t 50000 –c inst1.world,inst2.world –m oltp
Run one iteration comprising 2 concurrent sessions of 50000 transactions on each of inst1.world,inst2.world giving a total of 4 concurrent sessions.The location of the instances specified by inst1.world,inst2.world is entirely down to the user. They could be:
运行一组测试，对两个数据库(inst1.world,inst2.world)各发出两个并发session，每个session运行50000个事务，这两个数据库可以是:
orastress! –s 1,2,4 –t 50000 –c inst1,inst2,inst3,inst4 –m read
运行3组测试，分别以1，2，4个并发session对四个实例，各执行50000个事务:
1st iteration: 1 concurrent session on each instance, giving 4 sessions total
2nd iteration: 2 concurrent sessions on each instance, giving 8 sessions total
3rd iteration: 4 concurrent sessions on each instance, giving 16 sessions
--输出结果:
输出结果和orabm非常类似,具体参考:
---begin mode=oltp sess=1 txn=5000 TNS=l Fri Sep 19 22:11:06 2003
LXD1.WORLD #1 w=3 txn(all)=5000 xn(sam)=3999 t(sam)=431 tps=92.8 end=190903-12:25:39
---end - Fri Sep 19 22:20:19 2003
对于Benchmark测试来说,最重要的是标准,如果大家有统一的模型及标准,那么测试数据也就有了意义,否则以不同的并发、数据进行各不相同的测试是不具有太大意义的.
标准、比较、参考，这对于测试来说是最重要的.
以下给出我的一些测试数据:
1.10个Warehouse的测试数据
|
E:\OraDoc\ORACLE~4\BENCHM~1\ORASTR~1>"orastress!.exe" -s 1 -t 300 -c hsbill -m oltp
---begin mode=oltp sess=1 txn=300 TNS=hsbill Thu Sep 30 10:35:09 2004
HSBILL.HURRAY.COM.CN#1 w=3 txn(all)=300 xn(sam)=239 t(sam)=120 tps=2 d=13(5.4%) n=102(42.7%) o=6(2.5%) p=112(46.9%) s=6(2.5%) end=
300904-10:34:38
---end - Thu Sep 30 10:37:39 2004
E:\OraDoc\ORACLE~4\BENCHM~1\ORASTR~1>"orastress!.exe" -s 2 -t 300 -c hsbill -m oltp
---begin mode=oltp sess=2 txn=300 TNS=hsbill Thu Sep 30 10:41:40 2004
HSBILL.HURRAY.COM.CN#1 w=4 txn(all)=300 xn(sam)=239 t(sam)=469 tps=.5 d=12(5%) n=103(43.1%) o=13(5.4%) p=101(42.3%) s=10(4.2%) end
=300904-10:47:25
HSBILL.HURRAY.COM.CN#1 w=4 txn(all)=300 xn(sam)=239 t(sam)=314 tps=.8 d=11(4.6%) n=92(38.5%) o=10(4.2%) p=119(49.8%) s=7(2.9%) end
=300904-10:47:51
---end - Thu Sep 30 10:50:51 2004
E:\OraDoc\ORACLE~4\BENCHM~1\ORASTR~1>"orastress!.exe" -s 2 -t 3000 -c hsbill -m oltp
---begin mode=oltp sess=2 txn=3000 TNS=hsbill Thu Sep 30 11:26:02 2004
HSBILL.HURRAY.COM.CN#1 w=8 txn(all)=3000 xn(sam)=2399 t(sam)=4991 tps=.5 d=109(4.5%) n=1016(42.4%) o=116(4.8%) p=1050(43.8%) s=108
(4.5%) end=300904-13:09:23
HSBILL.HURRAY.COM.CN#1 w=4 txn(all)=3000 xn(sam)=2399 t(sam)=5432 tps=.4 d=87(3.6%) n=997(41.6%) o=128(5.3%) p=1070(44.6%) s=117(4
.9%) end=300904-13:13:50
---end - Thu Sep 30 13:16:51 2004
|
2.5个warehouse的测试数据
|
E:\OraDoc\ORACLE~4\BENCHM~1\ORASTR~1>"orastress!.exe" -s 2 -t 300 -c hsbill -m oltp
---begin mode=oltp sess=2 txn=300 TNS=hsbill Thu Sep 30 15:48:20 2004
HSBILL.HURRAY.COM.CN#1 w=2 txn(all)=300 xn(sam)=239 t(sam)=13 tps=18.4 d=7(2.9%) n=97(40.6%) o=9(3.8%) p=119(49.8%) s=7(2.9%) end=
300904-15:45:40
HSBILL.HURRAY.COM.CN#1 w=5 txn(all)=300 xn(sam)=239 t(sam)=19 tps=12.6 d=7(2.9%) n=97(40.6%) o=11(4.6%) p=112(46.9%) s=12(5%) end=
300904-15:45:47
---end - Thu Sep 30 15:48:47 2004
|
Posted by eygle at 12:35 PM | Comments (2)
如何实施Benchmark标准测试-问题的提出及Tpc-C标准
作者:eygle
出处:http://blog.eygle.com
1.问题的提出
不管你实施怎样的一个系统，你可能都考虑过这样的一系列问题:
我应该采购怎样的设备?
我的系统性能如何?
我的系统能够承受多少用户?
我的系统能够承受多少并发?
性能问题会在何时出现?
我将在何时升级?
显然，回答这些问题并非那么简单，更多的人是根据经验给出一个经验值，用来评估系统.
但是在大系统设计过程中，经验显示是不足够的，你必须拿出足够的证据来说明你的架构，你的系统必须在理论上能够满足用户的需求.
到这里我们已经看到,一个最重要的内容被引入了，那就是:用户需求.
这符合经济规律，有需求才有发展，需求推动一切.于是也就有了今天我们要讨论的标准测试(benchmark).
最近一段时间，一直参与一个大系统的方案设计、规划与测试，现在把一些心得写出来，供大家参考.
2.TPC组织
关于Benchmark测试，最有名的就是TPC(Transaction Processing Performance Council，事务处理性能委员会)组织了.你可以在其
官方站点 www.tpc.org 获得更为详细的信息.TPC组织成立于1988年,由一些在计算机领域提供软硬件系统或者相关解决方案的原厂商组
成，会员从成立之初的8家公司发展到目前的50余家，IBM、NCR、HP、Oracle、Microsoft等国际著名公司均是其会员。总部设在美国，
并对全世界开放，但迄今为止，TPC组织绝大多数会员都是美、日、西欧的计算机软硬件大公司.
作为一家非盈利性机构，事务处理性能委员会(TPC)负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准
测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会
成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。
TPC不给出基准程序的代码，而只给出基准程序的标准规范(Standard Specification)。
注意,这里我们提出在Benchmark测试中最重要的一个内容:标准规范.
你可能听到很多人这样对你说，TPC-C值不具有任何实际意义，任何测试都无法模拟真实生产环境中的负荷情况。
这总说法自然有其道理，但是未免片面了，或者说这种说法实际上曲解了TPC-C等标准测试的本意.
我们说Benchmark测试中最重要的是标准规范，也就是说，其实工具等因素是不重要的，只要大家都是用同一标准规范、同一工具进行系统
测试， 那么测试结果也就具有了比较意义.
从这个意义出发，benchmark测试实际上就成了各个厂商展示其技术实力的舞台.任何厂家或其它测试者都可以根据TPC组织公布的规范标准，
最优地构造出自己的系统，使用最优的平台和最高效的应用程序. 所以你可能听Oracle这样攻击过DB2,Oracle说:IBM进行的TPC测试使用的
都是Oracle数据库,而不是他们自己的DB2. 其实这个说法也是片面的，TPC-C测试的是OLTP的性能，而我们知道DB2在数据仓库方面才是真正
强大的.
为了保证测试结果的客观性，被测试者(通常是厂家)必须提交给TPC一套完整的报告(FullDisclosure Report)，包括被测系统的详细配置、分
类价格和包含五年维护费用在内的总价格.该报告必须由TPC授权的审核员核实(TPC本身并不做审计). 现在全球只有几 个审核员，全部在美国.
TPC已经推出了四套基准程序,被称为TPC-A、TPC-B、TPC-C和TPC-D。其中A和B已经过时,不再使 用了.TPC-C是在线事务处理(OLTP)的
基准程序，TPC-D是决策支持(DecisionSupport) 的基准程序。TPC后来尝试推出的TPC-E，TPC-S，最终被放弃。
3.TPC-C
我们重点关注的是TPC-C测试.
TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式
小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其
它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行
公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。
tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟
3．1TPC-C规范概要
TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。
TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:
假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；
每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。
该系统需要处理的交易为以下几种：
-
New-Order：客户输入一笔新的订货交易；
-
Payment:更新客户账户余额以反映其支付状况;
-
Delivery:发货(模拟批处理交易);
-
Order-Status:查询客户最近交易的状态；
-
Stock-Level:查询仓库库存状况，以便能够及时补货。
对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。
逻辑结构图：
流程图：
3.2．评测指标
TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算
机技术的不断发展，这些测试结果也在不断刷新。
TPC-C的测试结果主要有两个指标：
● 流量指标(Throughput，简称tpmC)
按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个
New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。
流量指标值越大越好！
● 性价比(Price/Performance，简称Price/tpmC)
即测试系统价格（指在美国的报价）与流量指标的比值。
性价比越小越好！
关于这部分内容,在TPC-C的官方文档中可以找到详细的说明，你可以在以下链接获得TPC组织的官方文档:
http://www.tpc.org/tpcc/spec/tpcc_current.pdf
在IBM的官方网站上，你也可以找到部分说明:
http://www-900.ibm.com/cn/products/servers/pseries/tech/tpcc.shtml
目前TPC-C的版本是5.2.
Posted by eygle at 12:33 PM | Comments (0)