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

 目 录 第一章 问题现象与分析 3 1.1、问题现象 3 1.2、通常导致这种现象的原因 3 1.3、xxx社保宕机现象对比分析 4 第二章 解决方法路线图 6 2.1 jvm的调整 6 2.2 减少jvm内存使用 7 2.2.1 加快db访问速度，减少中间件并发业务量 8 2.2.2 限制sql返回结果集 8 2.2.3 减少业务会话中存放的对象 8 2.3 补救措施 9 第三章、解决结果与进一步建议 9 3.1 解决结果 9 3.2 进一步建议 10 第一章 问题现象与分析 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应