性能监控分析总结（Loadrunner Analysi或unix、linux命令分析）

                            性能监控分析总结（Loadrunner Analysi或unix、linux命令分析）

一、cpu

1、Average load平均负载

分析方法1：

上一分钟同时处于就绪状态的平均进程数，小于cpu个数*核心数*0.7，如果这个数字大于cpu的数据，至少有一个线程要等待cpu；如果这个数值除以cpu的数目，结果高于5的时候表明系统在超负荷运转了，就相当于执行vmstat查询出来的r列的值（runable threads），平均值持续大于2，那么标识cpu存在瓶颈。

分析2：

一般来说只要当前活动进程数不大于3那么系统的性能是良好的，如果每个cpu的任务数大于5，那么就表示这台机器的性能有严重问题。例如：系统有2个cpu，lr监控到平均负载为8.13，那么其每个cpu的当前任务数为8.13/2=4.065，这表示该系统的性能是可以接受的。

总核数=物理cpu个数 x 每颗物理cpu的核数

总逻辑cpu个数=物理cpu个数 x 每颗物理cpu的核数x超线程数

（1）查看物理cpu个数：

cat  /proc/cpuinfo | grep "physical id" | sort  | uniq | wc –l

（2）每个物理cpu中core的个数（即核数）

cat  /proc/cpuinfo | grep "cpu cores" | uniq

51.96.11.26上4个物理cpu，每个物理cpu 6个核心即24C

（3）查看核心数：

cat  /proc/cpuinfo | grep "core id" | sort | wc –l

（4）查看逻辑cpu个数：

cat  /proc/cpuinfo|grep "processor"|wc –l

（5）是否为超线程？如果有两个逻辑cpu具有相同的“core id”，那么超线程是打开的。每个物理cpu中逻辑cpu（可能是core，threads或both）的个数。

（6）查看内存信息命令cat  /proc/meminfo

2、CPU Utilization (Unix Kernel Statistics)  cpu利用率

Cpu的使用时间百分比，如果在85%以上，则说明cpu成为资源瓶颈，该项指标的合理使用范围为60%-70%，若指标较低则意味着资源的浪费。

cpu利用率=系统cpu利用率+用户cpu利用率

二、内存

1、Paging rate 内存页交换速率

每秒读入物理内存或写入页面文件的页数，如果持续在几百，可能要加大内存了。

2、如果页交换率提高，则cpu消耗也会相应增加，如果该值偶尔走高，则表明当时有线程竞争如果持续很高，则内存可能是瓶颈。

3、Paging-in rate  每秒写入内存页和从物理内存中读出页的数目。如果该值偶尔走高，表明当时有线程竞争内存，如果持续很高，则内存可能是瓶颈。写入是从硬盘写入内存。

4、Paging-out rate 写出内存页速率，每秒从物理内存写到页文件中的内存页数目和从物理内存中删除掉的内存页数目。写出是从内存写入硬盘。

5、Swape-in rate  Swape- out rate

正在交换的进程数   交换区输入输出的进程数目，若交换分区进程交换频繁，也反映了系统内存资源的紧张。

交换分区swap的概念

Linux/unix交换分区就相当于windows中的虚拟内存。Swap空间的作用可简单的描述为：当系统的物理内存不够用的时候，需要将物理内存中的一部分空间释放出来，以供当前运行的程序使用。哪些被释放出来的空间可能来自一些很长时间没有操作的程序，这些被释放的空间被临时保存到Swap空间中，等到那些程序要运行时，再从swap中恢复保存的数据到内存中，这样，系统总是在物理内存不够时，才进行swap交换。

三、磁盘

1、Disk traffic  Rate of disk transfer  磁盘传输速率

硬盘传输速率是硬盘读取数据的速度，单位通常为MB/S。物理磁盘与内存交换时的传输速度。

相当于iostat –d  3n输出的tps或者iostat  –x  3的r/s+w/s

iostat  –d  3n:

iostat  –x  3的r/s+w/s (每秒的读写次数)

2、iostat  -x 1

%iowait：cpu用于等待io请求完成的时间

Await：平均每次设备i/o操作的等待时间(毫秒)即（ruse+wuse）/（rio+wio）

Avgrq-sz:平均每次io操作的数据量

Avgqu-sz：平均等待处理的io请求队列长度

svctm：平均每次io请求的处理时间

%util ：采集周期内用于io操作的时间比率即io队列非空的时间比率

一秒钟有百分之多少的时间用于i/o操作，或者说一秒钟有多少时间i/o队列是非空的，即use/1000，（use的单位为毫秒），如果%util接近100% ，说明i/o产生的请求太多，i/o系统已经满负荷，该磁盘可能存在瓶颈。

iostat –x-k-d 1

3、vmstat

vmstat  2  每隔2秒采集一次

r列:在运行队列中等待的进程数

b列：在等待资源的进程数，比如正在等待io或者内存交换

bi:从块设备读入数据的总量，块设备指系统上所有的磁盘及其他块设备。

bo: 块设备写入数据的总量。例如读取文件，bo就要大于0，bi与bo一般都要接近0，不然就是io过于频繁，需要调整。

wa:io等待所占用的cpu时间百分比

四、网络

1、Incoming packets error rate 数据包接收错误率

接收以太网数据包时每秒中接收到的错误数，可能是网络设备（网卡、网线、路由设备等）该值较大会影响相应时间，甚至超时。

2、Incoming packets rate 数据包接收速度

每秒钟传入的以太网数据包数

3、Outgoing packets rate 数据包发送速度

每秒钟传出的以太网数据包数

带宽为1Gbs 合计传输速率为128MB/s,吞吐率73178737byte，大约73MB。

 

五、Sql

通过创建事件监控器来看查看耗时最长的sql

查看监控开关设置

db2 get monitor switches

如何打开事件监控器

Db2=>update monitor switches using statement on

将监控的计数器清零：

db2 –v reset monitor all  

创建事件监控器：

Db2=>create event monitor sql_trace for statements write to table

创建完后我看可以看到db2自动生成了下面这张表：

db2 list tables for all|find /i “stmt”

Stmt_sql_trace

(注意修改该表的表空间)

db2 => set event monitor sql_trace state=1

直到监控结束

关闭监控器：

Db2=>set event monitor sql_trace state=0

Db2=>Terminate

清空事件监视器

db2 flush event monitor sql_trace

删除事件监控器

db2 “drop event monitor sql_trace”

分析输出

需要确定4类SQL语句。在执行以下查询以确定这些语句之前，在数据库配置参数中，至少要未应用程序堆大小(applheapsz)分配256个页面。

按照执行时间降序排列执行耗时最长的SQL语句。为了确定这些语句，使用下面的SQL SELECT语句：

select * from (select stmt_text,(stop_time-start_time) ExecutionTime,stop_time,start_time from stmt_sql_trace where stmt_operation not in (7,8,9,19)) aaa order by ExecutionTime desc;

select stmt_text,count(*),avg (timestampdiff(2,char(stop_time-start_time))) avg from stmt_sql_trace3 where stmt_operation not in (7,8,9,19) group by stmt_text order by avg desc

当前sql：

select * from sysibmadm.MON_CURRENT_SQL;

select * from sysibmadm.TOP_DYNAMIC_SQL;