年初活动期间,负责的系统被活动的流量给冲垮了。尽管在后续的阶段中,对系统进行了优化,但是这种行为颇有点亡羊补牢的感觉。
是否能在事件发生之前,就提前根据各方面的指标进行事故的规避呢?如果可以,又应该由哪几个维度去衡量与评估系统?尽管系统崩溃的原因各式各样,但如果有一套基于指标建立合理完善的监控机制,则能最大程度地对可能发生的风险进行提前防范。
基于以上理由,我想尝试去汇总一些指标维度去分析一个系统的健壮性。
响应时间是我们经常关注的一个指标。它可以是发起请求到系统接收请求最终传输完成数据所用的时间。从这句话的描述我们可以知道,这里包括两部分耗时,一部分是网络传输耗时,另一部分则是程序本身自己处理请求的耗时。
吞吐量也是另一个十分重要的指标。它一般指在单位时间里系统所能完成的请求数。
跟吞吐量比较密切的几个量化指标:TPS(每秒事务数)、QPS(每秒查询数)、响应时间、并发数
他们的关系是:
QPS(TPS)=并发数/平均响应时间
资源利用率包括CPU利用率、CPU负载,内存使用率,磁盘IO,网卡负载(NetWork Load),网卡队列情况等。
由于这里每一个小点都足以用不同的文章来阐述,这里仅挑几个小点来进行扩展,其他见各自的文章。具体的文章目录见:【此处应有链接】。
CPU利用率和CPU负载,我们通常在linux采用top命令查看。
0.2%us 用户空间占用CPU百分比
0.2%sy 内核空间占用CPU百分比
0.0%ni 用户进程空间内改变过优先级的进程占用CPU百分比
98.1%id 空闲cpu占比
1.4%wa 等待输入输出的CPU时间百分比
r 表示运行队列的大小
各指标合理范围:
us+sy 合理范围在60%~85%。大于85%,进程需要在运行队列等待,响应时间和业务吞吐量会受损害;us过大,说明用户进程占用cpu,sy过大,说明系统管理方面占用了较多的资源。
wa 是等待输入输出的CPU时间百分比,一般小于25%,超过25%,说明磁盘密集工作负载的结果,系统的磁盘活其他I/O有可能有问题。可以通过iostat/SAR -c进一步分析。
Id(idle):大于40,如果r经常大于4,且id经常小于40,表示cpu负载很重。
r:小于4,队列大于4时,表明系统的cpu或者内存可能有问题。
关于CPU的瓶颈:
很慢的响应时间(slow response time)
Cpu的空闲时间为零(zero percent idle cpu)
过高的用户占用cpu时间(high percent user cpu)
过高的系统占用cpu时间(high percent system cpu)
长时间的有很长的运行进程队列(large run queue size sustained over time)
这里残存的几个问题,可以通过以下链接进行学习:
【此处应有链接】cpu-用户进程和内核空间的区分
【此处应有链接】iostat/sar -c一些指标学习
【此处应有链接】CPU深入学习
这几个指标比较简单:
total:全部内存(包括使用的和未使用的)
used:已使用的内存 free:空闲的内存
cache:高速缓存区,Cache保存着CPU刚使用过的一部分数据,这部分数据由于Cache的速度比内存快,因此能大幅度的减少对磁盘IO的读写,提升系统性能。
buffers:缓冲区。一个用于存储速度不同步的设备或优先级不同的设备之间传输数据的区域,通过缓冲区,可以使进程之间的相互等待变少。
尽管free直观来看是空闲的内存,但是实际上linux和windows在内存管理上并不一样,内核会把剩余的内存申请为cached,如果free的内存不够,实际内核会将cache的部分内存给回收并进行重新分配的。这点需要额外注意下。
【此处应有链接】buffer和cache的区别
磁盘IO可以用以下工具进行:
(1)采用top的命令
上面也有提到过,其中wa的百分比可以大致体现当前的磁盘io请求是否频繁,如果wa的数量比较大,说明等待输入输出的io比较多;
(2)采用vmstat的命令。
一样查看wa的指标
(3)采用iostat -dx
其中r/s和w/s记为每秒的读操作以及写操作
网卡相关可以采用sar命令来进行监控
sar -n DEV 1 2
sar命令有6个不同的开关,分别是DEV(网络接口)|EDEV(网络错误的统计数据)|NFS(活动的NFS客户端的信息)|NFSD(NFS服务器的信息)|SOCK(套接字信息)|ALL
参数说明:
IFACE:LAN接口 rxpck/s:每秒钟接收的数据包
txpck/s:每秒钟发送的数据包
rxbyt/s:每秒钟接收的字节数
txbyt/s:每秒钟发送的字节数
rxcmp/s:每秒钟接收的压缩数据包
txcmp/s:每秒钟发送的压缩数据包
rxmcst/s:每秒钟接收的多播数据包
rxerr/s:每秒钟接收的坏数据包
txerr/s:每秒钟发送的坏数据包
coll/s:每秒冲突数
rxdrop/s:因为缓冲充满,每秒钟丢弃的已接收数据包数
txdrop/s:因为缓冲充满,每秒钟丢弃的已发送数据包数
txcarr/s:发送数据包时,每秒载波错误数
rxfram/s:每秒接收数据包的帧对齐错误数
rxfifo/s:接收的数据包每秒FIFO过速的错误数
txfifo/s:发送的数据包每秒FIFO过速的错误数
在系统运行过程中,GC作为一个异常影响因素而常常需要考虑。GC是Java基础不得不说的一环,在这里不展开篇幅进行详解。如果需要进一步的了解,可以参考:【此处应有链接】。
GC可以借助jstat -gc或者GC日志来进行跟踪相关指标,也可以借助一些可视化工具,比如GC Viewer、VisualVm或者在线GC分析工具(Gceasy)。
工具的使用将开另一篇文章详细讲解,此处不展开篇幅进行说明。可以参考:【此处应有链接】。
我们需要关注以下几个常见指标:
Avg GC time:每次GC停顿时间,程序的平均响应时长与这个值关系密切。
GC Interval avg time:每两次gc之间的平均间隔时间。
Throughput:用户应用程序运行时间占总程序的比例。
很简单直观的一个指标。这个指标不应该纳入到性能指标,而应该作为系统健康程度的一个反应。
具体的说明不用赘述。但是追寻错误率,定位错误原因,可以从日志进行追朔,可以了解一下Takipi这款工具(仅作了解)。
性能计数器(Performation Counter),也叫性能监视器。
在linux系统下主要的计数器监控命令是vmstat、iostat、top、sar。
详细可参考以下文件:
https://www.cnblogs.com/fnng/archive/2012/10/30/2747246.html
类别 | 计数器名称 | 计数器描述 |
---|---|---|
Memory | Free(KB) | 可用物理内存数 |
Swap(KB) | 已使用的虚拟内存数量。在linux系统中值被标识为swpd | |
(page)si | 每秒从磁盘交换到内存的数量,在linux系统中该值被放到swap区中 | |
(page)so | 每秒从内存交换出的内存数量。在linux系统中该值被放到swap区中 | |
Cache(KB) | 文件系统缓存 | |
Process | %CPU Usage | 被处理器消耗的处理器时间数量。可接受的上限一般不超过85% |
Page Fault Count | 该进程产生的页面失效次数。可以用该值与系统的页面失效次数进行对比,从而判断该进程对页面失效的影响。 | |
Resident Size(KB) | 时程保留的使用内存量,该数值等于进程的代码使用内存+进程的数据使用内存。如果该值在测试过程中持续增加,很可能意味发生了内存泄漏。 | |
%Idle Time | 描述CPU的空闲时间,如果该值低于10%,表明瓶颈是CPU,可以考虑增加或者换更快的处理器。 | |
%User Time | 非内核操作耗费的CPU时间。一般来说,如果系统中使用了大量的算法或复杂的计算操作。该值会比较大。 | |
%IO Wait Time | CPU消耗在等待I/O处理上的时间,此值需要结合I/O计数器进行考虑。 | |
Physical Disk | Percent of time the disk is busy | 指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比 |
Average number of transactions actively being serviced | 指读取和写入请求的平均数,该值不应超过磁盘数的1.5至2倍 | |
Average number of transactions waiting for service | 指读取/写入请求(队列)的平均数。在iostat的结果中,该值显示为wait。 | |
Reads(Writes) per sec | 物理磁盘上每秒磁盘的读、写的次数。两都相加,应小于磁盘设备最大容量。在iostat的结果中,该值显示为r/s和w/s | |
Average service time active transactions Inmilliseconds | 指以毫秒计算的在磁盘读取和写入数据所需要的平均时间。在iostat的结果中,该值显示为asvc_t。 | |
The number of disk operations per seconds | 显示每个磁盘每秒被操作次数。该值在vmstat命令的结果显示。 | |
System | %User time | 系统所有处理器执行非内核操作的平均时间的百分比,该值反应了用于有用作业的时间的比率 |
CPU context switches | CPU上下文切换。在vmstat的结果中,该值显示为cs |
日志的大小没有什么好说的。值得注意的,需要关注日志的格式,需要尽可能标准化。
NA
NA
性能优化指南:性能优化的一般性原则与方法
http://www.cnblogs.com/xybaby/p/9055734.html
lazy ideas in programming(编程中的惰性思想)
http://www.cnblogs.com/xybaby/p/6425735.html
java GC分析浅谈
https://blog.csdn.net/snow_114/article/details/80214332
性能分析Linux服务器CPU利用率
https://www.cnblogs.com/shengs/p/5148284.html
性能测试相关概念、指标
https://blog.csdn.net/yue530tomtom/article/details/81949392
系统性能指标体现和优化实践
https://blog.csdn.net/u013380694/article/details/78809598
性能测试知多少–系统计数器与硬件分析
https://www.cnblogs.com/fnng/archive/2012/10/30/2747246.html