码迷,mamicode.com
首页 > Web开发 > 详细

记一次Web应用CPU偏高

时间:2014-06-07 07:10:14      阅读:210      评论:0      收藏:0      [点我收藏+]

标签:c   style   blog   a   http   width   

LZ开发的一个公司内部应用供查询HIVE数据使用。部署上线后总是会出现CPU偏高的情况,而且本地测试很难重现。之前出现几次都是通过直接重启后继续使用,因为是内部使用,重启一下也没有很大影响(当然,每次重启都是顺带改改BUG,添加一些监控,或者修改了一些参数)。

 

今天再次发生占用CPU偏高的情况(机器是16核的),跑了几天后出现占用到200-300CPU的情况,之后快速升高,占用到700-1000。随机对应用状态状态尽兴了检查。

首先看了GC情况,看是否在进行FGC。

 

bubuko.com,布布扣

(在CPU刚开始飙高的时候FGC的次数是0,上图9次定位完问题才截的图,之前的没有保留)

发现应用并没有在进行FGC,而是进行频繁的YGC。

YGC也存在异常,S1和S0区域都是从0直接跳到99%

观察堆大小装太发现Young区内存都是不断的从0到99,而Old区在慢慢递增,还未达到FGC的状态。但预计后续会不停的上涨,导致FGC频道,应用无法提供服务。

在发现YGC频繁之后大约3个小时,终于开始了频繁的FGC,Old区满。

以下是堆大小和FGC的情况:

bubuko.com,布布扣

 

bubuko.com,布布扣

可以看到差不多10秒钟Old区就用满了导致一次FGC,而且Old区大小是10G(多么恐怖,10个G十来秒就用完了)

从内存和GC的角度只能看到YGC频繁导致了FGC频道(10秒一次)。但这样的情况应用还是能提供服务,只是占了较高的CPU(如果FGC在频繁一些应用应该是不能访问的)。

 

查完内存的状态确认并不是old区太小,被用满了导致了不停的FGC,因为old明显是够大的,如果10G不够,那应用肯定是有问题的。

之后去查了哪些线程占用了很高CPU(本应当在发现没有频繁FGC之后就入手查线程状态,经验不够)

查看进程的线程CPU使用情况:

bubuko.com,布布扣

拿到CPU占用较高的几个线程,转成16进制

bubuko.com,布布扣

使用jstack看进程内的线程堆栈信息(jstack 24820 > abc.log)

vim编辑abc.log,查找上面获取到的线程的16进制数

bubuko.com,布布扣

发现是使用了com.trilead.ssh2.StreamGobbler类的线程。这是一个ssh的第三方包。

后续查了其他CPU占用高的线程,除了GC占用,大部分都是SSH占用。

应用场景是每次使用HIVEQL进行查询的时候都会起一个线程,SSH到远程服务器,执行查询内容,返回结果。

如果有多个用户同时进行多个查询(一个用户也可以进行多次查询),就会出现多个线程多次SSH的情况。

后续处理的两个方案:

方案一,替换现有的第三方SSH工具,看有没有更好的

方案二,修改代码。考虑SSH后保持SESSION(查SSH SESSION的时效时间),统一账号,所有用户后台使用统一账号登录远程服务器执行查询。只使用一个SESSION,发现SESSION失效后进行一次重连。而不是每次查询都建一个登录一次获取session,用完后关闭,相信能减少SSH的引起的问题。

(PS:因为手头上还在进行其他项目,所以还是重启了应用先顶一阵,后面做完hive的权限控制,后台统一用户执行后优化SSH的处理)

 

OOM、CPU占用问题,JVM工具使用这些都是从菜鸟程序员不断提高要经历的,希望自己变的更好。

附JVM常用工具说明:http://my.oschina.net/feichexia/blog/196575

 

记一次Web应用CPU偏高,布布扣,bubuko.com

记一次Web应用CPU偏高

标签:c   style   blog   a   http   width   

原文地址:http://www.cnblogs.com/hzmark/p/JVM_CPU.html

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