中间件优化（1）
在前期的调研和日志分析中，大家都发现中间件出的问题比较多。从目前数据库的负载上看还较小，不过如果中间件的问题解决后，数据库的负载压力会明显的加大。中间件的问题主要集中在部分模块SQL执行时间较长，经常超时，以及经常出现OOM。
按理说整个系统有12个WLS实例，系统的并发用户量不大，为什么经常会出现OOM呢？难道是应用中很多模块都存在内存泄漏？通过在线的数据分析以及和开发商的深入沟通，我们否定了这种可能性。内存泄漏在项目刚刚上线时候确实存在，那时候系统只要跑上一天，当天晚上如果不重启中间件，第二天就可能出现OOM甚至宕机。经过一段时间的分析与优化，这些存在内存泄漏的模块在一年前就基本上都整改完了。通过我们对GC以及JVM堆内存的监控数据的分析，我们也能确认这一点，堆内存并不存在随着时间线逐步推高的趋势，而是围绕着一条基本上不变的基线做上下波动。
虽然通过堆内存的监控数据分析排除了应用模块内存泄漏的可能性，不过对于堆内存的基准曲线我们也看到了一些疑点。WLS启动后不久，这个堆内存的使用量基线就特别高，系统运行一天左右后，这个堆内存基线就维持在一个十分高的位置，哪怕半夜没什么人使用这个系统的时候也是这样。目前JVM的设置是2GB，也不算小了，按理说堆内存的使用率基线不应该总是处于这么高的高位。
要想弄清楚这个问题，一个最简单的方法就是去看看这套系统的WAR包里都有些什么东西。把WAR包打开以后，优化项目组的人恍然大悟了。原来这个系统经过这几年的不断完善，整合了大量外围功能，将以前的十几个小系统的功能都整合到了这个系统中。而开发商并没有对这些小系统的代码进行重构，很多都是采用了简单集成的方法。每个小系统用到的一些基础组件的版本也没有进行统一。经过简单的分析，我们就梳理出了一张示意图出来。
都不需要看具体的应用了，光这些框架组件就够应用服务器喝一壶了。在JVM中，这些jar包都需要经常访问，因此都需要在JVM中进行缓存。通过下面这张图，就可以更为清晰的看出问题所在了。
由于不同的应用都使用了互相不兼容的框架组件，因此这些应用模块越来越多的情况下，JVM的堆内存的启动水位线也就被推的很高。所有模块的最低内存使用量累加已经让堆内存的水位线十分高了，当多个模块的内存使用量同时出现高峰的时候，就会出现OOM了。
应用服务器存在的另外一个问题是，各个应用模块之间都使用独立的连接池。原本这种设计是一种十分好的架构设计，可以用于隔离不同模块，防止互相干扰。不过由于本系统的模块粒度十分小，很多十分小的应用模块也使用独立的连接池。因此哪怕没有任何用户在使用这个系统，数据库连接池中的最小连接数量也十分多。
这个问题导致的另外一个问题是，应用的启动十分缓慢，如果应用服务器宕机，重启一下的时间至少要十多分钟，其中大多数时间是数据库连接池创建的耗时。
至此，WEBLOGIC的主要问题都呈现在我们眼前了，如何解决这些问题呢？
