为什么不这样和为什么会这样

和一些朋友交流技术问题的时候，我很喜欢与经常问出“为什么会这样”的朋友沟通，因为这代表了一种希望了解和理解别人的想法的心态。而我最不愿意和经常说“为什么不这样”的人交流，因为在他的世界里，别人总是不大对的，自己的观点和立场才是正根。“为什么不如何如何，为什么非要这样”，可能经常说这样话的朋友自己都没有感受到，他在讨论和分析一个问题的时候，已经排除了大量的可能性了。

为什么系统出问题了不能先去优化SQL，为什么非要去调整数据库的参数；IO不足了为什么不能去扩容IO能力，非要和数据库较劲；既然Oracle软件里没有强制要求许可证，为什么就不能随便用用。为什么不代表了某种自我的立场，而某些问题是可以在一个更为广泛的范围内去思考和探讨的。只有更广泛地探讨，才能把问题考虑得更加周到。

就拿数据库优化来看吧，早期的用户往往连参数都设置不好，存储系统的条带设置也与数据库不匹配，在基础的底层出现的问题会导致数据库的负载稍微高一点就会出问题。这种情况下，如果非要揪着SQL不放，非要强调SQL优化，那么最终的结果不会太好。

我这些年做优化工作，遇到过太多的喜欢说“为什么不这样”的人。十多年前有套系统的weblogic总是出现OOM的问题，当时我建议用户做个整体分析，找出OOM的根源再对症下药。用户那边的开发处处长就属于那种“为什么不这样”的人，他觉得JVM出OOM，那肯定是应用写得不好，你来做优化，只要把消耗内存比较大的应用模块和SQL找出来就行了，其他的问题他自然会找开发商去搞定，不需要我们费心。我和他沟通了几次没有效果，只能按照他的思路来，找了几十个比较消耗内存的模块和SQL去优化，不过依然没啥效果，该宕机还是宕机。

后来他们上级的主任受不了了，直接把我叫过去骂了一顿，说为什么做了这么长时间优化还是不断宕机。我只好如实汇报，并说如果非得按你们给划下的道来做优化，那就只能修修补补。要想彻底解决问题，必须按照我们的方案，做一次全面排查才行。

后来经过全面分析发现JVM的问题是OOM IN NATIVE CODE，WLS实例宕机是因为32位的系统超过了4GB的物理内存而引发的。而造成这个问题的最主要原因是他们的 应用开发不够规范，不同的应用模块开发团队各自为政，没有统一管理。

WLS服务启动后，不用跑啥应用，各种框架的JAR包就把JVM内存占了一大半了。业务并发量大一点，就出问题了。定位了问题后面就好办了，统一一下开发框架，临时性把应用拆分一下，就能解决这个问题。分拆后，哪怕应用写得再烂，起码也不会宕机了。

那个处长大人被他们领导逼着按照我们的方法增加了几个WLS实例，同时把应用部署分拆到两个WLS集群中后，weblogic不宕机了。不过和我们的关系更加恶劣了，给后续的优化工作添了不少堵。

在做数据库优化的时候，同样的问题依然出现，我们通过日志等发现他们的 系统存在没有启用大页和AIX 操作系统的AIO参数MAXREQS等设置不合理的问题。在十多年前这是在AIX平台上十分经典的数据库配置问题。没有启用大页可能会导致Oracle 10g启动一段时间后页表过大，SYS CPU使用率增高，数据库性能整体下降，而AIX的AIO参数设置不合理的问题更加严重，会导致IO负载较高的时候数据库宕机。在日志中我们已经看到了他们已经出现过几次因为AIO SERVER数量配置不足而导致宕机的记录，因此我们建议他们调整。

这回遇到了和上回一样的问题，处座坚持认为数据库的问题都是应用开发商写的SQL不好引发的，只要把SQL优化好一切都迎刃而解了，于是我们也只能照办。幸运的是，某一天因为AIO的问题，系统出现了接二连三的宕机，惊动了上面的大领导，于是我们又被主任叫过去，责令我们尽快解决。于是上回的场景重演，很快我们就通过调整参数完成了这两个变更，顺便把MAXPERM%等不合理的操作系统参数，以及一些不合理的数据库参数都调整了。这个项目算是顺顺利利地进行下去了。

没有人是天生的无所不知无所不能的人，能知晓和掌控一切，也没有任何事情是绝对的，“为什么不这样”的执念会让你受限于自己的思维模式与技术能力限制，因此少一些这样的执念对于任何人都是有好处的。遇到问题能够多问问“为什么会这样？”，能够从多个角度去考虑问题，能够去倾听别人的想法，哪怕对你而言不是那么高明的想法，并从别人的角度多去考虑考虑问题，做事情会更科学一些。而对于你个人而言，可能也会进步得更快一些。