系统性能指标与调优思路（一）

年初活动期间，负责的系统被活动的流量给冲垮了。尽管在后续的阶段中，对系统进行了优化，但是这种行为颇有点亡羊补牢的感觉。

是否能在事件发生之前，就提前根据各方面的指标进行事故的规避呢？如果可以，又应该由哪几个维度去衡量与评估系统？尽管系统崩溃的原因各式各样，但如果有一套基于指标建立合理完善的监控机制，则能最大程度地对可能发生的风险进行提前防范。

基于以上理由，我想尝试去汇总一些指标维度去分析一个系统的健壮性。

一、响应时间、并发数以及吞吐量

响应时间是我们经常关注的一个指标。它可以是发起请求到系统接收请求最终传输完成数据所用的时间。从这句话的描述我们可以知道，这里包括两部分耗时，一部分是网络传输耗时，另一部分则是程序本身自己处理请求的耗时。

吞吐量也是另一个十分重要的指标。它一般指在单位时间里系统所能完成的请求数。
跟吞吐量比较密切的几个量化指标：TPS（每秒事务数）、QPS（每秒查询数）、响应时间、并发数

他们的关系是：
QPS(TPS)=并发数/平均响应时间

二、资源利用率

资源利用率包括CPU利用率、CPU负载，内存使用率，磁盘IO，网卡负载（NetWork Load）,网卡队列情况等。
由于这里每一个小点都足以用不同的文章来阐述，这里仅挑几个小点来进行扩展，其他见各自的文章。具体的文章目录见：【此处应有链接】。

2.1 CPU相关

CPU利用率和CPU负载，我们通常在linux采用top命令查看。

也可以考虑用vmstat来进行查看

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负载很重。