走过第一个双十一的收获----性能监控篇

一、网卡流量监控

1、网卡流量监控的意义是: 如果网卡流量上限设置过小，就会成为一个web系统的性能瓶颈。记得团队架构师说过的，曾经一个系统设置网卡流量上限为15M，出现了大流量的时候系统雪崩的情况。但是这个只是特例情况，正常情况下，这个指标是不会成为、也不应该成为一个系统的性能瓶颈的。

 

2、以前见过的某系统中目前的ifout出流量平均值为26319.93KByte/s,ifin进流量的平均值为50760.54KBytes/s.。都是在可接受的范围内

 

3、在linux下可以有很多的语句监控网卡流量

  第一种：watch more /proc/net/dev

  第二种：watch ifconfig

  第三种：ifstat

 

这两种都可以看到Receive【接收】和Transmit【发送】的流量。但是这两个可能会不太好，貌似都是监控到总的流量大小，我们需要关注的是网卡流量的瞬时的kBit/s的大小

，linux下的一个工具  iptraf【需要自己安装的】，可以更好监控，但是现在还没有测试使用过，对于我来说是存在于传说中的工具。。。。

 

二、cpu使用率

 

1、服务器cpu的使用率应该是维护在10%的使用率才能保证使用的安全性。

 

2、如果当天的aliMonitor出现问题，如何在linux中监控到cpu的使用率：

 

  a、使用top命令：

  

 

 

cpu(s)那一行显示的含义分别是：用户的模式（user）、低优先级的用户模式（nice）、系统内核模式（system）以及系统空闲的处理器时间（idle）

 

3、如果观察到对应某台机器出现高cpu使用率，首先做的是立即停掉该机器对外提供的服务。否则会导致一些服务的相应超时，导致一些用户的不可访问的情况。接下来可以首先查看是否是某个进程出现异常【比如黑客攻击，植入超高负载的死锁进程等】，确定进程的使用场景，如果可以的话可以杀死该进程。

  对应的linux语句是：

   a、查看进程的使用情况：  ps  aux |grep “XXXX”

   b、杀死不需要的进程： kill s -9 <pid>

 

三、RT

1、RT：response Time【响应时间】

 

2、 一次有索引的DB操作RT应该小于2ms，一个读操作的服务接口RT应该不大于20ms，写操作的RT在50ms内可以都勉强接受。

3、如果一个操作RT较高，首先应该看到的是

    a、热点接口对应的数据库操作，在数据库表是否有对应的索引【之前了解到一个数据库表索引的个数最好不雅超过5个，慎加索引】

    b、sql中的group by等操作是否有进行相应的优化，即sql优化

    c、调用的外部远程接口是否可以加缓存。【外部远程接口加缓存是很提高性能的一个事情，然而加缓存需要考虑缓存的失效期，毕竟需要保证数据的实时性，有缓存是一大阻碍】

    d、如果有批量操作，大数量可能会超过500+的，可以设置一下每次batch200条，然后重复batch直至任务全部完成。实验证明，每次batch200条会有一个比较优秀的RT值

    e、代码逻辑有问题、日志打印太多的废话等，个人理解，在代码逻辑的层次优化上其实很难可以大幅度降低接口RT，然而，毕竟都是需要关注的点啊。

 

 

四、TPS/QPS

 

1、TPS: transction per second 每秒事物数

QPS：query per second 每秒查询数

 

2、在一个大的web系统中，对于数据库的操作读操作远远大于写操作。读写分离可以降低数据库系统的压力。那么在我的理解中，TPS就是一个在写操作中的一次完整的操作，而qps就是在读操作中的一次完整的查询操作。正常来讲一次有索引的DB操作是不应该大于2ms的，而一个service层的服务接口的调用RT时间应该是小于20ms，那么，按照qps为20ms来计算，1s有1000ms，所以一个一个RT为20ms的读操作服务接口的QPS需要达到50 QPS。当然了，一个读接口要达到了50QPS的时候，并发量可能会是大于10以上，因为并发的影响，那么RT相应的也会变得大一些，

 

如果tps单机不能达到需求，就可以考虑加机器啦。毕竟我们现在也是有服务器集群的嘛。

 

五、tcp重传率

 

1、为什么会出现tcp重传的问题：

    TCP是一种可靠的协议，在网络交互的过程中，由于TCP报文是封装在IP协议中的，IP协议的无连接特性导致其可能在交互的过程中丢失，在这种情况下，TCP协议需要去保障其传输的可靠性。TCP通过在发送数据报文的时候设置一个超时值，如果在定时器溢出的时候还没有收到来自接收端的返回报文的确认，它就会重传该数据报文

 

2、常见的高请求web系统之中，tcp重传率不应该高于0.5%，这样就是说在200次请求中，就会有一次请求会失败。需要重试。

 

3、会导致TCP重传的常见状况：

     a、数据报传输途中丢失

     b、接收端的ACK确认报文在传输中途丢失

     c、接收端异常未响应ACK或者是被接收端丢弃

 

4、报文重传的次数：TCP报文重传的次数会根据不同的系统设置不同而区分。大部分的系统中，一个报文只会被重传三次。如果还是没有获取到该报文的确认，那么就不再尝试重传，直接reset重置该TCP连接。 但是在一些要求较高的业务应用系统中，则会不断的重传被丢弃的报文，已尽最大的可能保证业务数据的正常交互。

 

5、重传对于业务应用的影响：

   a、重传可以保障业务的可靠性

   b、重传反应网络通讯的状况：

         如果在我们的系统中出现高于0.5%的TCP重传率，会影响我们的系统业务交互效率，导致业务系统出现缓慢甚至无响应的情况发生。

       一般而言在出现大量tcp重传的时候，说明网络的通讯状况比较糟糕，需要站在网络层的角度去分析丢包和重传的原因

 

六、disk

 

1、磁盘的使用情况：需要对于各个磁盘空间的使用情况都进行关注。

 

df_home	/home分区磁盘空间使用率，范围(0,100]	是	%	avg,max,min
df_var	/var分区磁盘空间使用率，范围(0,100]	否	%	avg,max
df_	/分区磁盘空间使用率，范围(0,100]	是	%	avg,max,min
df_boot	/boot分区磁盘空间使用率，范围(0,100]	否		avg
df_home_admin	home/admin分区磁盘空间使用率，范围(0,100]	否		avg
df_tmp	/tmp分区磁盘空间使用率，范围(0,100]

 

2、目前的某些系统的disk的平均使用率大概在14%左右。

 

3、linux下的操作：

       查看磁盘的使用率：  df   -lh

 

七、memory

 

1、内存的使用情况也是在系统运行的时候需要关注的，内存的使用率在80%以下的时候都是可以接受的。

2、目前我们的系统的内存使用率一直在平衡在35%左右。

3、在linux下可以使用语句：

     free -m来查看内存的使用情况

 

八、cpu load

1、cpu load的含义：cpu负荷，简单理解就是cpu当前处理的线程与总共能同时处理线程的比值

 

2、cpu load值应该是和cpu核数有关的，如果出现load高于3/4的情况下，就应该开始报警关注

 

3、在linux下查看本机核数的命令： 

     cat /proc/cpuinfo 

   或者是：

     grep "cpu cores" /proc/cpuinfo|uniq

  命令：  其中的cpu cores：行代表的就是cpu的核数