|
测试系统性能.
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%)...
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.
注意：你应该定义足够的事务以便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）测试TPS值
下面我们来具体跑一下程序。在跑程序之前，要注意一下：前面的例子应该可以看到，在windows平台下运行orabmload时，设置了 LOCAL 变量，这个变量相当于UNIX平台下的ORACLE_SID，这次运行orabm程序，却有所不同，见下面的运行日志：
E:\temp>orabm 1,2,6,10 10000
ORACLE_SID not set
E:\temp>set LOCAL=ccbver
E:\temp>orabm 1,2,6,10 10000
ORACLE_SID not set
E:\temp>set ORACLE_SID=ccbver
E:\temp>orabm 1,2,6,10 10000
---begin sess=1 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:03:45 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=17 tps=471 sl=3918(49%) on=2483(31%) o
i=1598(20%) end=260105-10:05:58
---end - Wed Jan 26 11:04:09 2005
---begin sess=2 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:04:09 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=17 tps=471 sl=3999(50%) on=2441(30.5%)
oi=1559(19.5%) end=260105-10:06:19
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=17 tps=471 sl=4025(50.3%) on=2396(30%)
oi=1578(19.7%) end=260105-10:06:19
---end - Wed Jan 26 11:04:31 2005
---begin sess=6 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:04:31 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4041(50.5%) on=2372(29.7
%) oi=1586(19.8%) end=260105-10:07:13
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4017(50.2%) on=2404(30.1
%) oi=1578(19.7%) end=260105-10:07:13
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=42 tps=190 sl=3917(49%) on=2505(31.3%)
oi=1577(19.7%) end=260105-10:07:14
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4016(50.2%) on=2394(29.9
%) oi=1589(19.9%) end=260105-10:07:14
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4038(50.5%) on=2316(29%)
oi=1645(20.6%) end=260105-10:07:14
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=47 tps=170 sl=4011(50.1%) on=2380(29.8
%) oi=1608(20.1%) end=260105-10:07:15
---end - Wed Jan 26 11:05:26 2005
---begin sess=10 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:05:26 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=3969(49.6%) on=2390(29.9
%) oi=1640(20.5%) end=260105-10:08:45
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=4061(50.8%) on=2407(30.1
%) oi=1531(19.1%) end=260105-10:08:45
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=73 tps=110 sl=3996(50%) on=2444(30.6%)
oi=1559(19.5%) end=260105-10:08:46
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=4089(51.1%) on=2334(29.2
%) oi=1576(19.7%) end=260105-10:08:46
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=71 tps=113 sl=3935(49.2%) on=2468(30.9
%) oi=1596(20%) end=260105-10:08:46
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=74 tps=108 sl=4015(50.2%) on=2380(29.8
%) oi=1604(20.1%) end=260105-10:08:47
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=4008(50.1%) on=2446(30.6
%) oi=1545(19.3%) end=260105-10:08:47
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=76 tps=105 sl=3939(49.2%) on=2454(30.7
%) oi=1606(20.1%) end=260105-10:08:48
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=76 tps=105 sl=4061(50.8%) on=2333(29.2
%) oi=1605(20.1%) end=260105-10:08:48
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=77 tps=104 sl=3932(49.2%) on=2432(30.4
%) oi=1635(20.4%) end=260105-10:08:48
---end - Wed Jan 26 11:06:59 2005
原来还要设置 ORACLE_SID 变量！
我跑的这个例子是分四个案例：
第一个是1个并发session跑10000个事务；
第二个是2个并发session跑10000个事务；
第三个是6个并发session跑10000个事务；
第四个是10个并发session跑10000个事务。
测试程序运行结束后，会生成一个orabm.{ORACLE_SID}.log的文件，比如上面这个例子，生成的文件是 orabm.ccbver.log，该文件是累加的，如果继续跑测试程序，其测试结果会累加到这个文件中。
（3）格式化输出
其实从上面的运行结果中已经差不多可以看出TPS的值了，把并发session的TPS值相加即可。不过，orabm程序包中有一个格式化输出结果的SHELL脚本，可以看得更加清楚。
当然，得把日志文件上传到服务器上去运行，毕竟是SHELL程序嘛。
看结果：
$ ./orabm_tps.sh orabm.ccbver.log
ORACLE_SID=ccbver sess=1 tps=471
ORACLE_SID=ccbver sess=2 tps=942
ORACLE_SID=ccbver sess=6 tps=1104
ORACLE_SID=ccbver sess=10 tps=1089
可以看出，这台机器的TPS值大概在1100左右。
后来把事务数变为100000，再跑了一下，结果也差不多，如下：
$ ./orabm_tps.sh orabm.ccbver.log
上一页 [1] [2] [3] 下一页
[网络安全]代理服务器的概念及功能介绍 [网页制作]在Dreamweaver中按F12浏览的为什么是远程服务器的…
[网络技术]详细介绍通过远程桌面连接控制远程服务器的操作方… [网络技术]服务器的硬件由哪些构成
[系统软件]EXP-00008: ORACLE error 904 encountered的解决方… [常用软件]PB7 连接 Oracle 的配置方法
[Web开发]oracle Export and Import 简介 [Web开发]ADO访问Oracle结果集的心得
[JAVA开发]JDBC+Hibernate将Blob数据写入Oracle [JAVA开发]J2EE应用中与Oracle数据库的连接
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
