[原创]探查web应用反映慢的原因_Tomcat, WebLogic及J2EE讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  Tomcat, WebLogic及J2EE讨论区 »
总帖数
2
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4360 | 回复: 1   主题: [原创]探查web应用反映慢的原因        下一篇 
yang.liu
注册用户
等级:少校
经验:1182
发帖:77
精华:1
注册:2014-1-3
状态:离线
发送短消息息给yang.liu 加好友    发送短消息息给yang.liu 发消息
发表于: IP:您无权察看 2014-3-26 16:38:08 | [全部帖] [楼主帖] 楼主

1.1 环境:

    Weblogic版本:9.2.0

    操作系统版本:Linux 32bits

    Jdk版本:sun   java version "1.5.0_04"

    数据库连接字符串:jdbc:oracle:thin:@10.237.66.2:1521:orcl

1.2 集群结构:

图下图所示,在一个weblogic集群中共有5个被管节点,分别分布在5台机器上。

北京联动北方科技有限公司

1.3 问题现象: 

    在业务高峰期会出现应用响应很慢,并且有OOM(OutOfMemory)问题。

1.4 问题分析:

1.4.1    日志分析:


1.4.1.1 问题1、  


1.4.1.1.1 Threaddump分析:

weblogic响应慢问题,在分析threaddump后发现,线程大多数处于空闲状态,活动线程数量很少,没有出现死锁或者是同步锁。如图所示:

北京联动北方科技有限公司

1.4.1.1.2 GC日志分析:

从GC日志和服务器的CPU的idle的活动情况来看,发现cpu的使用率很高,99%以上。GC中有大量的fullGC活动情况。平凡的full   GC肯定是会影响weblogic  server的响应速度。因为full  gc是很消耗时间和cpu资源。如下图:

北京联动北方科技有限公司

北京联动北方科技有限公司

1.4.1.1.3 日志分析:

在日中发现大量的stuck状态的线程报错信息日志:

####<Feb 28, 2011 12:55:42 PM CST> <Error> <WebLogicServer> <AppWeb1.localdomain> <mServer_1> <[ACTIVE] ExecuteThread: '46' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1298868942136> <BEA-000337> <[STUCK] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "643" seconds working on the request "Http Request: /c602/connect/phoneRecord/doSearch", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
oracle.net.ns.Packet.receive(Unknown Source)
oracle.net.ns.DataPacket.receive(Unknown Source)
oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
oracle.net.ns.NetInputStream.read(Unknown Source)
oracle.net.ns.NetInputStream.read(Unknown Source)
oracle.net.ns.NetInputStream.read(Unknown Source)
oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1099)
oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1070)
oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:478)
oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
oracle.jdbc.driver.T4CPreparedStatement.fetch(T4CPreparedStatement.java:1027)
oracle.jdbc.driver.OracleResultSetImpl.close_or_fetch_from_next(OracleResultSetImpl.java:291)
oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:213)
weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_OracleResultSetImpl.next(Unknown Source)
com.jiaxun.connect.phoneRecord.data.PhoneRecordDAOQuery.query(PhoneRecordDAOQuery.java:52)
com.jiaxun.connect.phoneRecord.biz.PhoneRecordReadPortal.queryForList(PhoneRecordReadPortal.java:86)
com.jiaxun.connect.phoneRecord.ui.PhoneRecordDoSearch.doPost(PhoneRecordDoSearch.java:59)
com.jiaxun.connect.phoneRecord.ui.PhoneRecordDoSearch.doGet(PhoneRecordDoSearch.java:28)
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:225)
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:127)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
com.jiaxun.sys.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:123)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:26)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3212)
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:1983)
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1890)
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1344)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
>


引起这种问题的原因是由于在执行sql语句时,查询出了大量的数据,引起的网络上的异常。解决方法可以从优化sql语句上入手。

1.4.1.2 解决方案:


在经过了分析后,可以从以下方面入手解决,首先,由于程序中平凡的创建大量的对象为了减少full  gc的活动次数和活动时间,可以把jvm的young generations和old generations的比例作适当的调整。具体调整参数: –XX:NewRatio=n,适当扩大young generation的比例。服务器上的默认值是8.意思就是young generation:old generation=1:8。

其次,设置GC打印信息,为了观察调整后的GC详细的活动情况。参数:

-verbose:gc -Xloggc:gclog.log。


1.4.1.3 建议:


    对于OOM问题,在观察了weblogic server日志中weblogic输出的<Health>后发现,OOM并不是heap区的OOM问题,由于现场也没有更加详细的GC的日志,所以无法准确判断引起日志中报出OOM的问题原因。建议,继续对系统进行监控。




赞(0)    操作        顶端 
pengfei.li
注册用户
等级:少尉
经验:355
发帖:7
精华:0
注册:1970-1-1
状态:离线
发送短消息息给pengfei.li 加好友    发送短消息息给pengfei.li 发消息
发表于: IP:您无权察看 2014-4-15 13:58:22 | [全部帖] [楼主帖] 2  楼

注意发贴质量



赞(0)    操作        顶端 
总帖数
2
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论