一次Linux、Tomcat和Oracle数据库优化过程

因受公司保密协定，相关系统、中间件名称由系统A、系统B、TomcatA、TomcatB、ORACLE-1、ORACLE-2所代替。涉及到的地区、实际业务均为代号，请知晓

• 系统A的初始需求：

系统A的使用用户，在系统A上进行导出功能的时候，经常会引发系统A宕机，经过简单评估，判定系统硬件不足，需要扩容并迁移到云端用X86机器替代原有小型机。

接到这个case的时候，我先登上服务器上看了一下，是一台windows server 2003服务器。
里面跑了一个Tomcat应用程序，就是这个应用程序经常内存溢出。

看了一下服务器的位数，为64位，该服务器物理内存为16G，实际使用6.87G，剩余将近10g空闲物理内存未使用，查询系统注册表，发现Tomcat实际启动内存为1G，明显不正常。。
于是向用户申请重启，尝试增加Tomcat实际启动内存的操作。

实际操作后添加内存失败，原因为目前部署的tomcat版本为32位，只能识别1g内存，超过1g内存在java虚拟机内就会报错。配置高内存后，无法启动tomcat服务。

下图为用命令添加内存数测试java虚拟机是否可以正常运行，可以看到2048m的时候是报错的。

实际用DOS下查看tomcat的版本信息：为x86 32位版本。

看到这里我就有点崩溃了。。64位的机器，用32位的中间件，内存不溢出都有鬼。。。

• 系统A的上云之路

系统A的上云之路可以说是一波三折，中间经历各种各样的问题，历时近小1个半月，终于迁移成功了。本以为这下终于可以牛B了，结果噩梦刚刚开始。

地区A用户用系统A，是为了监控他们想要的业务的，但当实际业务发生时，系统A超过了它的承载能力，并且当时上云的时候，x86机器硬件评估也没做好（不过事后想想，也多亏了这块，得到了优化这个系统，不然问题一直就被高配置给掩盖了。）

具体问题场景

受实际业务影响，系统A与系统B之间的交互超过了系统A的最大承载能力，系统A先出问题，然后导致系统B跟随出问题，两个系统瞬间宕机。

看这个Case的时候，历时很久，也经历了好几个步骤才从一团杂乱无章的现象中缕清头绪，整理如下：

系统A报错：

java.sql.SQLException: Couldn't perform the operation setAutoCommit: You can't perform any operations on this connection. It has been automatically closed by Proxool for some reason (see logs). 

当时上网查询了一些相关文档，找到一篇：

参考文档：http://www.cnblogs.com/javawe...

文档中明确指出：

simultaneousBuildThrottle参数设置过小会引发这个问题

知道问题点在这了，于是调整了一下应用程序内的配置文件：
调整simultaneousBuildThrottle参数为1000，增大数据池并发处理量。

• 系统A与系统B之间的无情纠纷

调整好了上个case不到半个月，又接到新case，用户反映系统A非常卡，几乎不能用。
刚开始我还有点不相信，结果自己上去操作了一下，点一下操作要等5分钟左右，并且之前说过了，系统A有问题会连带系统B也跟着有问题，这样两个系统的维护负责人的矛盾就开始慢慢激发了。。

研发也在跟进这方面的问题，并且做了相当一部分工作，把TOMCAT层面的连接池、Session数得到了控制，至少发生卡慢问题的时候，不会回收不了了，只是效率的问题。

到这里开始想到了之前系统A上云的时候，数据库服务器ORACLE-1的系统idle%值很低，当时判定为x86的性能不够，还特意申请了高配服务器。

但是作为一名技术人员，对系统A的了解来看，现在的配置给系统A用也应该绰绰有余。
于是开始着手查看AWR报告，分析TOP SQL

分析了一晚上，真发现了3个会导致CPU处理异常高的SQL语句。
单独执行它们，一个都在1秒钟左右，看似不会对CPU造成影响，但是关联到业务，可能就不行了，这些SQL执行的频率相当之高，千里之堤溃于蚁穴，看来这些SQL的优化势在必行。

继续分析SQL语句，它们的共性是，查询的时候都用了like关键字。
再查看对应的表结构，发现like查询的字段正好是索引列。
再看一眼like里写的东西，到数据库表里一看，like里写的东西本身就能够确定唯一性。。不知道为什么用like。。。谁能告诉我，怎么想的？？对于这个实在不能忍受。。

优化这部分，实际没用多长时间，找研发同事修改了一上午就搞定了。
结果观察效果，一下数据库服务器的idle%上升了50%，之前是可怜的0%。

优化到50%，很显然不是咱们的最终目的，最终目的是让系统A变成正常的系统，cpu占用率在20%以下。

于是继续在TOP SQL中找，发现一张表的数据量级已经到了900W，并且没有索引。

真的好醉。。。who can help me?

900w的表，delete基本是不用想了，问了下相关负责同事，直接执行truncate操作。
执行完毕后，cpu利用率一下跌落到7%！！ 系统IDLE值上升到了95%！！

附一张对比图，数据从AWR报告中取的。

现在再也没有用户说卡慢了，因为idle值上去了，哈哈。

• 后续系统A还有没有可优化空间

答案是肯定有，经过观察，系统A有好几个大表，并没有分区，这块肯定对查询有影响。
并且几个业务功能的逻辑也有可优化空间，但是因为上面的优化做完了，这块就可以正常排期，没有那么紧急了。