受公司保密协议约束，相关系统和中间件名称替换为SystemA、SystemB、TomcatA、TomcatB、ORACLE-1、ORACLE-2。涉及的地区和实际业务都是代号。请了解系统A的初始需求：系统A的用户??在系统A上执行导出功能时，往往会导致系统A宕机。经过简单的评估，确定系统硬件不足，需要扩容迁移到云端，用X86机器代替原来的小型机。当我收到这个案例时，我首先登上了服务器看了一下。它是一个WindowsServer2003服务器。里面运行着一个Tomcat应用，但是这个应用经常内存溢出。我看了一下服务器的位数，是64位。服务器物理内存16G，实际使用6.87G。剩余的10g空闲物理内存未被使用。查看系统注册表，发现Tomcat实际启动内存为1G，明显不正常。.所以向用户申请重启，尽量增加Tomcat的实际启动内存。实际操作失败后添加内存。原因是目前部署的tomcat版本是32位的，只能识别1g内存。如果java虚拟机使用了超过1g的内存，就会报错。配置高端内存后，tomcat服务无法启动。下图是使用命令添加内存数量来测试java虚拟机是否可以正常运行。可以看到在2048m的时候报错了。实际查看DOS下tomcat的版本信息：是x8632位版本。看到这里我有点崩溃了。.对于64位的机器，如果使用32位的中间件，内存不溢出就会出现鬼影。..SystemA的上云之路SystemA的上云之路可以说是一波三折，中间经历了各种各样的问题。历时近一个半月，终于迁移成功。本以为这次终于可以牛逼了，没想到噩梦才刚刚开始。A地区的用户使用系统A来监控自己想要的业务，但是当实际业务发生时，系统A超出了它的承载能力，而且在使用云的时候，x86机器硬件测评没有做好（不过后来想了想，多亏了这个，系统被优化了，不然问题早就被高配置给掩盖了。）具体问题场景受实际业务影响，系统A和系统B的交互超过系统A处最大承载能力，A系统先出问题，B系统再出问题，两个系统瞬间宕机。在看这个Case的时候，花了好长时间，好几步，才从纷乱的现象中理清头绪。组织如下：系统A报错：java.sql.SQLException:Couldn'tperformtheoperationsetAutoCommit:Youcan'tperformanyoperationsonthisconnection。由于某种原因，它已被Proxool自动关闭（请参阅日志）。...文档中明确指出，将simultaneousBuildThrottle参数设置得太小，就会出现这个问题。知道问题出在这里，于是调整了应用中的配置文件：将simultaneousBuildThrottle参数调整为1000，增加数据池的并发处理能力。A系统和B系统的无情纠纷在上一个案子解决后的半个月内调整，又接到了一个新的案子。用户反映系统A非常卡，几乎无法使用。一开始我还是不相信，但是自己上去操作了一下，大概5分钟就点击操作了。前面说过，A系统有问题，B系统也会有问题，所以两个系统的维护都有责任。人们的矛盾开始慢慢激化。.R&D也在跟进这个问题，在TOMCAT层面对连接池和会话数的控制做了相当一部分的工作。至少当卡慢问题出现时，不会是不可恢复的，只是效率问题。至此，我开始想到系统A上云时，数据库服务器ORACLE-1的系统idle%值很低。当时判断x86性能不够，特意申请了一台高端服务器。但是作为一个技术人员，从对A系统的了解来看，目前的配置对于A系统来说应该是绰绰有余了。于是开始查看AWR报告，通宵分析TOPSQL，发现了3条会导致异常的SQL语句高CPU处理。单独执行它们大约需要1秒。貌似不会影响CPU，但是如果涉及到业务可能就不行了。这些SQL执行的频率相当高。这些SQL的优化势在必行。继续分析SQL语句。它们的共同点是在查询中使用了like关键字。然后查看对应的表结构，发现like查询的字段恰好是一个索引列。再看看like里面写的东西，再看看数据库表。like写的东西可以是独一无二的。.我不知道为什么要使用like。..谁能告诉我该怎么想？？我真的受不了这个。.这部分优化没多久，找了研发同事修改了整整一个上午。观察效果，??数据库服务器idle%提升了50%，之前是可怜的0%。优化到50%显然不是我们的最终目标。最终目标是让系统A成为一个正常的系统，cpu使用率在20%以下。于是继续在TOPSQL中查找，发现一张表的数据量级达到了900W，而且没有索引。真的醉了..谁能帮我？900w的表，delete基本不用了。问了相关负责的同事，直接执行了truncate操作。执行后cpu使用率下降到7%！！系统IDLE值已经上升到95%！！附一张对比图，数据取自AWR报告。现在没有用户说网卡慢了，因为空闲值涨了，哈哈。后续系统A是否有优化空间？答案是肯定的。经过观察，系统A有几张大表，没有分区。这肯定会影响查询。而且几个业务功能的逻辑也有优化的空间，但是因为做了上面的优化，所以这部分可以正常调度，并没有那么紧急。
