性能测试--总结（三）--性能定位

最新推荐文章于 2024-04-19 17:03:22 发布

weixin_34273046

最新推荐文章于 2024-04-19 17:03:22 发布

阅读量1.3k

点赞数

文章标签：运维数据库 java

原文链接：http://blog.51cto.com/13693838/2119337

版权

如果响应时间长，需要定位分析：

1，页面诊断图：

1）页面诊断图

页面组件：也称页面元素，指构成页面的组成部分，如文字、视频、音频、动画等。

网页细分图流程：

1，通过查看网页细分图，发现下载时间细分图中占时间比例最大是first buffer 时间。

2，通过查看first buffer 图，发现占该图中时间比例最大一般是server time 服务器时间。

3，网页的大小是网页中所有组件的和。

4，页面细分综合图的读图顺序：在实际项目中，一般是先看默认的第一张（得出时间长在第一次缓冲），再看最后一张（得出时间花费在第一次缓冲的服务器端。

2）页面组件细分图（page component breakdown）

页面中每个元素的平均响应时间占整个页面响应时间的百分比。

3）页面组件细分图（随时间变化）：（page component breakdown over time）

整个测试过程中，任意一秒内页面中每个元素的响应时间。

如在run time 中设置了browser cache ，则页面中的资源文件只在第一次下载，后面的页面响应时间不包括这些元素的时间，这在page component breakdown 中显示不出来，

通过over time图可以看出来。

设置了brower cache ：这个图是，前高后低，后面基本成直线状。

4）页面下载时间细分图（page download time breakdown）

页面中每个元素的响应时间分割图，响应时间被分隔为以下几个部分：

1， DNS resolution（DNS 解析时间）：

浏览器访问网站时，一般用域名，需要DNS服务器把这个域名解析成ip ，这个过程就是域名解析时间。

在局域网内直接使用ip访问，则不存在该时间。

2， connection （连接时间）：

解析出web server的ip地址后，浏览器请求发送到web server ，然后浏览器和web server 之间需要建立一个初始化http连接，服务器需要做2件事：一是建立连接，二是分配进程，

建立该连接的过程就是connection时间。

3， first buffer（第一次缓冲时间）

显示从初始HTTP请求到成功收回来自web 服务器的第一个数据包为止所经过的时间。

第一次缓冲时间度量是很好的web服务器延迟和网络滞后指示器。

注意：由于缓冲区大小最大为8k ，因此第一次缓冲时间可能也是完成元素下载所需的时间。

4， receive（接收时间）

从浏览器收到第一个字节起，直到成功收到最后一个字节所经历的时间，可以和组件大小结合，判断网络质量。

1）和客户端关系：如果服务器发送过来大量的数据包，但是客户端接收有问题，甚至无法全部接收。

2）和服务器也有关系：服务器可能发送慢。

3）如果receive 时间过长，先查看网络是否存在问题，在看客户端问题（页面上包括很多图片，而且图片很大，最大达163k ，）这样就会造成receive时间过长。分析：一张图片163k ，

相当于0.2M，当1000用户并发，则0.2M*1000=200M , 网速一般是10Mb（1Byte = 8 bits ），200M /(10Mb/8)=150s 左右，给被测系统造成很大的性能问题。

使用bmp类型图片，不可以。因为bmp基于无损压缩，图片中每个像素都是24bits，则1024*798*24bits=所以这种类型的图片无论是一张白纸还是一张色彩斑斓的图片，大小相似。都很大。

JPG----基于有损压缩，图片中存储像素直接的色彩差值，即如果一张白纸会比色彩图片的大小小很多。

5， SSL handshaking（ssl握手时间），

显示建立SSL连接所用的时间。此时刻后，客户端和服务器之间的所有通信都被加密。

SSL握手度量仅适用于HTTPS通信。

6， client（客户端时间） ，

请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的处理时间或者客户端其他方面引起的延迟。

7， FTP authentication（FTP验证时间） ，

仅限于FTP服务器测试

8， error（错误时间）

从发送HTTP请求，到web server 返回一个HTTP错误信息需要的时间

5）页面下载时间细分图（随时间变化）：（page download time breakdown over time）

在整个测试过程中，任意一秒内页面中每个元素的响应时间分割图。

6）第一次缓冲细分时间图

Time to first buffer 第一次缓冲时间：

1，网络时间：定义为从发送第一个http请求那一刻直到收到确认为止，所经过的平均时间。

2，服务器时间：定义为从收到初始HTTP请求确认直到成功收到来自web服务器的第一次缓冲为止，所经过的平均时间。

3，注意：由于要从客户端测定服务器时间，因此，发送初始HTTP请求到发送第一个缓冲区这一段时间内如果网络性能发生变化，则网络时间可能会影响此测定。

因此，所显示的服务器时间是一个估计值，可能不太准备，因为包含了回来的网络时间。

7）第一次缓冲细分时间图（随时间变化）

8）已下载组件大小图（downloaded component size KB）

页面中每个元素的大小KB ，通过它可以直接看出那些组件比较大，并需要进一步优化，以提高性能。

9）每张图和随时间变化图的区别：

--非时间变化图注重的是宏观的表现。

--随时间变化图注重的是元素在测试过程中的微观细节表现。

--一般测试中查看的顺序：先宏观了解，再微观研究细节。

2， LR监视的性能计数器

1， Processor

%processor time ：处理器执行非空闲线程的时间百分比，如果该值持续超过95% ，怀疑瓶颈是CPU 。

处理器时间的阈值（正常范围）：对于一个系统而言，如果%processor time 的平均值小于85% ，则一般没有问题。如果其平均值超过85% 或者其值持续超过95% ，则怀疑CPU瓶颈。

对于阈值，一般不同公司不一样，不同项目也不一致，一般情况不超过85% 都视为正常。

如果%processor time 偶然走高，达到100% ，要看其平均值，一般没问题。

processor/%user time 是指系统非核心操作消耗的cpu时间，如果该值较大，可以考虑是否通过算法优化等方法降低该值。如果服务器是数据库服务器，该值大的原因很可能是数据库的排序或是函数操作消耗了过多的cpu时间，此时可以考虑对数据库进行优化。

2， System

Processor queue length ：线程单元中的处理器队列的即时长度，所有处理器都使用单一队列（线程在该队列中等待处理器进行循环），此长度不包含当前正在执行的线程。

性能测试过程中，双核处理器一般视为2个CPU 。

处理器队列的阈值是：小于等于n+1，其中n是处理器的个数。

3， memory

要监视内存不足的状况，请从以下的对象计数器开始：

1） Available Mbytes ：当前系统的可用内存（以M为单位），至少要有1%的物理内存。如果系统的可用内存小于1% ，则有可能内存存在瓶颈。

2）当处理器向内存指定位置请求一页面数据或代码出现错误，就构成一个page fault 。

如果该页在内存的其他位置找到，该错误被称为软错误，用transition fault / sec 计数器衡量。

如果该页必须从磁盘重新读取时，被称为硬错误，许多处理器可以在存在大量软错误的情况继续操作，但是硬错误可能导致明细拖延。一般来讲，硬错误（单位个数）的阈值为内存1%，即2g内存，

硬错误不要超过20个，否则要引起注意。

3） page fault /sec 是处理器每秒钟处理的错误页，包括软硬错误。

4） page reads /sec 是为了解决硬错误，从磁盘读取的次数。如果page reads/sec 比率持续大于物理内存1%，表示可能内存不足。

5） pages/sec 是指为解析硬错误，从磁盘读取或写入磁盘的页数。

4， system

context switches / sec ：指计算机上的所有处理器，全都从一个线程转换到另一个线程的综合速率。

为了避免错误，必须保证在恢复一个任务之后，其上下文环境跟即将挂起前是一样的。操作系统内核有责任通过在任务挂起前保存其上下文来确保这种情况。当任务恢复时，

保存的上下文就被操作系统内核恢复到先前的执行情况。保存一个被挂起的任务的上下文并在任务恢复时恢复其上下文的处理过程就叫上下文切换context switching 。

5， physical disk

%disk time ：指所选磁盘驱动器忙于为读或写请求提供服务所用的时间的百分比。磁盘的使用率。

Avg.DISK queue length ：指读取或写入请求（为所选磁盘在实例间隔中队列）的平均数，该值不应该超过磁盘数的1.5-2 倍，要提高性能，可增加磁盘。

Disk reads/sec , Disk writes/ sec ：物理磁盘上每秒钟磁盘读写次数，两者相加，应小于磁盘设备最大容量。该值如果超过几十M ，或者上百M, 则考虑磁盘瓶颈。

avg.disk sec/read ：以秒为计算在磁盘上读取数据所需要的平均时间。

avg.disk sec/write ：以秒为计算在磁盘上写入数据所需要的平均时间。

性能调优的原则：尽量减少磁盘IO ，因为磁盘IO 如果较大，会严重影响系统的性能。

average disk sec/transfer：以秒计算的在此盘上写入数据所需的平均时间。小于15ms 是优秀，15-30ms良好，30-60ms可接受，60ms以上需要考虑更换硬盘。

只有%disk time值较大，其他值都比较适中，则硬盘可能会是瓶颈。若几个值都比较大，且数值持续超过80%，则可能是内存泄漏。

如何确定磁盘瓶颈？

下面假设在有4块硬盘的RAID5中观察到的Physical Disk性能对象的部分值：（如何查看电脑有几块硬盘？？通过我的电脑---属性---设备管理---磁盘驱动器，有几个就是几个磁盘）

Avg. Disk Queue Length 12 队列长度

Avg. Disk Sec/Read .035 读数据所用时间ms

Avg. Disk Sec/Write .045 写数据所用时间ms

Disk Reads/sec 320 每秒读数据量

Disk Writes/sec 100 每秒写数据量

Avg. DiskQueue Length，12/4=3，每块磁盘的平均队列建议不超过2。

Avg. Disk Sec/Read一般不要超过11～15ms。

Avg. Disk Sec/Write一般建议小于12ms。

从上面的结果，我们看到磁盘本身的I/O能力是满足我们的要求的，原因是因为有大量的请求才导致队列等待，这很可能是因为你的SQL语句导致大量的表扫描所致。在进行优化后，

如果还是不能达到要求，下面的公式可以帮助你计算使用几块硬盘可以满足这样的并发要求：

Raid 0 -- I/Os per disk = (reads +writes) / number of disks

Raid 1 -- I/Os per disk = [reads +(2 * writes)] / 2

Raid 5 -- I/Os per disk = [reads +(4 * writes)] / number of disks

Raid 10 -- I/Os per disk = [reads +(2 * writes)] / number of disks

我们得到的结果是：(320+4*100)/4=180，这时你可以根据公式①来得到磁盘的正常I/O值。假设现在正常I/O计数为125，为了达到这个结果：720/125=5.76。就是说要用6块磁盘才能达到这样的要求。

但是上面的Disk Reads/sec和Disk Writes/sec是个很难正确估算的值。因此只能在系统比较忙时，大概估算一个平均值，作为计算公式的依据。另一个是你很难从客户那里得到Seek time、

Rotational latency参数的值，这也只能用理论值125进行计算。

6， network interface

byte total /sec ：为发送和接收字节的速率，包括帧字符在内。

判断网络连接速率是否是瓶颈，可以用该计数器的值和目前网络的宽带比较。该值的阈值：该值* 8 /1024/1024 换算成M 之后，再与网络宽带的一半进行比较，如果小于宽带的一半，

则一般认为网络没有瓶颈。 1Byte = 8bits ，而宽带的单位为bits 。

windows系统硬件瓶颈

1，判断cpu瓶颈：

1）如果processor queue length 显示的队列长度保持不变（>=n+1）个并且处理器的利用率%processor time 超过90% ，那么很有可能存在处理器瓶颈。

2）如果发现processor queue length 的长度超过n + 1 ，而处理器的利用率却一直很低，那么或许更应该解决处理器阻塞问题，这时处理器性能一般不是瓶颈。

3） %processor time 平均值大于95% ， processor queue length 大于n+ 1 ，通过此过程可以判断cpu存在瓶颈，需要扩展。

2，判断内存泄漏的问题

如果发生内存泄漏，process/ private bytes 计数器和 process / working set 计数器的值往往会升高，同时avaiable Mbytes 的值会下降。内存泄漏应该是一个长时间的测试过程来检验的。

process/private bytes ：指不能与其他处理共享的、已分配的当前字节数。当内存泄漏时，该值会增高。

2.1 内存不足

memory/available mbytes 较小时内存可能不足了。pages/sec持续高于几百，可能内存有问题，也可能是运行使用内存映射文件的程序所致。page faults/sec每秒发生页面失效的次数，页面失效次数越多，系统向内存读取的次数越多，此时还需看pages read /sec的计数值，如果该值超过5，则可能内存有问题。

3，判断磁盘瓶颈：

Avg. Disk Queue Length，12/4=3（队列/磁盘个数），每块磁盘的平均队列建议不超过2。

Avg. Disk Sec/Read一般不要超过11～15ms。

Avg. Disk Sec/Write一般建议小于12ms。

如果memory的pages read/sec 很低，同时physical Disk / %disk time 和 physical Disk / average disk queue length 的值很高，则可能有磁盘瓶颈。但是如果 physical Disk / average disk queue length 增加的同时memory的pages read/sec 没有降低，则是内存不足。

4，判断网络瓶颈：

byte total /sec ：该值* 8 /1024/1024 换算成M 之后，再与网络宽带的一半进行比较，如果小于宽带的一半，则一般认为网络没有瓶颈。

processor / %DPC time，cpu消耗在网络处理上的时间，越低越好，在多处理器系统中，如果该值大于50%并且processor / %processor time 值非常高，则考虑加一个网卡提高性能。

5，判断应用程序瓶颈

吞吐量降低， cpu使用率高， context switches /sec 已经持续超过15000 ，说明程序的上下文切换比较频繁，需要调优。

Linux 系统硬件监控：

cpu，内存和磁盘的关系：cpu取数据时，cpu发出指令先去内存找，内存找不到再去磁盘找，找到后从磁盘读到内存然后加载到cpu。cpu是执行任务，内存和磁盘是存储的。他们三个是相互制约相互依赖。所以有瓶颈时需要综合考虑。

例如，cpu很高可能是内存导致的，像垃圾回收，内存不足时需要消耗cpu做垃圾回收。

运行队列：一核cpu在同一时刻只能处理一个任务。例如来了一个线程，处于准备运行状态，cpu把它取出来执行。如果来了多个可运行状态的线程，这一个核的cpu只能执行一个，其他需要去排队，这就形成一个队列。排队的线程越多对cpu的压力越大。可运行状态的线程在排队时在不断抢夺cpu资源。

在不同工具里运行队列名字不一样：top里load average 就是队列数，三个时间段的平均值。vmstat里r列是队列数。spotlight里是queue length 。

context switches上下文切换：cpu处理排队的线程是在不断的切换的，例如执行第一个线程一分钟，然后切换到第二个线程二分钟，这样不断切换中，让大家感觉到cpu都在处理所有线程。

interrupts中断：就是cpu正在处理某个线程时被打断，就是优先级更高。中断一般都是硬件引起的，比如鼠标和键盘，优先级最高。

cpu利用率：在windows中有个线程是sysrem idel process，就是cpu空闲利用率，这个越高就是cpu越闲。cpu利用率就是在一小时内有50分钟在处理这个线程，利用率就是50/60。在多核处理器中我们会看到多个线程都是很高的利用率，是因为多核都在处理。

压测时cpu很闲也有问题。说明cpu压不上去。

影响性能因素	好	坏	糟糕
CPU	user% + sys%< 70%	user% + sys%= 85%	user% + sys% >=90%
内存	Swap In（si）＝0 Swap Out（so）＝0	Per CPU with 10 page/s	More Swap In & Swap Out
磁盘	iowait % < 20%	iowait % =35%	iowait % >= 50%

1）nmon工具

Sys_summ页，为server资源使用率汇总

我们需求的主要数据为cpu，mem，io和net。例如以下图：

Cpu使用率分为三部分，系统、用户和等待。cpu使用率100%的情况，假设系统进程本身占领大部分cpu资源，可考虑系统是否存在过多僵尸进程或者系统进程存在死循环等原因；假设用户进程占用大量cpu资源，可考虑被压系统是否压力过大。或者被压系统存在大量运算等消耗cpu资源的操作。

cpu_summ页， cup的个数，及使用情况：

Ø Mem页，是server内存使用率的概况。

内存的总数，内存剩余，内存swap的变化数。 cached 或是 buffer 的数。

BBBP页：

总括cpu ，内存，磁盘，网络的概况。

Ø Disk_SUMM页。磁盘

Disk Read 每秒读的千字节数目图中为蓝色部分

Disk Write 每秒写的千字节数目图中为红色部分

IO/sec 每秒进行的IO数（一次IO就是控制操作一次读或写。IO块就是读或写的大小）。图中为上方黑色的线，报告中写的是这个參数的值

可以通过数字部分计算平均值。

Ø Net页网络

1、首先，使用# ifconfig查看Linux系统中的网卡名称，有的是eth0，有的是em1，以查看结果为准，下图为em1

2、先试试Linux系统中有没有安装ethtool工具，没有的话，下载ethtool工具，安装到系统。然后使用# ethtool em1，查看网络带宽，如下如图是1000Mb/s。

3，查看分析文件中NET sheet页中total-read和total-write的绝对值之和，如下图：total-read和total-write的绝对值之和约为82000KB/s，网络带宽是1000Mb/s,所以需要转换：

82000KB/s * 8=656000 Kb/s / 1024 =640Mb/s，与网卡带宽1000Mb/s比较即可。

Total read 每秒接收到的千字节的数目，如图蓝色部分

Total write 每秒发送的千字节的数目，如图红色部分

网络=Total read + Total write

网络的指标一般要依据设备来确定，百兆网卡的意思是每秒可以传输的网络流量是100Mbps,即最大的下载速度是12.5MB/s，一般server是千兆网卡，即125MB/s

2）vmstat

procs ：

r 列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。
b 列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。

memory

swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0，或者比较大，比如超过了100m，只要si、so的值长期为0，系统性能还是正常。

free 当前的空闲页面列表中内存数量(k表示) ，如果剩余内存不足，也会导致系统性能问题。

buff 作为buffer cache的内存数量，一般对块设备的读写才需要缓冲。

cache: 作为page cache的内存数量，一般作为文件系统的cache，如果cache较大，说明用到cache的文件较多，如果此时IO中bi比较小，说明文件系统效率比较好。

swap

si 由内存进入内存交换区数量。

so由内存交换区进入内存数量。

swap下的si、so的值长期不为0，表示系统内存不足。需增加系统内存。

bi 从块设备读入数据的总量（读磁盘）（每秒kb）。

bo 块设备写入数据的总量（写磁盘）（每秒kb）

这里我们设置的bi+bo参考值为1000，如果超过1000，而且wa值较大应该考虑均衡磁盘负载，可以结合iostat输出来分析。

system 显示采集间隔内发生的中断数

in 列表示在某一时间间隔中观测到的每秒设备中断数。

cs列表示每秒产生的上下文切换次数，如果超过15000考虑程序上下文切换频繁；或者当 cs 比磁盘 I/O 和网络信息包速率高得多，都应进行进一步调查。

cpu 表示cpu的使用状态
us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，需要考虑优化用户的程序。还要跟r一起结合分析。占用cpu高，同时r队列数长期超过cpu内核数，考虑cpu不足。

us是用户态cpu，sy是内核态cpu，上下文切换多就是sy高。基于网络环境下，网络环境有io引起中断，需要消耗sy，所以us：sy最好是7:3。

sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足。
wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%，如果wa超过30%，说明IO等待严重，这可能是磁盘大量随机访问造成的，也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。
id 列显示了cpu处在空闲状态的时间百分比。越大说明cpu越空闲。

id 是真空闲， wa 是等待io的空闲就是一直等待io读写。

3）top

top：
21:45:11 — 当前系统时间
0 days, 4:54 — 系统已经运行了4小时54分钟（在这期间没有重启过）
2 users — 当前有2个用户登录系统
load average:0.24, 0.15, 0.19 — load average后面的三个数分别是5分钟、10分钟、15分钟的负载情况。

load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。

Tasks ：

任务（进程），系统现在共有144个进程，其中处于运行中的有1个，143个在休眠（sleep），stoped状态的有0个，zombie状态（僵尸）的有0个。

CPU:

1.3% us — 用户空间占用CPU的百分比。
1.0% sy — 内核空间占用CPU的百分比。
0.0% ni — 改变过优先级的进程占用CPU的百分比
97.3% id — 空闲CPU百分比
0.0% wa — IO等待占用CPU的百分比
0.3% hi — 硬中断（Hardware IRQ）占用CPU的百分比
0.0% si — 软中断（Software Interrupts）占用CPU的百分比

Mem：

使用中的内存总量（used）指的是现在系统内核控制的内存数，空闲内存总量（free）是内核还未纳入其管控范围的数量。纳入内核管理的内存不见得都在使用中，还包括过去使用过的现在可以被重复利用的内存，内核并不把这些可被重新使用的内存交还到free中去，因此在linux上free内存会越来越少，但不用为此担心。

swap：

交换分区的used，如果这个数值在不断的变化，说明内核在不断进行内存和swap的数据交换，这是真正的内存不够用了。

各进程（任务）的状态监控:

PID：进程ID，进程的唯一标识符

USER：进程所有者的实际用户名。

PR：进程的调度优先级。这个字段的一些值是'rt'。这意味这这些进程运行在实时态。

NI：进程的nice值（优先级）。越小的值意味着越高的优先级。负值表示高优先级，正值表示低优先级

VIRT：进程使用的虚拟内存。进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES

RES：驻留内存大小。驻留内存是任务使用的非交换物理内存大小。进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA

SHR：SHR是进程使用的共享内存。共享内存大小，单位kb

S：这个是进程的状态。它有以下不同的值:

· D - 不可中断的睡眠态。

· R – 运行态

· S – 睡眠态

· T – 被跟踪或已停止

· Z – 僵尸态

%CPU：自从上一次更新时到现在任务所使用的CPU时间百分比。

%MEM：进程使用的可用物理内存百分比。

TIME+：任务启动后到现在所使用的全部CPU时间，精确到百分之一秒。

COMMAND：运行进程所使用的命令。进程名称（命令名/命令行）

还有许多在默认情况下不会显示的输出，它们可以显示进程的页错误、有效组和组ID和其他更多的信息。

第一行后面的三个值是系统在之前1、5、15的平均负载，也可以看出系统负载是上升、平稳、下降的趋势，当这个值超过CPU可执行单元的数目，则表示CPU的性能已经饱和成为瓶颈了。

第二行统计了系统的任务状态信息。running很自然不必多说，包括正在CPU上运行的和将要被调度运行的；sleeping通常是等待事件(比如IO操作)完成的任务，细分可以包括interruptible和uninterruptible的类型；stopped是一些被暂停的任务，通常发送SIGSTOP或者对一个前台任务操作Ctrl-Z可以将其暂停；zombie僵尸任务，虽然进程终止资源会被自动回收，但是含有退出任务的task descriptor需要父进程访问后才能释放，这种进程显示为defunct状态，无论是因为父进程提前退出还是未wait调用，出现这种进程都应该格外注意程序是否设计有误。

第三行CPU占用率根据类型有以下几种情况：
　　(us) user: CPU在低nice值(高优先级)用户态所占用的时间(nice<=0)。正常情况下只要服务器不是很闲，那么大部分的CPU时间应该都在此执行这类程序
　　(sy) system: CPU处于内核态所占用的时间，操作系统通过系统调用(system call)从用户态陷入内核态，以执行特定的服务；通常情况下该值会比较小，但是当服务器执行的IO比较密集的时候，该值会比较大
　　(ni) nice: CPU在高nice值(低优先级)用户态以低优先级运行占用的时间(nice>0)。默认新启动的进程nice=0，是不会计入这里的，除非手动通过renice或者setpriority()的方式修改程序的nice值
　　(id) idle: CPU在空闲状态(执行kernel idle handler)所占用的时间
　　(wa) iowait: 等待IO完成做占用的时间
　　(hi) irq: 系统处理硬件中断所消耗的时间
　　(si) softirq: 系统处理软中断所消耗的时间，记住软中断分为softirqs、tasklets(其实是前者的特例)、work queues，不知道这里是统计的是哪些的时间，毕竟work queues的执行已经不是中断上下文了
　　(st) steal: 在虚拟机情况下才有意义，因为虚拟机下CPU也是共享物理CPU的，所以这段时间表明虚拟机等待hypervisor调度CPU的时间，也意味着这段时间hypervisor将CPU调度给别的CPU执行，这个时段的CPU资源被”stolen”了。这个值在我KVM的VPS机器上是不为0的，但也只有0.1这个数量级，是不是可以用来判断VPS超售的情况？
　　CPU占用率高很多情况下意味着一些东西，这也给服务器CPU使用率过高情况下指明了相应地排查思路：
　　(a) 当user占用率过高的时候，通常是某些个别的进程占用了大量的CPU，这时候很容易通过top找到该程序；此时如果怀疑程序异常，可以通过perf等思路找出热点调用函数来进一步排查；
　　(b) 当system占用率过高的时候，如果IO操作(包括终端IO)比较多，可能会造成这部分的CPU占用率高，比如在file server、database server等类型的服务器上，否则(比如>20%)很可能有些部分的内核、驱动模块有问题；
　　(c) 当nice占用率过高的时候，通常是有意行为，当进程的发起者知道某些进程占用较高的CPU，会设置其nice值确保不会淹没其他进程对CPU的使用请求；
　　(d) 当iowait占用率过高的时候，通常意味着某些程序的IO操作效率很低，或者IO对应设备的性能很低以至于读写操作需要很长的时间来完成；
　　(e) 当irq/softirq占用率过高的时候，很可能某些外设出现问题，导致产生大量的irq请求，这时候通过检查/proc/interrupts文件来深究问题所在；
　　(f) 当steal占用率过高的时候，黑心厂商虚拟机超售了吧！

第四行和第五行是物理内存和虚拟内存(交换分区)的信息:
　　total = free + used + buff/cache，现在buffers和cached Mem信息总和到一起了，但是buffers和cached
Mem的关系很多地方都没说清楚。其实通过对比数据，这两个值就是/proc/meminfo中的Buffers和Cached字段：Buffers是针对raw disk的块缓存，主要是以raw block的方式缓存文件系统的元数据(比如超级块信息等)，这个值一般比较小(20M左右)；而Cached是针对于某些具体的文件进行读缓存，以增加文件的访问效率而使用的，可以说是用于文件系统中文件缓存使用。
　　而avail Mem是一个新的参数值，用于指示在不进行交换的情况下，可以给新开启的程序多少内存空间，大致和free + buff/cached相当，而这也印证了上面的说法，free + buffers + cached Mem才是真正可用的物理内存。并且，使用交换分区不见得是坏事情，所以交换分区使用率不是什么严重的参数，但是频繁的swap in/out就不是好事情了，这种情况需要注意，通常表示物理内存紧缺的情况。

最后是每个程序的资源占用列表，其中CPU的使用率是所有CPU core占用率的总和。通常执行top的时候，本身该程序会大量的读取/proc操作，所以基本该top程序本身也会是名列前茅的。
　　top虽然非常强大，但是通常用于控制台实时监测系统信息，不适合长时间(几天、几个月)监测系统的负载信息，同时对于短命的进程也会遗漏无法给出统计信息。

4）iostat

iostat -x 1 5

常关注的参数：

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

如%idle小于70%，I/O的压力就比较大了，说明读取进程中有较多的wait。

avgqu-sz: 发送给设备I/O请求的等待队列平均长度，对于单个磁盘如果值>1表明设备饱和，对于多个磁盘阵列的逻辑磁盘情况除外；
await(r_await、w_await): 平均每次设备I/O请求操作的等待时间(ms)，包含请求排列在队列中和被服务的时间之和；
svctm: 发送给设备I/O请求的平均服务时间(ms)，如果svctm与await很接近，表示几乎没有I/O等待，磁盘性能很好，否则磁盘队列等待时间较长，磁盘响应较差；
%util: 设备的使用率，表明每秒中用于I/O工作时间的占比，单个磁盘当%util>60%的时候性能就会下降(体现在await也会增加)，当接近100%时候就设备饱和了，但对于有多个磁盘阵列的逻辑磁盘情况除外；
还有，虽然监测到的磁盘性能比较差，但是不一定会对应用程序的响应造成影响，内核通常使用I/O asynchronously技术，使用读写缓存技术来改善性能，不过这又跟上面的物理内存的限制相制约了。

5）free

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

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

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

6）sar

active/s：本地发起的TCP连接，比如通过connect()，TCP的状态从CLOSED -> SYN-SENT
passive/s：由远程发起的TCP连接，比如通过accept()，TCP的状态从LISTEN -> SYN-RCVD
retrans/s(tcpRetransSegs)：每秒钟TCP重传数目，通常在网络质量差，或者服务器过载后丢包的情况下，根据TCP的确认重传机制会发生重传操作
isegerr/s(tcpInErrs)：每秒钟接收到出错的数据包(比如checksum失败)

noport/s(udpNoPorts)：每秒钟接收到的但是却没有应用程序在指定目的端口的数据报个数
idgmerr/s(udpInErrors)：除了上面原因之外的本机接收到但却无法派发的数据报个数
当然，这些数据一定程度上可以说明网络可靠性，但也只有同具体的业务需求场景结合起来才具有意义。

7）ping：通过ping判断服务器的网络是否畅通。

写一个bat文件，压测的时候执行即可。压测完成后查看最大值= ，如果超过100ms，说明网络延迟比较大：

3，数据库

ORACLE

11g的数据库可自动分配SGA 和 PGA:

--查看设置情况：

Select name,value from v$parameter where name in('pga_aggregate_target','sga_target') union select 'maximum PGA allocated' as name,TO_CHAR(value) as value from

v$pgastat where name='maximum PGA allocated';

--估测 memory_target 值大小：

select sga.value + GREATEST(pga.value,max_pga.value) as memory_target from (select to_number(value) as value from v$parameter where name='sga_target') sga,(select

to_number(value) as value from v$parameter where name='pga_aggregate_target') pga,

(select value from v$pgastat where name='maximum PGA allocated') max_pga;

--设置自动管理PGA 和 SGA : 只要设置这三个值并且 PGA_AGGREGATE_TARGET=0 和 SGA_TARGET=0 ，内存就可自动分配了。

alter system set memory_target=5G scope=spfile; --重启后如果再想修改memory_target，只要修改这句话即可，不用再重启。

alter system set PGA_AGGREGATE_TARGET=0 scope=spfile;

alter system set SGA_TARGET=0 scope=spfile;

--重启

shutdow immediate;

startup;

1）检查SGA 和 PGA的值：

SQL>show parameter sga； sga 一般是物理内存*0.8*0.6；

SQL>show parameter pga； pga 一般是物理内存*0.8*0.4；

手动修改Oracle数据库SGA和PGA

SGA的大小：一般物理内存20%用作操作系统保留，其他80%用于数据库。
SGA普通数据库可以分配40%-60%之间，PGA可以分配20%-40%之间。
1、以dba身份登录
并查看SGA信息：
SQL>show parameter sga；
查看PGA信息：

SQL>show parameter pga；

2、修改sga_target
SQL>alter system set sga_target=436M;

3、修改sga_max_size
SQL> alter system set sga_max_size=436M scope=spfile;

4、重启数据库使其生效：
SQL>shutdown immediate;
##注意，重启前一定先完成上述两部操作，且sga_target不得大于sga_max_size，一般保持两者相等.否则可能导致数据库无法启动。

SQL>startup

5、查看SGA是否生效：
SQL>show parameter sga
NAME TYPE VALUE
------------------------------------ ----------- -----
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 436M
sga_target big integer 436M

另外查看数据库的常用几种参数：

2）--查看ORACLE最大游标数

SQL> show parameter open_cursors;

3）--查看当前打开的游标数目

SQL> select count(*) from v$open_cursor;

4）--查询数据库进程数

sql>show parameter process; 设置的进程数

sql>select count(*) from v$process; 使用的进程数。

5）--数据库的连接数设置

show parameter session；设置的连接数。

Select * from v$session; 使用的连接数。

6)AWR报告分析

1，看概况。

2，先生成一份基准版的awr，然后在压测过程中生成的awr，与基准的数据对比。

3，关注top5 事件。

4，看sql执行时间长。

5，关注等待事件。

https://blog.51cto.com/13693838/2333724

6）spotlight-on-oracle :https://www.cnblogs.com/what-/p/7353621.html 直观的监视数据库。

MYSQL监控

4，Jprofile监控中间件

注意：在该视图下方的Recorded Objects子视图可以记录对象，从而查看类在一段时间里的总共实例数、GC数和活动数，但是在使用这些功能时会导致系统的性能严重降低，

例如：没开此功能时，1000并发响应时间为1s，开此功能后500并发时响应时间才能达到1s，因此只有当存在内存泄漏时才开启该功能。

在用LoadRunner疲劳测试时，在稳压期间，良好的系统内存占用应该是比较稳定，并且GC后下坡的幅度也应该比较一致，比如：前次GC释放200M，下次GC大致也是200M，这是一般规律，具体在分析时或有不同，性能分析人员应灵活运用。

当发现GC后回收的力度越来越小，则说明很有可能存在内存泄漏，这时需要开启该视图的Memory Views视图的Recorded Objects子视图。

1，堆和非堆

QQ截图20180531104045.png

堆：

包括：新生代（年轻代，survivor（幸存者区））和老年代。

年轻代：新创建的对象放在eden。

survivor：在eden space 中经过垃圾回收后，仍然存活的，放在survivor space 。survivor有两个。

老年代：新生代经过多次垃圾回收，仍然存活的对象；或者是新生代分配不了内存的大对象会直接进入老年代。当年老代放满之后，虚拟机进行垃圾回收称为full GC .

设置大小：-xms ，-xmx ，-xmn年轻代大小。

如果不足：报OutOfMemoryError： Java heap space 堆溢出。

非堆：

code cache 代码缓存区：

perm gen：永久区。-xx:permsize 最小值， -xx:maxpermsize 最大值。如果不足：报java.lang.outofmemoryerror:permgen space 错误。

2，JProfiler 自带的例子如下：模拟了内存泄露和线程阻塞的场景：
具体源码参考: /jprofiler install path/demo/bezier

(图12 )

(图13 Leak Memory 模拟内存泄露, Simulate blocking 模拟线程间锁的阻塞)

,1）判定内存泄漏

系统的内存消耗过多往往有以下几种原因：

1. 频繁创建Java对象，如：数据库查询时，没分页，导致查出表中所有记录；
2. 存在大对象，如：读取文件时，不是边读边写而是先读到一个byte数组，这样如果读取的文件时50M则仅此一项操作就会占有JVM50M内存。
3. 存在内存泄漏，导致已不被使用的对象不被GC回收，从而随着系统使用时间的增长，内存不断受到解压，最终OutOfMemory。

分析内存泄漏：

1. 在**Telemetries-> Memory**视图中你会看到大致如下图的场景(在看的过程中可以间隔一段时间去执行Run GC这个功能)：看到下图蓝色区域,老生代在gc后(**波谷**)内存的大小在慢慢的增加(理想情况下，这个值应该是稳定的)

经过长时间的测试之后，正常情况下，这个图形应该是平稳波动。如果有内存泄漏，波动的曲线逐渐升高。

2，在 Live memory->Recorded Objects 中点击**record allocation data**按钮，开始统计一段时间内创建的对象信息。执行一次**Run GC**后看看当前对象信息的大小，并点击工具栏中**Mark Current**按钮(其实就是给当前对象数量打个标记。执行一次Run GC，然后再继续观察; 执行一次Run GC，然后再继续观察...。最后看看哪些对象在不断GC后，数量还一直上涨的。最后你看到的信息可能和下图类似

(图15 绿色是标记前的数量，红色是标记后的增量)

在Heap walker中分析刚才记录的对象信息（heap walker 会占用一部分jvm，所以要保证jvm内存分配足够）：

(图16)

(图17)

点击上图中实例最多的class，右键**Use Selected Instances->Reference->Incoming Reference**.
发现该Long数据最终是存放在**bezier.BeaierAnim.leakMap**中。

(图18)

在Allocations tab项中，右键点击其中的某个方法，可查看到具体的源码信息.（如果看不到的话，可能得需要关联源码）

(图19)

【注】:到这里问题已经非常清楚了，明白了在图17中为什么哪些实例的数量是一样多，并且为什么内存在fullgc后还是回收不了(一个old 区的对象leakMap，put的信息也会进入old区, leakMap如回收不掉，那么该map中包含的对象也回收不掉)。

2）线程锁

线程的运行情况可以直接反应出系统的瓶颈所在，对线程一般有以下三个关注点：

a，Web容器的线程最大数管理，Web容器允许开启的线程数与系统要求的最大并发数有一定的对应关系，通常是Web容器运行的线程数略大于最大并发数，
以Tomcat为例，在{$tomcat}/conf/server.xml文件的Connector选项里配置maxThreads，它的默认值时150；
b，线程阻塞；
c，线程死锁。

线程锁分析：

为了方便区分线程，我将Demo中的BezierAnim.java的L236的线程命名为test

public void start() {            thread = new Thread(this, "test");            thread.setPriority(Thread.MIN_PRIORITY);            thread.start();
        }

正常情况下，如下图
勾选了Demo中"Simulate blocking"选项后，如下图(注意看下下图中的状态图标), test线程block状态明显增加了。

在Thread Views的Thread History视图里可以查看Web容器共打开的线程数以及这些线程的使用情况，在视图里红色表示阻塞的时间段，红色线条越长代表阻塞的时间越长，说明在存在阻塞情况这时切换到Current Monitor Usage或者Monitor Usage History视图。，如：

图：9

通过视图上方的

指定只显示阻塞时间超过一定s（秒）数的线程，在本例中指定5s，在线程表格中选中一行，一般会在下方表格里显示出等待线程和拥有线程的执行堆栈，通过分析这些执行堆栈并在项目中找到对应的Java类方法，分析阻塞原因（往往是使用synchronized同步关键字导致阻塞，因此在用到synchronized关键字时一定要谨慎），从而解决问题。

如果系统里存在线程死锁情况，则会显示在Deadlock Detection视图：

图：10

在该视图里会把死锁线程的Java对象调用关系以关系网的方式展示，并能定位到造成死锁的类方法，通过结合该图和Java代码分析解决问题。

在**Monitors & locks->Monitor History**观察了一段时间后，会发现有4种发生锁的情况。

第一种:
AWT-EventQueue-0 线程持有一个Object的锁，并且处于Waiting状态。

图下方的代码提示出Demo.block方法调用了object.wait方法。这个还是比较容易理解的。

(图22)

第二种:
AWT-EventQueue-0占有了bezier.BezierAnim$Demo实例上的锁，而test线程等待该线程释放。

注意下图中下方的源代码, 这种锁的出现原因是Demo的blcok方法在AWT和test线程
都会被执行，并且该方法是synchronized.

(图23)

第三种和第四种:
test线程中会不断向事件Event Dispatching Thread提交任务，导致竞争java.awt.EventQueue对象锁。
提交任务的方式是下面的代码:repaint()和EventQueue.invokeLater

        public void run() {
            Thread me = Thread.currentThread();            while (thread == me) {
                repaint();                if (block) {
                    block(false);
                }                try {
                    Thread.sleep(10);
                } catch (Exception e) {                    break;
                }
                EventQueue.invokeLater(new Runnable() {                    @Override
                    public void run() {
                        onEDTMethod();
                    }
                });
            }
            thread = null;
        }