3月24日 简单任务 （1）令人意外的开始

今天第一天到用户现场，我到香格里拉酒店和老方会合，老方在原厂，出差必须享受五星级标准，我就觉得400多块钱的酒店有点奢侈，住在旁边的迎宾馆。迎宾馆是原来的市委招待所，后来改造成了一个三星级酒店，虽然房间有点旧，不过十分干净。很大的院子，里面十分安静。最关键的是，一个市政府的朋友帮我打了个很不错的折扣，不到200块的价格是我选择这里的很重要的因素。

客户在开发区，从市区打车过去要40多分钟，在车上老方给我介绍了这个项目。老方是这个项目的负责人，前期也担任了售前的任务。听老方介绍，这是一个短信平台的优化项目，用户的优化目标是整体处理能力升25%以上，并没有对CPU资源、IO等提出明确的优化目标。听这个指标，好像优化目标并不高，老方也觉得这是个很简单的任务，只要花点心思优化几个SQL，就应该不难达到优化目标。在出租车上的这段时间，我们两个都很轻松，老方甚至考虑到不要过早结束项目的问题，因为客户出了一个不错的价格，如果我们过去三下两下就解决了问题，客户是不是会觉得钱花的有点冤枉。

上午是项目启动会，甲方的项目经理姓余，是个80后的美女，高挑的身材，说话甜甜的，听着比较舒服。从甲方对项目的期望来看，确实像老方所说，不算太高，比我们以前做的项目要相对简单一些。这是一个短信平台的系统，目前在平时是没有任何问题的。只有在中秋节和春节期间会出现性能问题，导致短信话单无法正常入库，严重的时候，为了确保短信系统能够正常运作，会出现应用软件被迫丢弃话单的情况。对于运营商来说，丢弃话单就意味着话费的流失，每年由于丢弃话单导致的话费流失达到数百万之巨。这还不是最大的问题，由于丢失的短信话单有可能是某个SP的业务短信，这就会导致SP业务收入方面的损失。为了确保业务高峰期不丢失短信话单，甲方希望通过本次优化能够将目前每秒最大入库短信量从1200条左右提高到1500条以上。其他方面的优化，能实现多少就算多少了，只要事务平均响应时间能够提升20%以上项目就可以验收了。

今天参加开工会的除了甲方外还有开发商华为的技术人员，华为方面对这次优化的态度十分友好，他们也希望我们能够对他们的系统的性能方面提出一些有益的建议，以便于改进他们的系统，他们表示只要我们提出的优化建议，一定在20个工作日内完成修改工作。

今天这个会只开了个把小时，就在友好的气氛中结束了。甲方的小余帮我们在旁边的ADC项目组的办公室里找到了两个空座位，然后是申请网禁，申请工作账号等工作。运营商在安全方面管的比较严，填写了数份表格，复印了身份证，甚至在安全责任书上按了指印，终于可以连到服务器上了。看看时间已经是中午11点50了，于是我和老方两个先锁了电脑屏幕，到外面去找吃饭的地方。

老方对这个地方也不熟悉，我们两个转了半天，终于发现了一条比较热闹的街道，街道两边有几家饭店和一个不大不小的超市。老方是山西人，比较喜欢面食，于是我们两个在一家规模比较大的饺子馆吃了一顿饭。虽然是在西南，不过这家饺子馆还颇有北方的风味，两个人吃的都比较满意。回来的路上我顺便在超市里买了一个喝水的杯子，我这个人好喝茶，不过每次出差总是忘记带杯子。还好我喜欢喝绿茶，随便找个茶杯就可以泡茶了。于是每到一个地方，我总是先找超市买茶杯。

回到办公室的时候，已经快2点了。客户中午两点上班，办公室里不少人还躺在简易床上睡午觉。我先把杯子洗了洗，泡上一杯茶，然后登录到系统上去看了看。客户的这个短信平台分为两个区，分别负责半个城市的业务。这两个区根据机房的地点被命名为人和平台和南坪平台，服务器是IBM 的P系列服务器，操作系统是AIX 5.3。南坪平台是早期建设的平台，数据库是8.1.7.4的版本，人和平台是前几年扩容的平台，数据库版本是9.2.0.6。

我首先查看了一下,两套系统的Statspack都是新装的，开了自动采样，估计这还是老方上个月来这里做售前的时候装的。我在南坪平台上把今天上午9：00-10：00的Statspack报告生成了一份打开看了看，每秒逻辑读和物理读的数量都很小，逻辑读只有五、六千。平均每秒的事务数也只有0.93个。想起刚才小余说过的，这套系统平时的时候负载很轻，CPU使用率都只有20%左右，IO也很闲。确实如她所说，现在是下午两点多，CPU的使用率只有10%多一点。我继续往下看Statspack报告，也没有发现什么开销较高的SQL。排名第一位的SQL是一条INSERT语句，是向一张SM_HISTABLE插入一条记录，根据表名判断，这就应该是那张短信话单表。这条语句在一个小时内执行了59万次，平均算下来每秒也不到200条。这条语句每次执行产生的逻辑读数量为14.2个。浏览了一遍Statspack报告，除了部分SQL没有使用绑定变量，应分析比例有点高之外，我也没有发现什么明显的问题。因为没有采集到业务高峰的数据，所以没有发现什么明显的问题也很正常，不过突然我发现了一个更为严重的问题，就是刚才我浏览TOP SQL这一节的时候，看到的单次执行开销最大的SQL也不过每次执行产生了不到2000个逻辑读。这说明系统中并无很多高开销的SQL，这样一来，早上我和老方商量的优化几个高开销SQL的计划就很难实施了。

我急忙把老方叫到门外，我们两个点上一支烟，然后我把刚才的发现告诉了他。老方也觉得有点意外，因为客户这次优化的目标并不高，老方认为达成优化目标没有任何问题，因此对于这套系统，他并没有像以往那样在售前阶段进行详细的分析。

我刚才发现，这套系统十分简单，除了那条开销最大的插入语句，只有少量的SELECT语句，而且大多数SELECT语句都是根据主键MSG_ID访问的，只有少量通过PHONE_NO查询的。在这样一套系统中做优化，想从SQL入手，估计难度较大，我们必须另辟蹊径。

如果不从SQL入手，我们该从哪里开始呢?这么简单的应用，通过操作系统和数据库参数方面的调整想要提升20-30%的性能，是不大现实的。调整应用的架构可能是最佳选择，不过这样的话，对应用调整过大，华为方面估计也会有很大的阻力。

讨论了半天，我和老方也没想出什么好的办法，于是我建议还是先找华为的开发人员了解一下应用的情况再说。从目前的情况看，只能先搞明白应用的关键瓶颈，再去想办法了。

经过了解，我才大体明白了这个系统中的关键问题。这是一个短信平台中的后台系统，用于存储和管理短信话单。来自短信平台的话单首先会存储在内存缓冲中，然后被后台进程批量写入数据库中。每个平台都配置了8个并发的写入进程，用于短信话单的写入操作，每次写入的批量为800条。他们也曾尝试过增加写入进程和增加写入批量的数量，不过效果不明显。SM_HISTABLE是一张分区表，首先他们设计了每个月一张话单表，表名为SM_HISTABLEyymm，每张表又按照每天一个分区，分为多个分区，分区主键是CREATED_DATE。每条话单都有一个唯一性的主键MSG_ID，话单插入后，后续处理中主要根据MSG_ID来查询话单数据，在做UPDATE数据的时候，一般都采用ROWID条件进行UPDATE，这方面也不会有性能问题。

从这种简单的应用系统来看，我们能够进行优化的点并不多。看样子我们需要认真的考虑一下这个特殊的应用，想想如何来完成这个现在看来很不简单的简单任务了。