目录
一．数据库性能
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
958
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
