3月25日 简单任务 （2）解决之道

今天一早老方就回北京了，昨天晚上我和老方一直在讨论这个项目，从采集到的信息来看，只能通过调整操作系统、数据库的参数，以及调整表的一些参数来达到提升系统总体性能的目标。而对于系统性能来说，最为关键的也就是大量的话单插入操作。目前话单插入是由8个并发进程完成的，每次的插入批量试800条记录。

既然实际情况和预先估计的有出入，那也只能硬着头皮上了。今天我主要要分析一下在哪些环节可以进行优化，以及每个环节可能的性能提升比例，从而为优化计划的制定提供一个基础。另外采集性能基线的工作也同时在进行，由于这个项目的特殊性，我们无法采集去年春节期间的数据了。这种系统，非业务高峰期的性能数据比较的意义不是很大。通过昨天的分析，在平时，每天的话单量在2000万条左右，而在中秋节和除夕，话单量可能达到1亿8千万到2亿。按照忙时集中系数为0.1计算，在平时，每天最忙的1个小时内，产生的话单量为200万条，折算到每秒钟产生的话单量为555条，而业务高峰期的量可能达到5550条。平均分配到两个系统，每个系统每秒要处理近3000条话单，才能确保系统不出问题。由于华为的系统中有内存缓冲区，可以进行一定程度的平滑高峰处理，因此华为方面提出能够达到每秒处理2000条话单以上的处理能力，就可以保证不丢话单，而目前华为工程师的测试结果为系统处理能力仅能达到1500条话单，这个优化项目，能够做到性能提升50%，就可以确保万无一失，提升25%以上，可以基本达到华为的最低要求。仅仅想通过调整系统参数和表的存储参数来实现这个目标，确实是具有一定的挑战性。

上午我分析了系统的主要等待事件，以及各个缓冲区的情况：

从主要缓冲池的指标上来看，没有明显的问题。而从主要等待事件上看，主要都集中在和IO相关的项目上。看样子IO系统的写性能指标并不好。另外REDO LOG相关的等待事件占整个等待事件的21%,REDO LOG看样子存在优化的可能。

从Statspack报告上看，每个小时的redo buffer allocation retries为483次，目前的LOG BUFFER为1M，加大LOG BUFFER可以减少这方面的等待。而目前共有16个日志组，每个日志组1个文件，每个文���60M。从日志切换情况来看，今天业务高峰期平均1分钟多一点切换一次日志。由于无法查看去年中秋节期间的数据，因此我只能推算，如果业务量加大10倍，那么每隔5、6秒钟就会产生一次日志切换，这样对系统的性能就会产生较大的影响。看样子，加大LOG BUFFER，增加REDO LOG文件的大小，性能提升10-15%还是很有可能的。

从今天的STATSPACK报告中，我们没有看到明显的BUFFER BUSY WAITS，一个小时也只有几百个BUFFER BUSY WAITS等待。通过测算，现在每个系统每秒的话单量不到300条，而每个插入的批次是800条，因此多个插入进程同时插入数据的机会较少，热块冲突不会很明显，而如果业务量增加10倍，那么热块冲突可能会变得很严重。目前南坪系统的数据库是8.1.7.4，人和系统的数据库是9.2.0.5。两套系统都没有使用自动段空间管理(ASSM)。通过检查，发现freelists参数都是缺省的1，这对于并发插入操作会有较大的影响。加大freelists参数，不仅仅可以减少并发插入时分配空块的等待，而且不同的插入进程会使用不同的freelists，因此不同的插入进程不会往同一个数据块中插入数据，从而避免不同的插入进程之间在业务高峰期间可能出现的热块争用。根据以往的经验，如果freelists设置合理，减少了这方面争用可能带来的性能提升可能达到5%-10%。

目前核心表SM_HISTABLE是每天一张独立的表，每张表都是分区表，表中设置了一个专门的分区字段ID_HINT，进行范围分区，这个字段的值是循环使用的，到达10000000后自动回绕为1，分区脚本如下：

这种分区模式对于减少热块冲突帮助不大，不过如果调整了FREELISTS参数后，热块冲突的严重程度也会下降，对性能的影响也不会特别大。不过如果能把不同的分区放到不同的磁盘组上，那么使用HASH分区比范围分区在IO负载均衡方面的作用就更为明显了。于是我马上要来了系统底层存储的设计文档。南坪系统的底层设计了多个磁盘组：

人和系统使用的是72G的磁盘，20块磁盘做成RAID 10,在VG划分的时候做了stripe。从底层存储的设计上，对于南坪系统，如果使用HASH分区，可以将IO均匀的分配到5个盘组上，从而避免业务高峰期的IO热点。这方面的调整，根据以往的经验，可以提升性能10-15%。

在ID_HINT列上，使用了一个SEQUENCE，ID_SEQ，我检查了一下，这个SEQUENCE的CACHE设置为1000，根据我以往的经验，设置为1000一般来说也够用了，不过下一步我们还需要进一步测试一下，CACHE设置的更高是否可能带来性能的提升。

从刚才的分析来看，我们目前可以达到的系统性能提升为1-（1-0.1）*（1-0.05）*（1-0.1）=23%。这是一个比较保守的数字，实际上提升的比例可能更高。因此通过这些方面的调整达到预定的优化目标还是很有可能的。

实际上，对于INSERT操作来说，使用BULK INSERT操作可以大幅度提升插入的性能，不过使用BULK INSERT，对于华为来说，应用需要做较大的修改，昨天在讨论方案的时候，华为方面感到如果要在短时间内完成修改，有些为难。而用户也希望把BULK INSERT作为最后的解决方案，可以作为建议提出来，华为在下一步的优化工作中进行修改，但是不列入本次优化的范围。

今天是在分析问题的过程中度过的，因此感觉过得很快。快下班的时候，老方打电话过来，说今天在武汉飞机晚点，刚刚到北京。一下飞机他就打电话询问情况。我说通过一天分析，感觉通过我们昨天考虑的几方面的优化，性能提升30%还是比较靠谱的。老方听后长舒了一口气，在飞机上他一直在考虑这个项目在售前阶段过于自信，没有做深入的分析，最终能不能让客户满意。

和老方通完电话，我给客户的余经理打了个电话，问她能不能安排一个业务不是很忙的时间，让我做一些针对性的实验，以便于确定优化方案。余经理说这是一个后台系统，我可以随便进行测试，只要不让话单积压过于严重，导致话单丢失就可以了。于是我连忙联系华为的维护工程师，和他讨论如何避免系统话单积压。华为的维护人员说他们本身就有一个实时监控系统，如果话单缓冲区占用率超过60%，就会产生告警，只要缓冲区保持在60%以下，风险就不是很大。于是我们约定好，明天白天我就开始进行一系列实验，一旦系统出现风险，他们马上通知我，我立即停止实验。