BlogJava-志当存高远,功到自然成!-随笔分类-应用服务器调优与管理

TOMCAT崩溃事件

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. — Wed, 11 Aug 2010 06:25:00 GMT

TOMCAT崩溃事件

http://www.blogjava.net/tedeyang/archive/2008/06/04/205740.html

今天一大早产品一部项目经理就来找我，他们的一台服务器昨天晚上tomcat服务崩溃，还不能重启服务，最后将服务器重启才OK。
我将事件过程和分析过程记录如下：

服务器：win 2000 sp4，apache 2 + tomcat 5.0 采用mod_jk级联。内存2G，硬盘剩余空间充足，CPU基本空闲。
主要应用：J2EE 1.4，JDBC（连接另一台mysql服务器）
崩溃时间： 2008-6-3 18：37：50

一.各种日志综合如下：

1.37分45秒，操作系统事件中诺顿杀毒软件报内存过低警报
2.37分45秒，web应用抛出JDBC连接异常：

2008-06-03 18:37:45 cn.*.db.DBManager.getConnection(DBManager.java:157) ERROR swim.db.DBManager com.mysql.jdbc.CommunicationsException: Communications link failure due to underlying exception:
** BEGIN NESTED EXCEPTION **
java.net.SocketException
MESSAGE: java.net.SocketException: No buffer space available (maximum connections reached?): JVM_Bind

3.37分50秒，tomcat抛出session无法save异常：

2008-06-03 18:37:50 ERROR- IOException while saving persisted sessions: java.io.FileNotFoundException: "izzs"SESSIONS.ser (系统资源不足，无法完成请求的服务。)
java.io.FileNotFoundException: "izzs"SESSIONS.ser (系统资源不足，无法完成请求的服务。)
    at java.io.FileOutputStream.open(Native Method)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:70)
    at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:511)
    at org.apache.catalina.session.StandardManager.unload(StandardManager.java:485)
    at org.apache.catalina.session.StandardManager.stop(StandardManager.java:687)
    at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4496)
    at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3037)
    at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4658)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1619)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1608)
    at java.lang.Thread.run(Thread.java:534)

二.简单分析

崩溃原因：内存不足导致资源不足，引起Tomcat的session崩溃。
这台服务器上运行着很多应用，是什么原因引起内存不足还无法确定。
初步判断罪魁祸首可能是apache，该进程平常占用500MB内存，经常会飚到1G以上。

Apache2的配置文件中：KeepAlive=On，MaxKeepAliveRequests=100，KeepAliveTimeout=15，分析aceess.log文件可以发现每个页面触发的request数量在10个以下，点击率较低，可能使连接过多。
我建议将keepAlive设为off，增加CPU负载，降低内存消耗。

三.效果

有待观察......

参考资料：
http://www.withend.com/post/78.html

四.结局
时隔一天，晚上九点再次崩溃，黑暗事件重演。
这一次，我才得知原来该apache还配置有其他域名，于是调出该域名下的access.log。项目经理去了机房，在轰轰地风扇声中打电话给我，让我分析分析。
仔细看访问日志，发现原来有N多Connect 443连接，443是什么？是SSL端口！HTTPS！，Connect命令则显然是代理功能！
而且这些connect的IP来自全球各地，加拿大、美国、澳洲、新西兰、北京、上海、英国、哪都有。
看来这台服务器是被人当代理服务器用了。
怪不得半夜会死机，人家西半球那时正大白天撒欢儿呢。

问题就出在apache的配置上，由于应用众多，并且这台服务器还是其他几台web服务器的对外出口，因此apache中配置了反向代理，不过不小心把正向代理（mod_proxy模块的ProxyRequests 指令）也打开了。
看看apache2.0的官方文档中mod_proxy部分，里面明明白白写着：

警告
在您没有对服务器采取安全措施之前，请不要用ProxyRequests启用您的代理。一个开放的代理服务器不仅对您的网络有威胁，对整个因特网来说也同样如此。

真的是很有威胁！大量代理请求急剧消耗内存，最终造成死机！

解决办法就是把正向代理关掉：ProxyRequests Off

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. 2010-08-11 14:25 发表评论

一次weblogic调优的经过

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. — Thu, 04 Sep 2008 05:30:00 GMT

项目组反应数据库有问题，
检查发现sga还用的默认参数，缓冲区命中率很低。根据系统内存调整后，好像系统正常了。数据库调整就算是结束了
一天后，我再登这个数据库的时候，发现一个提示说线程已经超过限制，不允许再登录。然后我去修改了process到250，增加并发连接数。然后重启了数据库。当天没发生什么事情，第二天，发现250又被撑满了，这个时候，我就开始换衣中间件有问题，登入中间件那边看了下日志，一直报错，提示无法打开新的连接。一般来说，中间件连接数据库能开10个都算可以了。至少websphere是这样，weblogic应该差不多。然后修改了一下，调整了weblogic的连接池，修改最大连接到100.

1、报错信息

<2008-4-22 上午04时33分18秒 CST>

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>

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>

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>

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>

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>

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>

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.查看跟踪信息比较调整前后性能：

调整前内存

调整后情况：

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

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. 2008-09-04 13:30 发表评论

weblogic]weblogic 8.1.4服务器挂起,出现StuckThreadMaxTime错误

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. — Thu, 04 Sep 2008 05:02:00 GMT

前几天用spring+hibernate+struts写了个增/删/改/查的例子。调试期间问题就来了，当查询结果翻页好几次就没N久没有响应了。最后控制报错。网上查了，它说数据库连接（池）问题。

出现错误如下:

[2007-9-30 下午12时03分03秒 CST] [Error] [WebLogicServer] [BEA-000337] [ExecuteThread: '13' for queue: 'weblogic.kernel.Default' has been busy for "901" seconds working on the request "Http Request: /admin/school.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.]

<转为[，>转为]，才发得出以上面错误。可能是javaeye的bug。

先说下我配置

1.环境：

spring 2.0.6，hibernate 3.2.3，struts 1.2.9，oracle 10.2，weblogic 8.1.4

jdbc是ojdbc14.jar

2.连接池用DBCP

xml 代码

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
bean>

3.分页方法（参考springside的），此类继承HibernateDaoSupport

java 代码

public Page listByPage(Class entityClass, int pageNo, int pageSize, List criterions, List orders) {
Criteria criteria = createCriteria(entityClass, criterions);
CriteriaImpl impl = (CriteriaImpl) criteria;
// 先把Projection和OrderBy条件取出来,清空两者来执行Count操作
Projection projection = impl.getProjection();
//获取总记录数
int totalCount = ((Integer) criteria.setProjection(Projections.rowCount()).uniqueResult()).intValue();
if(totalCount < 1) {
return new Page();
}
//加排序
if(orders != null) {
for(int i=0; i
criteria.addOrder((Order) orders.get(i));
}
}
//原来的投影
criteria.setProjection(projection);
int startIndex = Page.getStartOfPage(pageNo, pageSize);
//取得结果
List list = criteria.setFirstResult(startIndex).setMaxResults(pageSize).list();
return new Page(startIndex, totalCount, pageSize, list);
}
public Criteria createCriteria(Class entityClass, List criterions) {
Criteria criteria = getSession().createCriteria(entityClass);
if(criterions != null) {
for(int i=0; i
criteria.add((Criterion) criterions.get(i));
}
}
return criteria;
}

另外，没有用OpenSessionInViewFilter，struts与spring的整合：DelegatingRequestProcessor、action path与bean name同名。

翻页不过10次，服务器就没响应了，最后出现上面的错误的了。

问题解决，问题的原因是数据库连接耗尽，我用HiberanteDaoSupport的getSession()方法取得Session后没有释放Session。

出问题的代码处：

java 代码

public Criteria createCriteria(Class entityClass, List criterions) {
Criteria criteria = getSession().createCriteria(entityClass);
if(criterions != null) {
for(int i=0; i
criteria.add((Criterion) criterions.get(i));
}
}
return criteria;
}

用完Session释放后就没事了，调用HiberanteDaoSupport的releaseSession(session);方法后即可解决。

现在正确的代码：

java 代码

public Page listByPage(Class entityClass, int pageNo, int pageSize, List criterions, List orders) {
Session session = getSession();
//创建criteria
Criteria criteria = session.createCriteria(entityClass);
//为criteria添加criterions
createCriteria(entityClass, criteria, criterions);
CriteriaImpl impl = (CriteriaImpl) criteria;
// 先把Projection和OrderBy条件取出来,清空两者来执行Count操作
Projection projection = impl.getProjection();
//获取总记录数
int totalCount = ((Integer) criteria.setProjection(Projections.rowCount()).uniqueResult()).intValue();
if(totalCount < 1) {
return new Page();
}
//加排序
if(orders != null) {
for(int i=0; i
criteria.addOrder((Order) orders.get(i));
}
}
//原来的投影
criteria.setProjection(projection);
int startIndex = Page.getStartOfPage(pageNo, pageSize);
//取得结果
List list = criteria.setFirstResult(startIndex).setMaxResults(pageSize).list();
//释放hiberante资源,一定要释放,要不然就数据库连接耗尽.
releaseSession(session);
return new Page(startIndex, totalCount, pageSize, list);
}
public Criteria createCriteria(Class entityClass, Criteria criteria, List criterions) {
if(criterions != null) {
for(int i=0; i
criteria.add((Criterion) criterions.get(i));
}
}
return criteria;
}

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. 2008-09-04 13:02 发表评论

WEBLOGIC调优方案

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. — Mon, 30 Jun 2008 12:55:00 GMT

注：在下面做的介绍都是以Weblogic8.1为例的，其它版本的Weblogic可能会有些许不同。
1) 设置JAVA参数；
a) 编辑Weblogic Server启动脚本文件；
l   BEA_HOME\user_projects\domains\domain-name\startWebLogic.cmd(startWebLogic.sh on Unix)
l BEA_HOME\user_projects\domains\domain-name\startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix)
b) 编辑set JAVA_OPTIONS命令，如：set JAVA_OPTIONS=-Xms256m –Xmx256m；
c) 保存，重启即可。
注：在WebLogic中，为了获得更好的性能，BEA公司推荐最小Java堆等于最大Java堆。
2) 开发模式 vs. 产品模式；
开发模式和产品模式的一些参数的默认值不同，可能会对性能造成影响，下面是对性能有影响的参数列表：
参数         开发模式默认值         产品模式默认值
Execute Queue: Thread Count         15 threads         25 threads
JDBC Connection Pool: MaxCapacity         15 connnections         25 connections
通过启动管理控制台，在域（如：mydomain）> 配置 > 常规选择产品模式。
3) 尽量开启本地I/O；
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 配置 > 调整选择启用本地I/O。
注：此值也可通过手动的修改config.xml配置文件。
4) 调优执行队列线程；
a) 修改默认执行线程数
在这里，执行队列的线程数表示执行队列能够同时执行的操作的数量。但此值不是设的越大越好，应该恰到好处的去设置它，太小了，执行队列中将会积累很多待处理的任务，太大了，则会消耗大量的系统资源从而影响整体的性能。在产品模式下默认为25个执行线程。
为了设置理想的执行队列的线程数，我们可以启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 监视 > 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数，据此确定理想的数值。
理想的默认执行线程数是由多方面的因素决定的，比如机器CPU性能、总体体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。随着CPU个数的增加，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。在测试中，可以以25*CPU个数为基准进行调整。当空闲线程较少，CPU利用率较低时，可以适当增加线程数的大小（每五个递增）。对于PC Server和Windows 2000，则最好每个CPU小于50个线程，以CPU利用率为90%左右为最佳。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置中修改线程计数。
b) 设定执行队列的溢出条件；
Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置下面几项：
L 队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。
L 队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。
L 线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和内存不是足够的高，尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。
L   最大线程数：为了防止创建过多的线程数量，可以通过设定最大的线程数进行控制。
在实际的应用场景中，应根据具体情况适当的调整以上参数。
c) 设定执行队列监测行为
Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态，可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities文档。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置下面几项：
l   阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。
l   阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了 "阻塞线程最长时间" 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为 600 秒。
5) 调优TCP连接缓存数；
WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置“接受预备连接”。
6) 改变Java编译器；
标准的Java编译器是javac，但编译JSP servlets速度太慢，为了提高编译速度，可以使用sj或jikes编译器取代javac编译器。下面说说更改Java编译器：
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 常规下改变Java 编译器，默认为javac。输入完整路径，如：c:\visualcafe31\bin\sj.exe。然后打开高级选项，在预规划到类路径填写编译 Java 代码时为 Java 编译器类路径预规划的选项，如：BEA_HOME\jdk141_02\jre\lib\rt.jar。
7) 使用Webogic Server集群提高性能；
具体关于如何配置Weblogic集群，我就不细说了。详情可参考：Introduction to WebLogic Server Clustering。
8) Weblogic EJB调优
由于EJB2.0已经很少项目在用了，EJB3.0再成熟一点，我再补充这一部分吧！
9) JDBC应用调优
JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。
增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。
尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。
最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology ... tdocs/jdbc9201.html。
10) JSP调优
l   设置jsp-param pageCheckSeconds=-1；
l   设置serlet-reload-check=-1或ServletReloadCheckSecs=-1；
l   设置jsp-param precompile=true，关闭JSP预编译选项。(转载)

存鹰之心于高远,取鹰之志而凌云,习鹰之性以涉险,融鹰之神在山巅. 2008-06-30 20:55 发表评论