某某系统性能分析优化报告
一、背景
2014年1月份以来XX系统多次频繁出现訪问量上去后，系统查询SQL语句提交到oracle数据库进行查询未及时返回时。非常easy出现后台线程挂起，而XX系统并发数较高达到每个节点200多个连接，总连接数达到800多，WAS线程池未能及时释放，终于导致线程池耗尽，须要定期重新启动WAS才干解决。当前利用运维监控管理系统每隔30分钟监控。无法訪问时短信报警。然后人工重新启动，基本上一周要重新启动两到三次，同一时候分析中间件日志对Oracle数据库进行优化，可是效果不佳。
公司高度重视用户、项目组反馈的情况，在公司内部安排资深研发人员、系统架构师分析现场项目组发回的系统日志，中间件日志，排查系统可能存在的隐患点，并安排资深技术专家到现场进行排查，解决系统性能问题。
2014年4月14人日我到现场，与XX单位李主管、公司分公司总经理曾某、现场项目组负责人许某就眼下XXX系统存在的性能情况做了沟通，收集系统存在性能问题现象、可能的规律，主要有下面方面：
1、系统执行一段时间后综查系统訪问变慢，訪问出错，见下图1-1。
图1-1
2、 当訪问量急剧增长时出现，JDBC数据源连接上升非常快，系统请求变慢，响应时间变长，系统查询长时间没有响应。例如以下图1-2。
图1-2
3、server消耗CPU资源达到97%、内存资源消耗达到50%。见下图1-2。
图1-3
上述三种情况都须要通过人工重新启动中间件才干解决。
二、原因分析过程
我到现场后通过分析XX系统中间件日志、server參数设置。对近几年的系统訪问日志依照年、月、日等不同角度做了对照，通过数据能够分析得出XXX系统的訪问量呈线性增长。訪问量一直都非常高，综合以上几个因素初步定位了系统引起宕机的主要原因，在用户数高并发时，中间件WebSphere线程池非常繁忙，引起JVM垃圾回收不能及时有效处理，最后导致XXX系统中间件线程挂起宕掉。
（一）、检查server、中间件设置并进行參数优化
1、检查操作系统红旗Linux的内核參数设置，内核參数中最大可用内存限制为2G，改动内核參中最大可用内存为32G。
2、查看分析近一周中间件日志。日志主要表如今当系统出现高峰訪问时有部分数据源因连接超时而关闭。
3、查看中间件系统配置，改动JVM的最小堆最大堆分别由1024M、2048M改为2048M、4096M。
4、更改应用server会话管理由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） 改动server的内核參数对内存的限制。4台server所有改动。
（2）改动中间件的JVM虚拟机大小，最小堆和最大堆分别为2048M、4096M。
（3） 调整硬件负载均衡器的负载策略，设置10个连接为起点进行轮巡的负载策略
（三）、综合分析其它三个单位的性能问题
1、A单位经观察主要原因是部分数据资源的连接不能释放。长时间执行后会出现堆积。
2、A单位业务高峰期观察应用serverJDBC繁忙数最高20个，CPU达到96%以上。内存占用达到22G，磁盘IO不明显，仅占用非常小的200kB/s，经过业务高峰期后。系统能回复业务低谷时的资源占用水平。
3、B单位主要是由于网络原因造成以及数据源连接不能得到释放。
4、C单位查看了一个节点。主要原因也是由于数据源的连接不能得到释放。
三、A单位系统及B、C单位系统性能优化处理措施
1、对每一台server查看中间件日志。依据出错的信息对出错的方案进行调整。【非常重要】
2、调整中间件的JVM虚拟机内存，改动为初始堆2048 M、最大堆4096 M（前提是操作系统没有限制）。
一台server内存为32G，建议先添加一个概要文件（从眼下A单位情况来看，server的CPU在业务高峰期压力较大）。
3、设置会话管理中的内存溢出。禁止溢出，设置超时时间为15分钟。
4、改动内存会话由1000添加到2000。
5、改动应用程序的会话个数由1000添加到2000。并设置禁止内存溢出
6、改动数据源的超时时间，针相应用訪问量大server设置连接超时、收集时间、未使用超时、时效超时分为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。