码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2015-11-01 19:22:57      阅读:316      评论:0      收藏:0      [点我收藏+]

标签:

一、网卡流量监控
1、网卡流量监控的意义是: 如果网卡流量上限设置过小,就会成为一个web系统的性能瓶颈。记得勤泽说过的,曾经一个系统设置网卡流量上限为15M,出现了大流量的时候系统雪崩的情况。但是这个只是特例情况,正常情况下,这个指标是不会成为、也不应该成为一个系统的性能瓶颈的。
 
2、我们系统中目前的ifout出流量平均值为26319.93KByte/s,ifin进流量的平均值为50760.54KBytes/s.。都是在可接受的范围内
 
3、如果当天的aliMonitor出现问题,在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使用率,首先做的是立即停掉该机器对外提供的服务【比如阿里的hsf服务】。否则会导致一些服务的相应超时,导致一些用户的不可访问的情况。接下来可以首先查看是否是某个进程出现异常【比如黑客攻击,植入超高负载的死锁进程等】,确定进程的使用场景,如果可以的话可以杀死该进程。
  对应的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、磁盘的使用情况:需要对于各个磁盘空间的使用情况都进行关注。
以下是aliMonitor中配置的各个磁盘空间的
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、如果出现AliMonitor不可用的时候,在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的核数
 
 

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

标签:

原文地址:http://www.cnblogs.com/shiru/p/4928403.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!