系统应用服务器内存溢出解决报告

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

XXX系统应用服务器内存溢出解决报告

xxxx股份有限公司

2010.9

目录

第一章问题现象与分析 (2)

1.1、问题现象 (2)

1.2、通常导致这种现象的原因 (2)

1.3、xxx社保宕机现象对比分析 (3)

第二章解决方法路线图 (4)

2.1 jvm的调整 (4)

2.2 减少jvm内存使用 (5)

2.2.1 加快db访问速度,减少中间件并发业务量 (5)

2.2.2 限制sql返回结果集 (6)

2.2.3 减少业务会话中存放的对象 (6)

2.3 补救措施 (6)

第三章、解决结果与进一步建议 (6)

3.1 解决结果 (6)

3.2 进一步建议 (7)

第一章问题现象与分析

1.1、问题现象

XXX应用服务器经常有内存溢出、系统没有响应的现象,尤其在每月的月末最为明显。

目前的应用服务器有三种类型,其中ibm和linux应用服务器报告频繁出现内存溢出或没有响应的现象,hp unix应用服务器相稳定。在出现问题期间Weblogic无法响应任何客户端请求,大量请求加载到了这台没有响应的Server上,最后只有杀掉并重启这台应用服务器。

1.2、通常导致这种现象的原因

WLS Server 没响应可能的几种原因:

1、繁重的I/O,呼叫DB时间过长导致中间件内存耗尽,server没有响应。

2、程序死循环,loop-backs,这种情况cpu很忙,系统没有响应。

3、连接到外部server,没响应,由于网络等原因

4、2个以上的执行者同步死锁

5、业务量过大,全部线程都被占用,出现队列等待现象

6、读写本地I/O,发生阻塞

WLS Server 宕机的原因:

OutOfMemory

JNI程序

jvm的bug

os的bug

1.3、xxx社保宕机现象对比分析

✓应用服务器没有响应分析

通过初步判断,对于xxx应用服务器没有响应的情况可以做如下排出法解决:

――程序死循环

这种情况会导致cpu非常繁忙,而通过目前观察,每次系统没响应的时候,cpu没有一直100%忙,另外,对出现问题时的java core分析没有发现这类线程,因此可以基本排除这种可能,。

――连接到外部server,没响应,由于网络等原因

目前我们的业务基本都是直接通过中间件访问数据,没有通过应用服务器间调用或多数据库调用的,基本排除这种可能。

――2个以上的执行者同步死锁

这种情况有可能,但比较难找,一般都是业务高峰的时候才有可能出现,跟应用人员了解后得知我们很少使用同步方式实现对资源的共享。另外通过对javacore进行分析,并未发现同步造成的死锁现象。

――业务量过大,全部线程都被占用,出现队列等待现象

通过观察我们的业务量在高峰时确实很大,但由于我们配置的线程数都很高,尽管出现宕机时也没有达到配置的上线,所以这个方面可以被排除。

――繁重的I/O,呼叫DB时间过长导致中间件内存耗尽

由于我们经常有新业务变更,尤其近期还有居民医保业务上线,因此I/O问题导致

的因素也需要重点考察!

――读写本地I/O,发生阻塞,多线程耗尽jvm内存

这种现象很可能发生,应重点给予关注

✓对WLS SERVER 宕机的几种情况的分析:

――OufOfMemory

目前xxx社保应用服务器出现宕机的时候基本都表现为这种现象,这也是中间件服务器最常见的现象。原因可能有多种,可能是平台的,多数情况下是物理内存配置过低,或jvm参数配置过低造成的。但通过对xxx社保配置参数进行分析发现参数基本合理,除了线程数和连接池配置稍大点,其它都很正常。由此分析是估计是其它原因造成的。

其它可能的原因可能是平台原因,比如jvm版本、垃圾回收方式和算法的缺陷等;

也可能是应用造成的,比如业务并发量过大,内存不足造成,也可能是返回大结果集以及会话存放对象过多等原因。因此重点是找出可行的解决方案,避免出现内存溢出,减少对jvm内存的使用量。

――平台bug

比如jni、jvm、os的bug等。每个weblogic版本都有对应的平台Jni,用来增加系统性能,但有时表现出不稳定的现象。Jvm和os版本对WLS server的稳定更是影响很大,通过以前的记录发现ibm和linux的应用服务器比hp出现的宕机频率更多些,因此有必要对ibm和linuxjvm做些分析和调整。

第二章解决方法路线图

通过前面分析把解决问题的路线图定位在三方面,一个是调整现有平台jvm版本和参数,尽量达到平台的稳定性;另外一个是考虑如何减少jvm内存的使用上,尤其要解决访问DB慢以及返回大结果集这两方面,以期通过增强访问速度减少并发量,减少返回结果对内存的占用,从而使系统不发生或少发生OutOfMemory现象。另外,在意外出现宕机的情况下,通过负载均衡器的配置实现新请求直接发送给其它运行正常的服务器。

2.1 jvm的调整

采用方法:

调整ibm应用服务器的jvm 系统参数kcluster等,消除内存碎片。

调整linux应用服务器的jvm ,由bea的jrockit到sun jdk。

实际效果:

Ibm服务器jvm为1.4.2,由于本版本的垃圾回收算法问题,会出现内存碎片,7月份相应调整了jvm参数,不过还是宕机很多次,没有明显效果。通过对8月份ibm

服务器一次宕机javacore分析,发现在高峰阶段jvm还是会出现heap lock资源

等待现象,经查ibm资料,基本上还是证实是内存碎片过多,并发申请内存太多导

致系统无内存可用,最后宕机。不过8月份已经好很多了,才发现一次。这种情况

目前最好方法是通过减少并发量来解决,由于应用的原因目前还无法升级jvm。

Linux服务器的jvm通过从jroick调整到sun后,在7月份就效果就很好。在8月份系统出现一次没有响应了,当时内存还是剩余很多的,现象也是

OutOfMemory,但同时报sun javaException in thread "CompilerThread0"

ng.OutOfMemoryError: requested 32760 bytes

forChunkPool::allocate. Out of swap space?

经查这种现象跟在linux平台上jvm虚拟机不稳定有关,但这种现象不会经常出现。

2.2 减少jvm内存使用

想办法减少jvm内存使用量是解决问题的关键,减少应用服务器瞬时的并发量是一个好的途径,这就要保证快速的DB访问,小的结果集返回,session中少量的保存对象,同时会话保持不宜过长。

2.2.1 加快db访问速度,减少中间件并发业务量

采用方法1:通过oracle oem等工具跟踪监控大量耗I/O的语句,同时监控其它影响db服务器运行慢的进程。

实际效果:项目组调整低性能的sql后,该部分业务明显加快,没有再发现相关业务的大量全表扫描等情况。

采用方法2:对影响应收预览速度的ac40瘦身,重建并进行了分区。

实际效果:根据现场反映速度有些提升。但由于对另外一个影响速度的关键表ab30无法瘦身(医保业务用),目前应收预览速度要有质的飞跃还很难。

相关文档
最新文档