性能调优及故障诊断思路

一、性能调优
1.数据源连接池及请求池
最大连接数（maxActive）、最小连空闲数（minIdle）、最大空闲数（maxIdle）、超时时间（maxWait）
如果没有连接池则性能差，如果连接数过多则维护成本大，既要解决线程阻塞，又要避免线程死锁。
2.jvm调优
最大堆（-Xmx）、最小堆（-Xms）、垃圾回收策略、详细垃圾回收。
-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=C:/Users/admin/Desktop/oom.hprof
实践：最大堆与最小堆大小一致尽量设置大些效果明显
3.高速缓存
redis….
二、故障诊断
1.查看应用服务器CPU使用是否过高
检查方式：topas
可能原因：有程序业务逻辑比较复杂，导致占用CPU过高
处理方案：kill -3 was线程号，获得javacore，分析javacore中正在执行的应用程序逻辑是否过于复杂。
2.查看应用服务器jvm开销是否过高
检查方式：开启was性能监控检查HeapSize以及UsedMemory
可能原因：有过大的数据读写产生或者是未使用合理的垃圾回收机制导致。比如文件上传或者数据查询
处理方案：kill -3 was线程号，获得javacore，分析javacore中这在执行的应用程序的执行逻辑，是否存在未加条件的查询或者文件上传功能；检查jvm参数中垃圾回收机制。
3.查看数据库连接数是否正常
检查方式：开启was性能监控，检查JDBC连接池参数：poolSize、waiteTime、free pool size
可能原因：连接池设计不合理导致多线程在等待连接
处理方式：修改jdc连接池大小，增加最小值和最大值；或者数据库存在死锁，需要进一步检查数据库情况
4.查看web服务器内存是否开销过高
检查方式：开启was监控，检查线程池poolSize
可能原因：was连接池最大值设置过小，导致IHS请求一直等待was连接池释放，从而引起web服务器内存开销过高。或者was挂起，导致连接一直无法释放。
处理方式：修改was连接池大小，重启was。
5.出现javacore报警
检查方式：was profile目录下是否存在javacore、heapDump等文件，使用javacore、heapDump文件分析工具分析
可能原因：
*IBM NOOM: native out of memory ,该问题可能是由于was的bug导致的，目前遇到的情况是，将was在64位服务器上分配内存地址时，如果was jvm大小设置为2G，可能会导致内存溢出，目前解决方案将was jvm大小设置为4G
*search oom：该问题一般是由于未加限制条件的数据库查询，导致入大量数据被读如内存引起的
*upload oom：上传out of memory ，上传文件文件中未限制文件数量，导致大批量数据被读入内存引起
*Download oom：下载服务器文件，先将所有文件读入内存，然后转换成输入输出流下载导致javacore
*restart oom：发布版本后未重启was，导致was中可能存在内存泄漏的未被完全释放而引起的javacore