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

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 宕机的原因：OutOfMemoryJNI程序jvm的bugos的bug1.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 bytesforChunkPool::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无法瘦身（医保业务用），目前应收预览速度要有质的飞跃还很难。

2.2.2 限制sql返回结果集采用方法：从底层编写监控sql返回的大结果集程序，可定制记录数等参数实际效果：目前已经抓到很多大sql，返回的结果集从几千达到10几万以上，基本消除了大结果集造成的原因，长期部署可对新程序新业务的大结果集检验有非常大的好处。

2.2.3 减少业务会话中存放的对象采用方法：减少会话中的存放对象数，把没有必要或不需要使用的对象从会话中清除。

实际效果：这是一个备用手段，由于是改动了程序，为了生产安全考虑，暂时没有部署，在其它手段没有效果的情况下经过测试后再把它加载上去。

2.3 对本地读写的定位通过对大量ibm java core分析，发现有读写I/O导致的堵塞。

2.4 补救措施方法：在应用服务器上部署一个test.html静态页面，同时在负载均衡器上配置对这个静态页面的定时访问。

结果：通过8月份业务的实际运行考验确实起到了作用，7月份当一台服务器没有响应的时候马上就有业务人员反映，8月份却没有，同时我们也发现了的确新的请求就不再发给问题服务器，重新启动后新请求一点一点的加载上来，改善是很有效果的。

第三章、解决结果与进一步建议3.1 解决结果通过两个月周期的现场分析、调整，目前应用服务器系统稳定性已经明显提高了。

尽管月底个别高峰的时候还会出现系统没有响应情况，但通过其它手段弥补已经不会影响业务的运行。

分析导致系统宕机因素是多方面的，包括java平台的原因，程序大结果集的原因，表数据量大/sql程序不够优化的原因，阵列I/O性能的原因、并发大业务的等原因。

这些原因往往交织在一起，呈现出各种系统宕机状况。

但最终只要我们提高sql的运行速度，降低jvm 的内存使用量，把握好大的结果集和大的业务对象使用，尽管jvm本身有不稳定的情况，也不会或很少出现jvm宕机现象的。

3.2 进一步建议✓优化或升级现有阵列目前整体系统的瓶颈在I/O上，希望考虑阵列升级计划。

✓对目前业务数据和程序做一个周期瘦身和优化方案从系统整体性能分析看，不良的I/O状况，越来越多的上亿记录的表导致大量对数据库操作业务缓慢，使中间件服务器并发量瞬时增加，中间件服务器的负载量加重，也成为中间件的宕机的一个主要原因。

✓优化本地I/O读写，将日志调试信息去掉。

✓对新业务继续监控大结果集（目前部署在11、12上）。

✓对新业务继续要做及时监控，抓大sql（耗I/O量大，运行次数多，阻塞其它业务）。