性能监控实战

用户响应时间=服务器响应时间+网络时间

系统性能分析思路

(1)整体系统CPU利用率

(2)内存利用率

(3)磁盘I/O的利用率和延迟

(4)网络利用率

cpu

CPU:top、vmstat、uptime、sar

一般我们期望会期望系统平均可用的CPU不少于20%

JVM自带监控命令:jstat、jmap、Jvisualvm、JConsole

Mysql监控工具:Spolight、Monyog、及命令行工具

内存

total      used        free         buffers         cached

Mem  物理内存总量  使用的物理内存总量  空闲的物理内存总量  用作内核缓存的内存量  缓存的交换区总量

swap  交换区总量   使用的交换区总量     空闲交换区总量

可用物理内存=Mem(free+buffers+cached)

当物理内存不够时,会使用swap分区,所以性能测试过程中需要关注swap和mem的使用情况。物理内存不够,大量的内存置换到swap空间,可能导致CPU和I/O的瓶颈。

I/O

I/O比较频繁(读或者写)的时候,如果I/O得不到满足会导致应用的阻塞。

需要考虑I/O的TPS、平均I/O数据、平均队列长度、平均服务时间、平均等待时间、IO利用率(磁盘Busy Time%)等指标

总结

很多时候,这些因素彼此之间是相互依赖的,任何一个处于高负载状态,都可能导致其他资源受到影响,如:

(1)大量的网络吞吐量导致占用CPU的资源增大,此时系统要分出部分资源进行软件终端的处理

(2)大量的CPU开销会尝试更多的内存使用

理解并分析当前系统的特点很重要,多数系统对应的应用类型分为以下两种:

(1)IO范畴

大量数据处理的过程,不对CPU及网络发起更多请求。如数据库软件(mysql、Oracle)

(2)CPU范畴

批量处理CPU请求及数学计算的过程。如:webserver、mailserver等。

瓶颈分析

性能监控实战_第1张图片

CPU定位分析

CPU利用率大于50%是,需要注意了;大于70%,需要密切关注;高于90%,情况比较严重了。

监控命令:vmstat、sar、dstat、mpstat、top、ps

类型度量方法

衡量标准


性能监控实战_第2张图片

使用情况

1、vmstat 统计1-%id的计数

2、sar -u 统计1-%idle的计数

3、dstat 统计1-%idl的计数

4、mpstat -P ALL 统计%idle的计数

5、ps 统计CPU的计数注意>=50%

告警>=70%

严重>=90%

满载6、vmstat的r计数器> cpu逻辑颗数

7、sar -q ,“runq-sz”>cpu逻辑颗数

8、dstat -q ,“run”>cpu逻辑颗数运行队列大于1时,证明已经有一定的负载了,不过这个计数也不绝对,需要进一步分期其他的资源情况来断定是否CPU已经满负荷运作

错误9、perf工具捕获处理器的错误信息,需处理器支持安装perf:yum install perf*

需处理器支持

内存定位分析

监控命令:vmstat、sar、dstat、free、top、ps等

类型度量方法

衡量标注


性能监控实战_第3张图片

使用情况

1、free 查看使用情况

2、vmstat

3、sar -r

4、ps

注意>=50%

告警>=70%

严重>=80%

满载

5、vmstat的si/so比例辅助swapd和free利用

6、sar -W 查看次缺页数

7、查看内核日志有误OOM机制kill进程

8、dmesg | grep killed

1、so数值大,且swapd已经占比很高,内存肯定已经饱和

2、sar命令次缺页多意味已经在不定地和swap打交道,证明内存已经饱和

3、但内存不够用会出发内核的OOM机制

错误

9、查看内核有无physical failures

10、通过工具如valgrind等进行检查有计数

网络定位分析

监控命令:sar、ifconfig、netstat,以及查看net的dev速率,通过查看发现收发包的吞吐率达到网卡的最大上限,网络数据报文有因为这类原因而引起的丢包、阻塞等现象都证明当前网络可能存在瓶颈。在进行性能测试是为了减小网络的影响,一般我们都在局域网中进行测试执行。

类型度量方法

衡量标准


性能监控实战_第4张图片

使用情况

1、sar -n DEV 的收发计数大于网卡上限

2、ifconfig RX/TX宽带超过网卡上限

3、cat /proc/net/dev的速率超过上限

4、nicstat的util

基本满负荷

1、收发包的吞吐速率达到网卡上限

2、有延迟

3、有丢包

4、有阻塞

满载

5、ifconfig dropped 有计数

6、netstat -s "segments retransmited"有计数

7、sar -n EDEV,rxdrop/s  txdrop/s有计数统计的丢包有计数证明已经满了

错误

8、ifconfig,“errors”

9、netstat -i,RX-ERR TX-ERR

10 sar -n EDEV,rxerr/s   txerr/s

11、ip -s link, “errors”错误有计数

IO定位分析

监控命令:sar、iostat、iotop

类型度量方法

衡量标准


性能监控实战_第5张图片

使用情况

1、iostat -xz,“%util”

2、sar -d,“%util”

3、iotop的利用率很高

4、cat /proc/pid/sched | grep iowait注意>=40%

告警>=60%

严重>=80%

满载

5、iostat -xnz,“avgqu-sz ”>1

6、iostat await>70IO已经有满载嫌疑

错误

7、dmseg 查看io错误

8、smartctl /dev/sda有信息

linux系统性能分析思路和实践

系统负载监控分析实践

可以通过uptime、top、w等命令分析

uptime

系统时间  up:主机运行时间  当前登录用户数  平均负载:过去1分钟、5分钟、15分钟

(1)运行时间越长,系统越稳定

(2)当前用户数,用w命令可以更详细

(3)系统的平均负载只在特定时间间隔内运行队列中的平均进程数。

一般建议每个CPU内核平均负载不大于0.8;若大于1~3之间,如果系统其他资源都很正常,可接受;若>5,则系统性能有问题

uptime是从文件/proc/loadavg文件里面读取的。统计过去1分钟、5分钟、15分钟平均负载:

[dcai@localhost ~]$ uptime | awk '{print $(NF-2)}'

0.00,

[dcai@localhost ~]$ uptime | awk '{print $(NF-1)}'

0.02,

[dcai@localhost ~]$ uptime | awk '{print $NF}'

0.12

系统监控分析实战

top之外,还有htop、dstat、nmon、glances等

top

性能监控实战_第6张图片

1、第一行:uptime一样

2、第二行:运行状态信息

运行、睡眠、中断、僵死

3、第三行:CPU信息

us:用户占用CPU百分比

sy:系统占用CPU百分比

ni:优先级(用户进程空间内改变过优先级的进程占用CPU百分比),范围-20(最低优先级)~19(最高优先级)

id:空闲CPU百分比

wa:等待输入输出的CPU时间百分比

hi:硬中断占用的CPU百分比

si:软中断占用的百分比

我们比较关注:us、sy、id、wa、hi、si这六个数值

(1)按下键盘1,可以显示每个逻辑CPU的使用情况

(2)id持续过低时,系统迫切需要解决CPU资源问题

(3)wa使用率过高,需要考虑IO性能是否有瓶颈,可以用iostat,sar等命令进一步分析

(3)hi使用率过高,可以分析文件 /proc/interrupts、/proc/irq/pid/smp_affinity、服务irqbalance是否配置、以及CPU的频率设置,通过这些可以帮系统大赛优化系统的硬中断

(4)si:内核通过一种软件的方法(可延迟函数)来模拟硬件的中断模式,通常叫软中断。常见的软中断都和网络有关,长时间的写日志也可能产生软中断。

系统有个进程ksoftirqd来处理软中断,每个CPU都有自己对应的ksoftirqd/n(n为CPU逻辑ID)。但网络出现阻塞的时候,ksoftirqd会出现瓶颈,此时可通过ps命令查看ps aux | grep ksoftirqd

(5)CPU利用率=1-%id

4、第四行+第五行:内存使用情况

buffer和cache的作用是缩短IO系统调用的时间。如果频繁地访问文件都能被命中,很明显会比读取磁盘调用快,磁盘的IO必定会减小。cache的命中率很关键,如果不能命中,对cache而言是极大的浪费,此时应考虑drop cache并提升相应的cache命中率。

5、第六行:进程信息

进程号(PID)、进程所有者(USER)、进程优先级(nice值、NI)、进程使用的虚拟内存(VIRT)、进程使用的实际物理内存(RES)、共享内存(SHR)、CPU占用百分比、进程使用的物理内存百分比(%MEM)、进程使用的CPU时间总计(1/100秒,TIME+)、命令行

(1)top显示的是进程信息,要看线程级,可用ps -ef

(2)TIME+表示的是进程使用的CPU时间总计,不是进程的存活时间

(3)默认不会显示进程分布在那颗CPU上,如想分析CPU对应的应用程序,可修改top默认配置,添加字段Last used CPU即可。

(4)H:top配置帮助页

d:刷新间隔

f:添加进程字段显示列

1:显示平均/各颗CPU的利用率信息

W:保存配置信息

6、top参数

-d  批处理模式

-c  命令/程序名  触发

-d  设置延迟间隔(刷新频率)

-n  设置迭代数量(退出前监控次数)

-p  监控特定的PID

-u或-U: 用户名 或 UID

top -b -d 1 -n 3 > top.log

tomcat监控之probe

目前流行的中间件有tomcat、jetty、Jboss、weblogic、WebSphere等,基本原理相似,都遵循servlet规范。对容器的监控实际上是对JVM的监控,容器运行在JVM纸上。JVM的监控分析工具有jvisualVM、jconsole、jprofiler、zabbix、nagios、cacti等。下面介绍tomcat监控工具probe,probe只需要一个war包就可以完成监控任务,完全不用设置,下面是tomcat常规监控项:


性能监控实战_第7张图片

类别    计数器    描述

tomcat

JVM内存:关注GC回收频率,Full GC次数越少越好

最大线程数:线程池连接数长期大于80%以上,建议优化

数据库连接数:活动连接数长期大于80%以上,建议优化连接池

请求数

请求状态线:程数,线程状态,大量blocked状态线程可以dump线程栈信息进行优化

probe

安装probe之后,打开浏览器访问probe:127.0.0.1:8089/probe

线程池的监控:

current_threads_count:线程池中ready好的数量,我的在运行状态,我的在等待状态

current_threads_busy:当前活动状态的线程数量,正处在活动状态

max_threads:最大线程池数量

我们需要关注current_threads_count和current_threads_busy是否接近max_threads,如果是,则需要加大max_threads数量;如果服务器硬件支撑不了更多线程数,就需要更换更强的硬件或做集群来分担负载。

JVM监控

除了probe之外,自带监控工具也比较好用

jps

jps是jdk提供的一个查看当前java进程的小工具, 可以看做是JavaVirtual Machine Process Status Tool的缩写。非常简单实用。

jps –l:输出主类或者jar的完全路径名

jps –v :输出jvm参数

jps –q :仅仅显示java进程号

jps -m : 输出main method的参数

jps -mlv 10.134.68.173 (如果需要查看其他机器上的jvm进程,需要在待查看机器上启动jstatd。)

性能监控实战_第8张图片

jstat

FGC(Full gc)会暂停用户相应,也就是不处理用户请求,等待Full gc完成后响应用户请求,这个等待时间过大会影响用户体验,所以Full gc是JVM调优的重点

jstat -gcutil [PID]

jmap

分析程序内存占用其实是分析堆(Heap)内存,堆快照使用jamp获取

典型获取方式:

jmao dump:format=b,file=d:\heap.hprof [pid]

heap.hprof是快照文件,可以使用JVisualvm来打开

JVisualvm

JDK自带的JVM可视化监控工具

在%JAVA_HOME%\bin下找到,双击启动

下图:可以做堆Dump操作,查看堆内存明细。堆的回收曲线能够直观反映堆内存回收频率,是否有内存溢出等问题。

性能监控实战_第9张图片

下图:点击“线程Dump”导出JVM当前线程栈信息,通过分析这些信息来定位到程序问题

性能监控实战_第10张图片

总结:对于Java的应用来讲,JVM的性能反映了Java程序的性能,JVM的监控分两大类,一是堆内存,二是线程;从堆内存可以分析大对象与内存溢出等问题,从线程状态及线程信息分析出低效程序,解决的是CPU资源占用的问题。

MySql监控之MONyog

MySql监控方法:官方客户端、命令行、SQL、MONyog

1、下载MONyog.地址:https://www.webyog.com/

2、安装完成后,启动MONyog进行连接配置

3、MONyog绝大多数指标都进行了详细说明

性能监控实战_第11张图片
性能监控实战_第12张图片

最后

当性能测试环境复杂的情况下,可以借助zabbix、nagios、cacti等监控平台


转自:http://www.cnblogs.com/lingzeng86/p/6681140.html

作者:落花无意溪自流

你可能感兴趣的:(性能监控实战)