性能自动化测试方略

目录

一．数据库性能... 1

1.1 在开始性能测试之前确认... 1

1.2 自动脚本检验... 1

二．服务器性能... 2

三．应用程序性能... 2

四．网络性能... 2

五．用到的工具及原理... 2

5.1 CPU性能分析工具：... 2

5.2 Memory性能分析工具：... 3

5.3 I/O性能分析工具：... 5

5.4 Network性能分析工具：... 9

 

 一．数据库性能

1.1 在开始性能测试之前确认

1. 数据库本身的一些重要参数的设置是否合理？

Ø  数据库表在建立在那个表空间？

Ø  对一些报警信息的阈值是否进行了设置？

Ø  SGA_MAX_SIZE等参数设置

Ø  缓存命中率等是否达到要求

2. 弄清楚数据库架构

Ø  专用服务器模式

Ø  共享服务器模式

3. 弄清楚应用程序连接数据库服务器的方式

Ø  普通连接

Ø  连接池

4. 弄清楚共享内存大小等参数的配置

1.2 自动脚本检验

1．数据库操作代码设计是否合理？

Ø  找出滥用I/O的前25个SQL语句

Ø  SQL语句的设计，限制对索引的引用，如：<>,!=,is NULL, is not NULL等where字句

2.  索引设置是否合理？

Ø  外键是否没有设置索引？

Ø 索引类型是否需要改变？（如B树索引、位图索引等）

3.  数据库的CPU、I/O性能，找出瓶颈所在

二．服务器性能

主要监视应用程序所在的服务器的cpu、I/O性能，找出瓶颈所在

 

三．应用程序性能

主要对日志文件的分析

四．网络性能

主要监视性能瓶颈是否发生在网络这一块

 

 

五．用到的工具及原理

5.1 CPU性能分析工具：

         当一个系统的CPU空闲时间或者等待时间小于5%时，我们就可以认为系统的CPU资源耗尽，我们应该对CPU进行性能调整。

 

1.      Top

发现系统中最影响性能的用户

 

2.      Sar

sar –u 3 1000 >sar_cup.log[例子]

Linux 2.6.18-128.el5 (yali02)   05/23/2011

03:45:03 PM      CPU     %user     %nice  %system   %iowait    %steal    %idle

03:45:05 PM      all     14.12      0.00     8.09      5.97      0.00    71.83

03:45:07 PM      all     23.09      0.00    12.41      1.25      0.00    63.25

03:45:09 PM      all      0.87      0.00     0.50     13.43      0.00    85.19

03:45:11 PM      all     26.04      0.00    15.33      0.69      0.00    57.95

03:45:13 PM      all     11.78      0.00     6.91     12.38      0.00    68.94

03:45:15 PM      all     14.31      0.00     8.18      6.22      0.00    71.29

03:45:17 PM      all     24.08      0.00    13.96      2.15      0.00    59.81

03:45:19 PM      all      0.06      0.00     0.09     18.88      0.00    80.97

03:45:21 PM      all     21.58      0.00    13.05      2.56      0.00    62.80

03:45:23 PM      all     11.75      0.00     6.59     13.38      0.00    68.28

Average:          all    14.77      0.00      8.51     7.69      0.00     69.03

说明：

主要分析:

iowait列：如果iowait值很高，说明cpu主要在等待IO操作，IO很可能是瓶颈；

idle列：如果该列值很低，说明CPU负载很高，或者CPU处理能力不足。

如果idle列值低，iowait列很高，也有可能是IO的瓶颈。

 

主要用来分析：

低CPU空闲时间

等待I/O（iowait）>10%所用时间的高百分比

%system>15 瓶颈。这可能说明交换、分页或者备份会导致瓶颈

%usr异常高。这可能是由于没有正确调正应用程序或过度利用cup

 

3.      ps

将ps命令与以选的V$视图相结合

ps -e  –o pcpu ,pid,user,args |sort –k3 –r | tail

4.      vmstat -x

 

5.2 Memory性能分析工具：

         当一个应用系统的内存资源出现下面的情况时，我们认为需要进行Memory性能调整：

页面频繁换进换出；缺少非活动页。

         例如在使用vmstat命令时发现，memory的cache使用率非常低，而swap的si或者so则有比较高的数据值时，应该警惕内存的性能问题。

 

一．利用free命令监控内存

         从操作系统角度和应用程序角度进行分析free命令结果。

         Linux系统下对内存的调度有缓存机制，如果系统需求内存很大的话,被缓存的内存页是可以回收的。不过一般为了高效，是处于cache状态。

如果你用free命令查看内存使用状况，-/+ buffers/cache这行的数值才是你需要获取的信息。

 

[root@zeus ~]# free -m

                            total       used      free     shared   buffers     cached

Mem:      3920       3837       82          0     132       1947

-/+ buffers/cache:       1757       2162

Swap:                        4094         1       4093

 

1．操作系统是看 Mem

这里的free=82才是真正没有任何数据的(注意，不是系统的可用内存量)，不涉及到Linux高效数据存取(Access)中提到的缓存。

total：内存总数

used：已使用内存数

free：空闲的内存数

shared：可以忽略，过时不用的了，总是为0

buffers：Buffer缓存内存数

cached：Page缓存内存数

关系：total=used+free

 

2．应用程序看-/+buffers/cache(这行代表的就是程序真正使用内存量和剩余内存量):

这里的free（106）表示可以被应用程序可支配的剩余内存,也就是系统还有多少内存可以被程序使用

used=Mem行中的used – buffers – cached

free=Mem行中的free + buffers +cached

可见-buffers/cache反映的是被程序实实在在吃掉的内存，而+buffers/cache反映的是可以挪用的内存总数。

当可用内存少于额定值的时候，就会开会进行交换。

 

3．Swap

只要不用swap的交换空间，就不用担心自己的内存太少。如果常常swap用很多，可能你就要考虑加物理内存了。这也是linux看内存是否够用的标准。

 

其实可以从二个方面来解释：

对操作系统来讲是Mem的参数.buffers/cached 都是属于被使用的。

对应用程序来讲是(-/+ buffers/cache)，buffers/cached 是等同可用的，因为buffer/cached是为了提高程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。

 

所以,以应用来看看，以(-/+ buffers/cache)的free和used为主.所以我们看这个就好了。另外告诉大家一些常识。Linux为了提高磁盘和内存存取效率。Linux做了很多精心的设计, 除了对dentry进行缓存(用于VFS，加速文件路径名到inode的转换), 还采取了两种主要Cache方式：Buffer Cache和Page Cache。前者针对磁盘块的读写，后者针对文件inode的读写。这些Cache能有效缩短了 I/O系统调用(比如read，write，getdents)的时间。

 

一般有这样一个经验公式：

应用程序可用内存/系统物理内存>70%时，表示系统内存资源非常充足，不影响系统性能，

应用程序可用内存/系统物理内存<20%时，表示系统内存资源紧缺，需要增加系统内存，

20%<应用程序可用内存/系统物理内存<70%时，表示系统内存资源基本能满足应用需求，暂时不影响系统性能。

 

二．利用vmstat命令监控内存

 

[root@www ~]# vmstat 2 10

procs ———–memory———- —swap– —–io—- –system–—–cpu——

r b   swpd   free  buff  cache   si  so    bi    bo  in   cs us sy id wa st

1 1   1096 211184 1254481747432    0    0   63   222    1   3 19  7 57 17  0

3 0   1096 167492 1256801750628    0    0 1212     6 5225 2765 21 11 5612  0

1 5   1096 202556 1258801754964    0    0 1122  2286 5502 2252 32  6 46 16 0

3 1   1096 126464 1253961765556    0    0 4842    88 5723 3821 38 11 3318  0

2 4   1096 192260 1250641752772    0    0 1958    42 4817 1868 20  6 61 14 0

1 3   1096 182900 1252281757592    0    0 3668  4530 5513 2948 29 11 3129  0

3 4   1096 127220 1253881763436    0    0 3016    20 5579 2329 20 13 3136  0

2 11  1096 138924 125616 1774812   0    0  4702  150 5871 3263 64  9  9 19  0

0 1   1096 164788 1258001777452    0    0 3634    52 6158 2897 47  6 30 17 0

2 3   1096 175148 1249921749708    0    0 4032     2 5698 2720 26  8 37 28 0

 

1，看memory列

swpd: 虚拟内存使用情况，单位：KB

         如果不为0，或者比较大，但si,so一直为0，这种情况通常也不会影响系统性能。

free: 当前系统空闲的内存，单位KB

buff：表示buffers cache的内存数量，一般对块设备的读写才需要缓冲。

cache：表示page cached的内存数量，一般作为文件系统cached，频繁访问的文件都会被cached，

如果cache值较大，说明cached的文件数较多，如果此时IO中bi比较小，说明文件系统效率比较好。

 

2，看swap列

si：表示从磁盘交换到内存的交换页数量，单位：KB/秒

so：表示从内存交换到磁盘的交换页数量，单位：KB/秒

一般情况下，si、so的值都为0，如果si、so的值长期不为0，则表示系统内存不足。需要考虑增加系统内存。

 

对Mem性能的工具主要有：

1.      Top

2.      Vmstat

3.      Strace

4.      Ipcs

5.      ipcrm

 

5.3 I/O性能分析工具：

         系统出现以下情况时，我们认为该系统存在I/O性能问题：

         系统等待I/O的时间超过50%；一个设备的平均队列长度大于5。

         我们可以通过诸如vmstat等命令，查看CPU的iowait等待时间，以得到系统是否存在I/O性能问题的准确信息。

 

缓存

读缓存：每秒钟从磁盘读取到缓存的块，>90%表示糟糕I/O的可能性

写缓存：每秒钟从缓存写入磁盘的块，<70%表示糟糕的I/O的可能性、

 

运行队列和交换队列：

运行队列的（runq-sz）大于4，或者交换队列（swpq-sz）大于5，说明可能出现问题

 

分页/交换：频繁的分页和交换，说明了I/O问题。

 

$iostat -x 1

Linux 2.6.33-fukai (fukai-laptop)          _i686_    (2 CPU)

avg-cpu: %user   %nice %system %iowait  %steal  %idle

          5.47    0.50    8.96  48.26    0.00   36.82

 

Device:         rrqm/s   wrqm/s    r/s     w/s   rsec/s  wsec/s avgrq-sz avgqu-sz  await  svctm  %util

sda               6.00   273.00  99.00    7.00  2240.00 2240.00    42.26     1.12  10.57   7.96  84.40

sdb               0.00     4.00   0.00  350.00     0.00 2068.00     5.91     0.55   1.58   0.54  18.80

rrqm/s:          每秒进行 merge 的读操作数目。即delta(rmerge)/s

wrqm/s:        每秒进行 merge 的写操作数目。即delta(wmerge)/s

r/s:         每秒完成的读 I/O 设备次数。即delta(rio)/s

w/s:         每秒完成的写 I/O 设备次数。即delta(wio)/s

rsec/s:          每秒读扇区数。即delta(rsect)/s

wsec/s:            每秒写扇区数。即delta(wsect)/s

rkB/s:         每秒读K字节数。是 rsect/s的一半，因为每扇区大小为512字节。(需要计算)

wkB/s:   每秒写K字节数。是 wsect/s 的一半。(需要计算)

avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)

avgqu-sz: 平均I/O队列长度。即delta(aveq)/s/1000 (因为aveq的单位为毫秒)。

await:    平均每次设备I/O操作的等待时间 (毫秒)。即delta(ruse+wuse)/delta(rio+wio)

svctm:    平均每次设备I/O操作的服务时间 (毫秒)。即delta(use)/delta(rio+wio)

%util:     一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即delta(use)/s/1000 (因为use的单位为毫秒)

 

如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

idle小于70% IO压力就较大了,一般读取速度有较多的wait.

同时可以结合vmstat 查看IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。

avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小.如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲，读定速度是这个来决定的。

 

svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator算法，优化应用，或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

 

不错的例子.(I/O 系统 vs. 超市排队)

 

举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队排了。还有就是收银员的速度了，如果碰上了连钱都点不清楚的新手，那就有的等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。

 

I/O 系统也和超市排队有很多类似之处:

 

r/s+w/s                                        类似于交款人的总数

平均队列长度(avgqu-sz)         类似于单位时间里平均排队人的个数

平均服务时间(svctm)              类似于收银员的收款速度

平均等待时间(await)               类似于平均每人的等待时间

平均I/O数据(avgrq-sz)           类似于平均每人所买的东西多少

I/O 操作率(%util)                      类似于收款台前有人排队的时间比例。

 

我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。

 

# iostat -x 1

avg-cpu: %user %nice %sys %idle

16.24 0.00 4.31 79.44

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

/dev/cciss/c0d0

0.00 44.90 1.02 27.55 8.16 579.59 4.08289.80 20.57 22.35 78.21 5.00 14.29

上面的 iostat 输出表明：每秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体(w:r = 27:1)。

 

平均每次设备 I/O 操作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上 78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是同时发出的，那么平均等待时间可以这样计算:

 

平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + … + 请求总数-1) / 请求总数

 

应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms，和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

 

每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个左右)，这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。

 

一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。

 

delta(ruse+wuse)/delta(io)= await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 =2232.8，表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35。

 

iostat      -d-k 1 10         #查看TPS和吞吐量信息

iostat      -d-x -k 1 10       #查看设备使用率（%util）、响应时间（await）

iostat      -c1 10           #查看cpu状态

 

IO性能主要用到的工具如下：

1.      Sar

sar –d  5 2>sar_io.log

%util:>50,说明设备I/O忙

 

2.      Ipstat

 

3.      Vmstat

 

4.      iostat -x

 

5.4 Network性能分析工具：

         一个应用系统出现如下情况时，我们认为该系统存在网络性能问题：

         网络接口的吞吐量小于期望值；

         出现大量的丢包现象；

         出现大量的冲突现象。

1.      sar

sar命令使用-n选项可以汇报网络相关信息，可用的参数包括：DEV、EDEV、SOCK和FULL。

如果你使用DEV关键字，那么sar将汇报和网络设备相关的信息，如lo，eth0或eth1等，例如：

$ sar -nDEV 1 2

Linux2.6.9      10/17/2009

 

12:10:49 AM  IFACE  rxpck/s  txpck/s   rxbyt/s   txbyt/s  rxcmp/s   txcmp/s  rxmcst/s

IFACE：就是网络设备的名称；

rxpck/s：每秒钟接收到的包数目

txpck/s：每秒钟发送出去的包数目

rxbyt/s：每秒钟接收到的字节数

txbyt/s：每秒钟发送出去的字节数

rxcmp/s：每秒钟接收到的压缩包数目

txcmp/s：每秒钟发送出去的压缩包数目

txmcst/s：每秒钟接收到的多播包的包数目

 

如果你使用EDEV关键字，那么会针对网络设备汇报其失败情况，例如：

$ sar -nEDEV 1 3

Linux2.6.9     10/17/2009

 

12:15:06 AM IFACE  rxerr/s   txerr/s    coll/s rxdrop/s  txdrop/s  txcarr/s rxfram/s  rxfifo/s  txfifo/s

rxerr/s：每秒钟接收到的损坏的包的数目

txerr/s：当发送包时，每秒钟发生的错误数

coll/s：当发送包时，每秒钟发生的冲撞(collisions)数（这个是在半双工模式下才有）

rxdrop/s：由于缓冲区满，网络设备接收端，每秒钟丢掉的网络包的数目

txdrop/s：由于缓冲区满，网络设备发送端，每秒钟丢掉的网络包的数目

txcarr/s：当发送数据包时，每秒钟载波错误发生的次数

rxfram/s：在接收数据包时，每秒钟发生的帧对齐错误的次数

rxfifo/s：在接收数据包时，每秒钟缓冲区溢出错误发生的次数

txfifo/s：在发送数据包时，每秒钟缓冲区溢出错误发生的次数

 

如果你使用SOCK关键字，则会针对socket连接进行汇报，例如：

$ sar -nSOCK 1 3

Linux2.6.9       10/17/2009

12:27:29AM    totsck    tcpsck   udpsck    rawsck   ip-frag

12:27:30AM        90        41         4         0         0

12:27:31AM        90        41         4         0         0

12:27:32AM        90        41         4         0         0

Average:           90        41         4         0         0

 

totsck：被使用的socket的总数目

tcpsck：当前正在被使用于TCP的socket数目

udpsck：当前正在被使用于UDP的socket数目

rawsck：当前正在被使用于RAW的socket数目

ip-frag：当前的IP分片的数目

如果你使用FULL关键字，相当于上述DEV、EDEV和SOCK三者的综合。

2.      ifconfig

3.      netstat -s

4.      nfsstat