注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

曾国藩的博客

 
 
 

日志

 
 

某大型平台性能瓶颈问题实例分析  

2015-08-26 14:53:28|  分类: tomcat/jetty/web |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
http://www.howzhi.com/group/it/discuss/508

最近,手头某一省级平台发生系统反应缓慢,一个请求可以达到五六秒,极大影响系统的体验。客户反应巨大。着手解决这个问题,但是解决的过程很鸡血,实在是痛苦。

  • 平台架构背景:

      架构模式:Share-nothing架构,Browser->WebServer(即App server)->DB。Web(应用)服务器完全无状态,可实现热插拔;客户端采用AJAX替代传统Web页面。

      架构组成:8台中低端PC服务器(Dell R510),16个Jetty实例;同时,8台PC服务器也兼了Cache服务器,总共开辟出16G缓存;2台反向代理集群,缓存资源文件;2台IBM小机,互为热备,作为DB(数据库未实现shard)。

      架构设计容量:5万注册用户,1000左右的并发。

  • 平台运行背景以及症状
      平台运行背景:系统刚刚上线不久,用户总数才达到规划数量的1/10左右,系统数据量最大的一张表也不超过10万条记录。
 
      症状:大部分时候,系统反应良好,但是每当上午:10:00--12:00, 13:30~~14:00之间,系统反应缓慢,几乎无法使用,AJAX请求有时候超时。
      
  • 解决过程
1、根据以往的经验,首先考虑数据库IO,可是系统刚刚上线不久,目前最高在线用户也就400,考虑并发量应该最高也就50左右。验证上述过程:
     A)   DBA告知,数据库系统几乎木有压力,可以忽略
     B)   通过每秒请求数的监控(来自F5),发现确实并发数不大。

 2、考虑DB压力不大,那么一下应用服务器的压力是否过重,看了一下所有服务器的load,发现最大也不过6左右,而且,每台应用服务器的Load图表都差不多(注1),应用服务器都有8个核心,Load都未到8,虽然load值偏大了(1/10的用户量),但应该不至于使系统反应如此缓慢呀。这下头大了,系统的load偏高,此其一;但系统反应缓慢,Load的表现和系统表现不一致,此其二.

 

3、由于用户基数和请求数的现实,考虑是否网络流量过大,由于是AJAX应用,又考虑资源文件请求和网络流量的问题。于是,查看了反向代理服务器的Load和流量,以及整个系统的流量。木有发现什么问题!

A) 反向代理服务器的Load

    B) 反向代理服务器的流量

C) 系统流量

    这下麻烦了,IO,NetWork IO,Load都不能体现系统的实际状况,那问题难倒出现在JVM内部? 可是JVM内存正常! CPU正常! 

     唉,只能使用最原始的办法了,分析日志.....最痛苦也是最有效的方式。  

 

 

  •  日志分析过程
1、选择其中一台应用服务器作为日志分析,平台的日志文件(不是访问日志,是应用日志)是以10M为分割点,每10M为一个日志文件。按惯例,看了下日志目录,感觉日志文件有点多(注2)。
    同时分析了应用日志,未见高峰期有异常发生。
     

 2) 系统访问日志分析:

cat jetty-2011_11_18.request_.log  | awk '/18 11:[3-5]/{print}'  | awk  '{print $7}' | awk -F '?' '{print $1}' |sort | uniq -c | sort -nr | head -n 100

    上述语句的意思是,对11月18日11点30至12点之间的访问的URL,打印访问数量排名前100的数量以及URL.

    分析得到这段时间内产生的访问都属于正常访问,未见有异常的访问(之前,对于这些URL已经进行性能测试冲击,并未发现特别耗资源的,并发量也不错).

 

    

    死路一条?

    咋办? 现在能看得见的就是日志量有些大,对,日志量有些大! 看了一下log4j的配置,全局是info级别记录。根据经验判断,这个是有点多了的,但是多到什么程度?

    对app.log.*进行分析:

    cat app.log*  | awk '/18 11:3[0-4]/{print}'| wc -l

    (注:统计18日当天11点30分至35之间的日志行数)

    发现, 5分钟打了900多条记录。于是对系统高峰期(10:00--12:00, 13:30~~14:00)进行了抽样调查,发现一个Jetty实例,每秒钟最高日志量能达到200条, 显然两个Jetty实例,每秒钟需要写将近400条的日志。

    这是系统的瓶颈了???但是为什么应用服务器的load并不高?如果是IO瓶颈,那么Load应该能反应出来的,可是Load为什么都差不多平均在1以下呢? 我不能确定。

 

    于是,在旁支环境进行了测试,将系统日志级别进行全面调整,仅打ERROR级别及以上的日志。调整前后分别用ab(ApacheBench)对系统某个轻量级请求进行了冲击测试。

    A)、在调整前,每秒100,200,300的并发,系统实际吞吐量达到70~80个请求/秒

    B)、调整后,每秒100,200,300的并发,系统实际吞吐量能达到800~1000个请求/秒。

     肯定是问题所在了!全面调整日志打印参数,提高应用日志打印级别。 系统的性能得到了本质的提高。

    可是,为什么系统load和实际反映不一样呢? 当时很晚了,于是回家了。第二天上午,系统人员告诉我,监控貌似有点不对,下午,系统人员告诉我,所有的监控都指向发布服务器了~~~~~~汗~~~~当天即得到了调整,真是杯具,木有历史记录了。


  • 总结:
   1、系统部署的时候,要小心验证,系统监控的问题,导致后面分析问题的方向完全是错误的。
   2、经验主义害人,还需要更小心的求证,之前我参与过的大型系统,都是并发上千以上的,所以对负载均衡到每台服务器的压力都比较大,每台服务器的负载图基本都具有典型参考意义。可是,我分析的这个平台,用户量少,并发小,平均到每台服务器的负载还不具备典型参考意义,应当是有高有低,并不能完全均衡。可是,我想当然了,如果这步能有作为,就能够在出现性能问题之前得以纠正,为这次性能分析大大节约时间和成本。(参看注1,采用红字标识)
   3、短时间内产生巨大的日志量,其实也是一目了然的,由于前面种种挫折,导致对自己的分析方法出现了怀疑,缺乏数据敏感度,对于一些影响系统的数据,需要更进一步的把握和打扎实基础。(参看注2,采用红字标识)
    4、作为从事大型应用架构的架构师,个人的分析能力和实操能力还具备较大的上升空间。

 

案例分析一例,供各位大虾参考。

  评论这张
 
阅读(194)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018