记录一次出差广东对中间件性能优化的完整报告

某某系统性能分析优化报告

一、背景

        2014年1月份以来XX系统多次频繁出现访问量上去后，系统查询SQL语句提交到oracle数据库进行查询未及时返回时，很容易出现后台线程挂起，而XX系统并发数较高达到每一个节点200多个连接，总连接数达到800多，WAS线程池未能及时释放，最终导致线程池耗尽，需要定期重启WAS才能解决；当前利用运维监控管理系统每隔30分钟监控，无法访问时短信报警，然后人工重启，基本上一周要重启两到三次，同时分析中间件日志对Oracle数据库进行优化，但是效果不佳。

        公司高度重视用户、项目组反馈的情况，在公司内部安排资深研发人员、系统架构师分析现场项目组发回的系统日志，中间件日志，排查系统可能存在的隐患点，并安排资深技术专家到现场进行排查，解决系统性能问题。

       2014年4月14人日我到现场，与XX单位李主管、公司分公司总经理曾某、现场项目组负责人许某就目前XXX系统存在的性能情况做了沟通，收集系统存在性能问题现象、可能的规律，主要有以下方面：

      1、系统运行一段时间后综查系统访问变慢，访问出错，见下图1-1。

图1-1

2、 当访问量急剧增长时出现，JDBC数据源连接上升很快，系统请求变慢，响应时间变长，系统查询长时间没有响应，如下图1-2。

图1-2

     3、服务器消耗CPU资源达到97%、内存资源消耗达到50%，见下图1-2。

图1-3

       上述三种情况都需要通过人工重启中间件才能解决。

二、原因分析过程

        我到现场后通过分析XX系统中间件日志、服务器参数设置；对近几年的系统访问日志按照年、月、日等不同角度做了对比，通过数据可以分析得出XXX系统的访问量呈线性增长，访问量一直都非常高，综合以上几个因素初步定位了系统引起宕机的主要原因，在用户数高并发时，中间件WebSphere线程池非常繁忙，引起JVM垃圾回收不能及时有效处理，最后导致XXX系统中间件线程挂起宕掉。

      （一）、检查服务器、中间件设置并进行参数优化

1、检查操作系统红旗Linux的内核参数设置，内核参数中最大可用内存限制为2G，修改内核参中最大可用内存为32G。

2、查看分析近一周中间件日志，日志主要表现在当系统出现高峰访问时有部分数据源因连接超时而关闭。

3、查看中间件系统配置，修改JVM的最小堆最大堆分别由1024M、2048M改为2048M、4096M。

4、更改应用服务器会话管理由1000增大到2000，超时时间设置由30分钟缩小为10分钟，加快未使用资源的释放。

5、统计各个数据源所引用的查询方案使用较高的，增加数据源的连接池最小以及最大连接数。

6、调整数据源的超时设置，加快GC回收精准度。 

（二）、系统运行监控、日志分析，精确定位问题原因

         按照上述分析思路对XXX系统进行监控，验证分析结果。

        2014年4月15日-2014年4月16日，两天对XXX系统的运行情况进行跟踪分析，并增加一个概要节点运行，增加系统的压力的分担，监控结果显示：

1、当业务高并发时（上午9:30-11:30，下午14:30-17:30），XXX系统都是在消耗资源库数据源(JDBC/XXX)的连接池，连接池资源释放非常慢。

 2、因已对中间件JVM虚拟机内存进行修改加大，并且又增加了一个was实例运行，目前系统尚稳定。

3、系统资源消耗情况，CPU资源消耗很低，内存消耗16G左右，没有太大波动。

 4、修改负载均衡器的负载策略，改变原来的源IP最短响应负载策略为轮询负载策略，5个节点目前访问数量基本一致。

 5、与研发人员沟通分析是否程序代码存在内存泄露或连接未关闭的情况。

 6、查看中间件日志发现部分方案存在配置问题，查询会报错，主要查看117节点，而117节点在16、17日两天中间件的JDBC资源一直得不到释放。

（1） XXX方案的分段代码分段不能查询，SQL 拼接缺少AND符号；

（2）VW_001表的XXXZHM字段不存在；

（3） VW_002的XXXHM字段不存在；

（4） VW_003的XXX_ID字段不存在；

（5）VW_004的XXZH字段不存在；

（6） VW_005的XXXSFHM字段不存在；

              以上是日志中报错的一部分，现场还需要对整个日志分析，直到所有的方案都不会报错。

              综合以上分析，原因基本定位，采取优化措施并对剩余节点重点处理了以下措施：

（1） 修改服务器的内核参数对内存的限制，4台服务器全部修改。

（2）修改中间件的JVM虚拟机大小，最小堆和最大堆分别为2048M、4096M。

（3） 调整硬件负载均衡器的负载策略，设置10个连接为起点进行轮巡的负载策略

（三）、综合分析其他三个单位的性能问题

 1、A单位经观察主要原因是部分数据资源的连接不能释放，长时间运行后会出现堆积。

 2、A单位业务高峰期观察应用服务器JDBC繁忙数最高20个，CPU达到96%以上，内存占用达到22G，磁盘IO不明显，仅占用很小的200kB/s，经过业务高峰期后，系统能回复业务低谷时的资源占用水平。

 3、B单位主要是因为网络原因造成以及数据源连接不能得到释放。

 4、C单位查看了一个节点，主要原因也是因为数据源的连接不能得到释放。

三、A单位系统及B、C单位系统性能优化处理措施 

1、对每一台服务器查看中间件日志，根据出错的信息对出错的方案进行调整。【非常重要】

2、调整中间件的JVM虚拟机内存，修改为初始堆2048 M、最大堆4096 M（前提是操作系统没有限制）。

一台服务器内存为32G，建议先增加一个概要文件（从目前A单位情况来看，服务器的CPU在业务高峰期压力较大）。

3、设置会话管理中的内存溢出，禁止溢出，设置超时时间为15分钟。

4、修改内存会话由1000增加到2000。

5、修改应用程序的会话个数由1000增加到2000，并设置禁止内存溢出

6、修改数据源的超时时间，针对应用访问量大服务器设置连接超时、收集时间、未使用超时、时效超时分为60、60、60、50，针对访问量中等的设置为120、120、120、300，针对小访问量设置为180、180、180、240。

7、修改线程池的default的最小大小20、最大大小100，webcontainer的最小30、最大150。(A单位系统中间件default的最小大小20、最大大小100，webcontainer的最小30、最大200) 

8、开启容器服务的ORB按引用传递服务，开启web容器的servlet高速缓存。

9、修改后监控应用系统在业务高峰期的JDBC连接，并分析中间件日志是否存在错误日志。

10、建议对中间件的补丁进行安装，最新版本补丁一定程度上在代码层面做了优化，websphere中间件6.1最新补丁版本号为6.1.0.47, websphere中间件6.0的最新补丁版本号为6.0.2.43。