走过第一个双十一的收获----性能监控篇
一、网卡流量监控
1、网卡流量监控的意义是: 如果网卡流量上限设置过小，就会成为一个web系统的性能瓶颈。记得团队架构师说过的，曾经一个系统设置网卡流量上限为15M，出现了大流量的时候系统雪崩的情况。但是这个只是特例情况，正常情况下，这个指标是不会成为、也不应该成为一个系统的性能瓶颈的。
2、以前见过的某系统中目前的ifout出流量平均值为26319.93KByte/s,ifin进流量的平均值为50760.54KBytes/s.。都是在可接受的范围内
第一种：watch more /proc/net/dev
第二种：watch ifconfig
第三种：ifstat
这两种都可以看到Receive【接收】和Transmit【发送】的流量。但是这两个可能会不太好，貌似都是监控到总的流量大小，我们需要关注的是网卡流量的瞬时的kBit/s的大小
，linux下的一个工具 iptraf【需要自己安装的】，可以更好监控，但是现在还没有测试使用过，对于我来说是存在于传说中的工具。。。。
1、服务器cpu的使用率应该是维护在10%的使用率才能保证使用的安全性。
![]()
1、磁盘的使用情况：需要对于各个磁盘空间的使用情况都进行关注。
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
| 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的核数