如何进行数据库压力测试工具tiobench,orion,lmbench,netperf的安装及简单使用1.          Tiobench 基于文件系统的IO压力测试2.       使用Orion做基于裸设备的IO压力测试3           Lmbench 内存测试:4           netperf针对网络做压力测试

这篇文章将为大家详细讲解有关如何进行数据库压力测试工具tiobench,orion,lmbench,netperf的安装及简单使用,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。

下载:

http://sourceforge.net/projects/tiobench/files/tiobench/0.3.3/tiobench-0.3.3.tar.gz/download

解压缩: tar xzvf tiobench-0.3.3.tar.gz

再进入到tiobench-0.3.3目录中

Make

Make install

IO测试(对文件系统读写测试工具)可以使用以下命令取得帮助。

./tiotest -h

使用预定义或者可配置测试可以使用可以命令获取帮助。

./tiobench.pl –help

执行可以如下:tiobench.pl其实只是包装了一层,里面调用了tiotest

./tiobench.pl –block 4 –random 10000 –numruns 5 –threads 10 –size 2048

上面这句话的意思是:

1个块大小为4字节 ,10个线程,执行10000个随机IO,写2048MB数据,共执行5次。

测试完之后可以看到产生的测试报告如下:

Unit information================

File size = megabytes

Blk Size  = bytes

Rate      = megabytes per second

CPU%      = percentage of CPU used during the test

Latency   = milliseconds

Lat%      = percent of requests that took longer than X seconds

CPU Eff   = Rate divided by CPU% – throughput per cpu load

Sequential Reads

2.6.18-164.el5   1024  4    10    4.94 8210.%     0.004     7.27   0.00000  0.00000     0

Random Reads

2.6.18-164.el5   1024  4    10    4.64 7483.%     0.004     0.04    0.00000  0.00000     0

Sequential Writes

2.6.18-164.el5   1024  4    10    2.21 9521.%     0.015     11.56   0.00000  0.00000     0

Random Writes

2.6.18-164.el5   1024  4    10    0.02 98.51%     0.012     0.06   0.00000  0.00000     0

想知道各行分别代表什么含义,请执行:./tiosum.pl可以得到各行的TIILE。感觉这个地方很山寨。
组装一下就是:

Unit information================

File size = megabytes

Blk Size  = bytes

Rate      = megabytes per second

CPU%      = percentage of CPU used during the test

Latency   = milliseconds

Lat%      = percent of requests that took longer than X seconds

CPU Eff   = Rate divided by CPU% – throughput per cpu load

Sequential Reads

                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU

Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff

—————————- —— —– —  ————————————————————

2.6.18-164.el5                1024    4    10    4.94 8210.%     0.004        7.27   0.00000  0.00000     0

Random Reads

                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU

Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff

—————————- —— —– —  ————————————————————

2.6.18-164.el5                1024    4    10    4.64 7483.%     0.004        0.04   0.00000  0.00000     0

Sequential Writes

                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU

Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff

—————————- —— —– —  ————————————————————

2.6.18-164.el5                1024    4    10    2.21 9521.%     0.015       11.56   0.00000  0.00000     0

Random Writes

                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU

Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff

—————————- —— —– —  ————————————————————

2.6.18-164.el5                1024    4    10    0.02 98.51%     0.012        0.06   0.00000  0.00000     0

发现一个读IO只要0.004毫秒,非常快,这是因为IO是基于文件系统cache的,其实测试的是内存,并非文件系统。所以,可以使用下面一个工具来测试IO。

下载http://www.oracle.com/technetwork/topics/index-089595.html,需要一个OTN的免费帐号。

下载安装之后,可以以下命令获取帮助:

./orion_linux_x86-64 –help

为了避免文件系统cache,我们可以将需要测试的目录先进行umount

如:我要测试的目录为/data/对应的盘为/dev/sda8(映射关系保存在/etc/fstab中)

先执行:

umount /data

然后执行命令,命令执行完成后,再执行mount /data即可重新mount回来。

mount /data

测试如下:

2.1数据库OLTP类型,假定IO类型全部是8K随机操作,压力类型,自动加压,从小到大,一直到存储压力极限。读写比各为50%

2.2.1        测试8KB的块,这个是数据库块大小

       创建一个文件名为zhoucang8k.lun的文件,内容为/dev/sda8  

./orion_linux_x86-64 -run advanced -testname zhoucang8k -size_small 8 -size_large 8 -type rand -write 50 &

这里能够得到一些报告如下:

文件1:zhoucang8k_20110520_1757_lat.csv表示每个IO的延时,1,2,3,4,5分别代表并发数
Large/Small1234503.554.184.775.355.941     2     
文件2:zhoucang8k_20110520_1757_iops.csvIOPS的能力,1,2,3,4,5分别代表并发数。
Large/Small1234502814786287478421     2     
文件3:zhoucang8k_20110520_1757_mbps.csv IO吞吐量,单位:MB/每秒
Large/Small01234512.14     23.72     

还有两个文件trace文件内容较长,这里不贴了,另一个summary文件如下:

文件4:zhoucang8k_20110520_1757_summary.txt
ORION VERSION 11.1.0.7.0Commandline:

-run advanced -testname zhoucang8k -size_small 8 -size_large 8 -type rand -write 50

This maps to this test:

Test: zhoucang8k

Small IO size: 8 KB

Large IO size: 8 KB

IO Types: Small Random IOs, Large Random IOs

Simulated Array Type: CONCAT

Write: 50%

Cache Size: Not Entered

Duration for each Data Point: 60 seconds

Small Columns:,      0

Large Columns:,      0,      1,      2

Total Data Points: 8

Name: /dev/sda8    Size: 1053115467264

1 FILEs found.

Maximum Large MBPS=3.72 @ Small=0 and Large=2

Maximum Small IOPS=842 @ Small=5 and Large=0

Minimum Small Latency=3.55 @ Small=1 and Large=0

2.2.2   测试128KB的随机IO,这个是db_file_multiblock_read_count的默认值。

       创建一个文件名为zhoucang128k.lun的文件,内容为/dev/sda8  

./orion_linux_x86-64 -run advanced -testname zhoucang128k -size_small 128 -size_large 128  -type rand -write 50 &

结果(见附件):

Maximum Large MBPS=29.11 @ Small=0 and Large=2

Maximum Small IOPS=311 @ Small=5 and Large=0

Minimum Small Latency=5.93 @ Small=1 and Large=0

2.2.3        测试1MB的随机IO,这个是操作系统上能够支持的最大IO。

       创建一个文件名为zhoucang1024k.lun的文件,内容为/dev/sda8  

./orion_linux_x86-64 -run advanced -testname zhoucang1024k -size_small 1024-size_large 1024 –write 50 -type rand &

结果(见附件):

Maximum Large MBPS=109.76 @ Small=0 and Large=2

Maximum Small IOPS=135 @ Small=5 and Large=0

Minimum Small Latency=11.49 @ Small=1 and Large=0

2.2 IO吞吐量的测试,跟数据库归档等相关。

2.2.1        数据库吞吐量测试,假定IO全部是1M的序列性IO

./orion_linux_x86-64 -run advanced -testname zhoucang1m -size_small 1024 -size_large 1024 –write 50 -type seq &

IOPS:

Large/Small 1 2 3 4 5
0 83 110 123 129 133

Lat:

Large/Small 1 2 3 4 5
0 11.92 18.12 24.33 30.86 37.56

整完之后,可能需要重新创建文件系统。因为/dev/sda8的label头信息被覆盖了。

/etc/fstab内容如下

LABEL=/data             /data                   ext3    defaults        1 2

执行以下命令创建文件系统。

mkfs -t ext3  /dev/sda8

/etc/fstab中加入:

/dev/sda8               /data                   ext3    defaults        1 2

mount -a

下载一个Lmbench:

www.bitmover.com/lmbench

http://www.bitmover.com/bitkeeper(里面的链接,打不开)

tar xzvf lmbench-3.0-a9.tgz

lmbench-3.0-a9

make results

输入1000,大概1G的内存测试。(这个值越大,测试结果越准确,同时,值大,测试的时间也会稍稍有点长)

其它参数可以自选,这里我选择了全部默认(调带大小等参数),漫长的执行过程。。。。

测试完毕执行make see可得到以下四个文件,

在result目录下:percent.errs  percent.out  summary.errs  summary.out
percent.errs和summary.errs

其它:具体如何使用这个工具呢?发现这个工具BIN目录下有非常多的文件,功能很强大,具体可以参看这个链表上面有详细的介绍:

http://www.bitmover.com/lmbench/man_lmbench.html

详尽的测试结果见附件:

这个工具是由HP公司开发的,测试网络栈的一个工具,详细的使用文档可以参看附件。

从官方网下载一个netperf,登录:

ftp://ftp.netperf.org/netperf/

拷贝文件:netperf-2.4.5.tar.gz

执行

Tar xzvf netperf-2.4.5.tar.gz

cd netperf-4.0.0rc2

Mkdir bin

./configure –prefix /root/zhoucang/netperf-2.4.5/bin

检测安装平台的目标特征的,能够直接linux下的makefile,

再执行make和make install

安装完成之后,进入安装目录的 bin目录。

执行以下命令可以查看帮助:

./netperf –help

4.1批量(bulk)网络流量的性能

批量数据传输典型的例子有ftp和其它类似的网络应用(即一次传输整个文件)。根据使用传输协议的不同,批量数据传输又分为TCP批量传输和UDP批量传输。

4.1.1        测试TCP_STREAM传输:

Netperf缺省情况下进行TCP批量传输,即-t TCP_STREAM。测试过程中,netperf向netserver发送批量的TCP数据分组,以确定数据传输过程中的吞吐量:

测试结果如下

[root@tstpay1 bin]#  ./netperf -H 10.253.34.8 -l 60TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Recv   Send    Send                         

Socket Socket  Message  Elapsed             

Size   Size    Size     Time     Throughput 

bytes  bytes   bytes    secs.    10^6bits/sec 

 87380  16384  16384    60.03     949.29 

从netperf的结果输出中,我们可以知道以下的一些信息:

1) 远端系统(即server)使用大小为87380字节的socket接收缓冲

2) 本地系统(即client)使用大小为16384字节的socket发送缓冲

3) 向远端系统发送的测试分组大小为16384字节

4) 测试经历的时间为60.03秒

5) 吞吐量的测试结果为949.29Mbits/秒

4.1.2        UDP_STREAM的测试

UDP_STREAM用来测试进行UDP批量传输时的网络性能。需要特别注意的是,此时测试分组的大小不得大于socket的发送与接收缓冲大小,否则netperf会报出错提示:

执行:./netperf -t UDP_STREAM -H 10.253.34.8 -l 60

执行结果如下:

[root@tstpay1 bin]# ./netperf -t UDP_STREAM -H 10.253.34.8 -l 60UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Socket  Message  Elapsed      Messages               

Size    Size     Time         Okay Errors   Throughput

bytes   bytes    secs            #      #   10^6bits/sec

262144   65507   60.00      110099      0     961.62

129024           60.00      110098            961.61

UDP_STREAM方式的结果中有两行测试数据,第一行显示的是本地系统的发送统计,这里的吞吐量表示netperf向本地socket发送分组的能力。但是,我们知道,UDP是不可靠的传输协议,发送出去的分组数量不一定等于接收到的分组数量。

第二行显示的就是远端系统接收的情况,由于client与server直接连接在一起,而且网络中没有其它的流量,所以本地系统发送过去的分组几乎都被远端系统正确的接收了,远端系统的吞吐量也几乎等于本地系统的发送吞吐量。但是,在实际环境中,一般远端系统的socket缓冲大小不同于本地系统的socket缓冲区大小,而且由于UDP协议的不可靠性,远端系统的接收吞吐量要远远小于发送出去的吞吐量。

4.2 请求/应答(request/response)网络流量的性能

另一类常见的网络流量类型是应用在client/server结构中的request/response模式。在每次交易(transaction)中,client向server发出小的查询分组,server接收到请求,经处理后返回大的结果数据。

4.2.1        TCP_RR

TCP_RR方式的测试对象是多次TCP request和response的交易过程,但是它们发生在同一个TCP连接中,这种模式常常出现在数据库应用中。数据库的client程序与server程序建立一个TCP连接以后,就在这个连接中传送数据库的多次交易过程。

[root@tstpay1 bin]#  ./netperf -t TCP_RR -H 10.253.34.8TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local /Remote

Socket Size   Request  Resp.   Elapsed  Trans.

Send   Recv   Size     Size    Time     Rate        

bytes  Bytes  bytes    bytes   secs.    per sec  

16384  87380  1        1       10.00    11294.81  

Netperf输出的结果也是由两行组成。第一行显示本地系统的情况,第二行显示的是远端系统的信息。平均的交易率(transaction rate)为11294.81次/秒。注意到这里每次交易中的request和response分组的大小都为1个字节,不具有很大的实际意义。用户可以通过测试相关的参数来改变request和response分组的大小,TCP_RR方式下的参数如下表所示:

参数 说明
-s size 设置本地系统的socket发送与接收缓冲大小
-S size 设置远端系统的socket发送与接收缓冲大小
-r req,resp 设置request和reponse分组的大小
-D 对本地与远端系统的socket设置TCP_NODELAY选项

通过使用-r参数,我们可以进行更有实际意义的测试:

#./netperf -t TCP_RR -H 10.253.34.8 — -r 32,1024TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local /Remote

Socket Size   Request  Resp.   Elapsed  Trans.

Send   Recv   Size     Size    Time     Rate        

bytes  Bytes  bytes    bytes   secs.    per sec  

16384  87380  32       1024    10.00    8955.26  

16384  87380

从结果中可以看出,由于request/reponse分组的大小增加了,导致了交易率明显的下降。注:相对于实际的系统,这里交易率的计算没有充分考虑到交易过程中的应用程序处理时延,因此结果往往会高于实际情况。

4.2.2        TCP_CRR

与TCP_RR不同,TCP_CRR为每次交易建立一个新的TCP连接。最典型的应用就是HTTP,每次HTTP交易是在一条单独的TCP连接中进行的。因此,由于需要不停地建立新的TCP连接,并且在交易结束后拆除TCP连接,交易率一定会受到很大的影响。

[root@tstpay1 bin]# ./netperf -t TCP_CRR -H 10.253.34.8TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local /Remote

Socket Size   Request  Resp.   Elapsed  Trans.

Send   Recv   Size     Size    Time     Rate        

bytes  Bytes  bytes    bytes   secs.    per sec  

16384  87380  1        1       10.00    4607.63  

16384  87380

即使是使用一个字节的request/response分组,交易率也明显的降低了,只有4607.63次/秒。TCP_CRR使用与TCP_RR相同的局部参数。

4.2.3        UDP_RR

UDP_RR方式使用UDP分组进行request/response的交易过程。由于没有TCP连接所带来的负担,所以我们推测交易率一定会有相应的提升。

[root@tstpay1 bin]# ./netperf -t UDP_RR -H 10.253.34.8UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local /Remote

Socket Size   Request  Resp.   Elapsed  Trans.

Send   Recv   Size     Size    Time     Rate         

bytes  Bytes  bytes    bytes   secs.    per sec  

262144 262144 1        1       10.00    11367.45  

129024 129024

结果证实了我们的推测,交易率为11367.45次/秒,高过TCP_RR的数值。不过,如果出现了相反的结果,即交易率反而降低了,也不需要担心,因为这说明了在网络中,路由器或其它的网络设备对UDP采用了与TCP不同的缓冲区空间和处理技术。

关于如何进行数据库压力测试工具tiobench,orion,lmbench,netperf的安装及简单使用就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

原创文章,作者:kepupublish,如若转载,请注明出处:https://blog.ytso.com/199149.html

(0)
上一篇 2021年11月20日
下一篇 2021年11月20日

相关推荐

发表回复

登录后才能评论