文档章节

weblogic调优的经过

 突突突酱
发布于 2018/10/24 16:43
字数 1881
阅读 13
收藏 0

项目组反应数据库有问题,
检查发现sga还用的默认参数,缓冲区命中率很低。根据系统内存调整后,好像系统正常了。数据库调整就算是结束了
一天后,我再登这个数据库的时候,发现一个提示说线程已经超过限制,不允许再登录。然后我去修改了process到250,增加并发连接数。然后重启了数据库。当天没发生什么事情,第二天,发现250又被撑满了,这个时候,我就开始换衣中间件有问题,登入中间件那边看了下日志,一直报错,提示无法打开新的连接。一般来说,中间件连接数据库能开10个都算可以了。至少websphere是这样,weblogic应该差不多。然后修改了一下,调整了weblogic的连接池,修改最大连接到100.
1、 报错信息
<2008-4-22 上午04时33分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT
hread: '1' for queue: 'weblogic.kernel.Default' has been busy for "102" seconds
working on the request "Http Request: /guestAction.jsp", which is more than the
configured time (StuckThreadMaxTime) of "60" seconds.>
<2008-4-22 上午04时33分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT
hread: '7' for queue: 'weblogic.kernel.Default' has been busy for "178" seconds
working on the request "Http Request: /guestAction.jsp", which is more than the
configured time (StuckThreadMaxTime) of "60" seconds.>
<2008-4-22 上午04时34分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT
hread: '0' for queue: 'weblogic.kernel.Default' has been busy for "111" seconds
working on the request "Http Request: /guestAction.jsp", which is more than the
configured time (StuckThreadMaxTime) of "60" seconds.>
<2008-4-22 上午04时34分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT
hread: '1' for queue: 'weblogic.kernel.Default' has been busy for "162" seconds
working on the request "Http Request: /guestAction.jsp", which is more than the
configured time (StuckThreadMaxTime) of "60" seconds.>
<2008-4-22 上午04时35分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT
hread: '0' for queue: 'weblogic.kernel.Default' has been busy for "171" seconds
working on the request "Http Request: /guestAction.jsp", which is more than the
configured time (StuckThreadMaxTime) of "60" seconds.>
<2008-4-22 上午04时35分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT
hread: '12' for queue: 'weblogic.kernel.Default' has been busy for "111" seconds
working on the request "Http Request: /guestAction.jsp", which is more than the
configured time (StuckThreadMaxTime) of "60" seconds.>
<2008-4-22 上午04时36分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT
hread: '12' for queue: 'weblogic.kernel.Default' has been busy for "171" seconds
working on the request "Http Request: /guestAction.jsp", which is more than the
configured time (StuckThreadMaxTime) of "60" seconds.>
2、 判断可能存在部分sql语句未优化,造成执行时间过长(request超时)造成挂死
3、 解决
开发模式和产品模式的一些参数的默认值不同,可能会对性能造成影响,下面是对性能有影响的参数列表:
参数 开发模式默认值 产品模式默认值
Execute Queue: Thread Count 15 threads 25 threads
JDBC Connection Pool: MaxCapacity 15 connnections 25 connections
通过启动管理控制台,在域(如:mydomain)> 配置 > 常规选择产品模式。
修改了server-myserver参数中的threadcount参数,按照cpu数量,修改为100
修改jdbc数据库连接池,修改为初始15,最大100。
晚间进行跟踪,系统运行正常,高峰时段,尤其是早晨的高峰时段,系统没有再出现挂死的问题。
早晨点击页面查询发现有时会出现页面无法访问的情况。
跟踪发现weblogic最高时有100多并发,同时注意到内存占用比较高,检查发现,原来内存配置较低。
检查原配置文件:
:bea
if "%PRODUCTION_MODE%" == "true" goto
bea_prod_mode
set JAVA_VM=-jrockit
set MEM_ARGS=-Xms96m -Xmx256m
set
JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none
goto
continue
:bea_prod_mode
set JAVA_VM=-jrockit
set MEM_ARGS=-Xms128m
-Xmx256m
goto continue

:sun
if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode
set
JAVA_VM=-client
set MEM_ARGS=-Xms32m -Xmx200m -XX:MaxPermSize=128m
set
JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none
goto
continue
:sun_prod_mode
set JAVA_VM=-server
set MEM_ARGS=-Xms32m
-Xmx200m -XX:MaxPermSize=128m
goto continue
很明显配置为96m,最高256m。修改后的参数:
修改后结果为
:bea
if "%PRODUCTION_MODE%" == "true" goto
bea_prod_mode
set JAVA_VM=-jrockit
set MEM_ARGS=-Xms256m -Xmx768m
set
JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none
goto
continue
:bea_prod_mode
set JAVA_VM=-jrockit
set MEM_ARGS=-Xms256m
-Xmx768m
goto continue

:sun
if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode
set
JAVA_VM=-client
set MEM_ARGS=-Xms256m -Xmx768m -XX:MaxPermSize=128m
set
JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none
goto
continue
:sun_prod_mode
set JAVA_VM=-server
set MEM_ARGS=-Xms256m
-Xmx768m -XX:MaxPermSize=128m
goto continue
:continue

最低256,最高768.查看跟踪信息比较调整前后性能:
调整前内存

调整后情况:

现在垃圾回收不那么频繁了,整体稳定性应该有好处。再频繁打开一个页面的情况下,页面仍然能正常显示。
第二种解决办法:

最近生产环境下的系统经常出现以下的错误提示,
####<2007-7-2 下午04时07分20秒 CST> <Error> <WebLogicServer> <gis> <portalServer> <weblogic.health.CoreHealthMonitor> <<WLS Kernel>> <> <BEA-000337> <ExecuteThread: '5' for queue: 'default' has been busy for "1,165" seconds working on the request "Http Request: /tzzmWeb/saye/regie/census/customertoMtn/custcheckout.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>
该问题是由于处理custcheckout.do请求超时引起的,系统配置的处理时间是600s,但是该线程处理了1165s后,仍然没将请求释放,所以报了这个错误。如果发送该请求较多,很有可能会导致weblogic的线程阻塞,严重会引起weblogic挂起现象。
可以通过以下几种方法解决:
1)修改StuckThreadMaxTime参数,将默认的600s改成1200s,或者其它适合的值。
2)增大线程数,防止线程阻塞问题。
3)优化程序,减少处理时间。
第三种解决办法:
最近,服务器weblogic经常报异常:
<Error> <WebLogicServer> <BEA-000337>
<[STUCK]ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'has been busy for "640" seconds working on the request "Http Request: /jsp/cn/modelshow/m_hbrow.jsp", which is more than the configured time (StuckThreadMaxTime) of "600"seconds.
该异常出现的原因是资源请求的时间超出了weblogic设定的600s,造成资源排队请求,如果类似的操作很多的话,那么会造成大面积的资源请求队列,从而引起weblogic无法正常提供服务,严重时引起weblogic崩溃。那么这种原因是如何导致的呢?
首先,我们从测试服务器上发现,出现这种情况的原因是因为该请求的时间过长,于是从该请求的数据处理过程入手进行分析,发现该请求的sql语句,在sql/plus下执行时间过长,如下:
select c.*
from ( 
select t.*,rownum r 
from (
select RGGT_ID,CPMC,PPMC,TITLE,MTMC,
MTRQ,WZZT,LRRQ,INFO_SIGN,ZYMC,BRIEF 
from co1003_2239_data 
where (1=1)
and (
INFO_SIGN in ('网络新闻','媒体电子版','品牌新闻')
and PPMC <> '业内动态'

order by mtrq desc,ppmc desc
) t 
) c
where rownum<21
该表大概225W数据,在sql/plus下执行时间超长,造成请求weblogic反应时间超出默认值,从而引起资源排队请求的问题,引起服务器不稳定运行。那么出现了这种问题,怎么解决呢?我们的解决方法是对该sql语句进行优化处理:
1:对INFO_SIGN,PPMC等字段建立规范表,从数据库中进行查询,尽量减少in的使用
2:对<>等操作符不使用,使用> or <等方式来代替
3:尽量减少排序order by,rownum的使用,只在关键时刻进行使用,其他时刻能够不使用的就不进行使用。

通过以上方式来减少资源请求时间,从而减少以上异常的发生,来保证服务器的正常运行。

© 著作权归作者所有

粉丝 2
博文 293
码字总数 206929
作品 0
私信 提问
加载中

评论(0)

weblogic 执行队列处理请求分布问题。

服务器: weblogic10.3.5 + linux 测试功能: 系统提供一个票据下载功能,此功能单独分解成两步骤,一个下载用户验证,另一个是下载, 测试场景: 500个合法用户同时并发下载5个票据信息。 ...

保罗的寓言
2012/03/14
1.4K
0
weblogic优化问题

我weblogic版本为10.3.6,部署方式是建一个域,又通过管理台托管几个子域,在子域上部署应该,更新应用都是覆盖更新程序文件后通过weblogic进行更新生效。现在一个问题就是,更新之后执行激活...

王金豆
2015/12/23
278
1
Closing socket as no data read from it on 127.0.0.1:11,514 during the configured idle timeout of 5 secs

Closing socket as no data read from it on 127.0.0.1:11,514 during the configured idle timeout of 5 secs 这是在weblogic中运行程序的时候发生的,而且是刷新页面的时候发出的警告,程序...

哎哎哎哎啊
2013/09/10
6.4K
0
解决替换weblogic的commons-fileupload.jar后引发的问题

上一篇博文中提到通过替换weblogic自带的commons-fileupload.jar来解决FileUpload类的NoSuchMethodError问题。在完成替换后,该问题得到顺利解决,但是也会引发其他的一些问题,下面提到的这...

彭苏云
2014/01/21
964
0
国内首位中间件Oracle ACE:WebLogic执行线程耗尽解决方案

作者介绍 王超,国内第一位中间件ORACLE ACE,东方宏达中间件技术总监,原ORACLE|BEA 资深中间件现场支持工程师,14年现场支持工作经验,WebLogic 6.1/7.0/8.1/9.2/10.3/11g/12c、Tuxedo技术...

王超
2016/08/16
0
0

没有更多内容

加载失败,请刷新页面

加载更多

007. J.U.C 之锁的使用

1. Lock API 1. Locks 包类层次结构 2. Lock 接口 方法签名 描述 void lock(); 获取锁(不死不休) boolean tryLock(); 获取锁(浅尝辄止) boolean tryLock(long time, TimeUnit unit) throws ......

紫穹
58分钟前
64
0
如何确定Python变量的类型? - How to determine a Python variable's type?

问题: How do I see the type of a variable whether it is unsigned 32 bit, signed 16 bit, etc.? 如何查看变量的类型,无论是无符号32位,带符号16位等等? How do I view it? 我该如何看...

javail
今天
164
0
略谈分布式系统中的容器设计模式

本文作者:zytan_cocoa 略谈分布式系统中的容器设计模式 谭中意 2020/3/5 前言:云原生(Cloud Native)不仅仅是趋势,更是现在进行时,它是构建现代的,可弹性伸缩的,快速迭代的计算网络服...

百度开发者中心
03/11
168
0
a small thing that made me a little bit depressed

It was just two hours ago,specificly speaking It was 11:48 almost coming close to midneight. I was pratising singing songs in my renting room which is a sharing apartment . I re......

lost_myself
今天
154
0
OSChina 周日乱弹 —— 这中间几个月的地震、核爆、外星人、高达... 去哪了

Osc乱弹歌单(2020)请戳(这里) 【今日歌曲】 @薛定谔的兄弟 :分享洛神有语创建的歌单「我喜欢的音乐」: 《Elizabeth》- Ashram 手机党少年们想听歌,请使劲儿戳(这里) @巴拉迪维 :#共...

小小编辑
今天
275
1

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部