连载-从一个项目看系统优化工程(4)

连载-从一个项目看系统优化工程(4)

开发商调研

由于优化项目组决定采取白盒优化的方式实施优化，因此需要对研发团队进行深入的调研，于是优化项目组分为两个小组，分别在四川和湖北两个省与研发团队进行沟通，了解本系统的系统架构，并开始采集应用的信息。

在研发调研开展之前，优化项目组还有一件事需要完成，就是对系统的性能进行一次初步的评估。由于研发团队系统优化的经验与知识较为薄弱，因此如果优化项目组不掌握系统性能状况的一些基本情况，那么就很难与研发团队做有效的沟通，研发调研的效果会大打折扣。于是优化项目组花了三天时间，根据业务部门调研的情况，补充采集了一些系统的运行数据，并进行了分析，完成了财务系统的性能初步评估，形成了《财务系统性能初评报告》。在这次分析中，获得了比摸底分析更为准确的系统状态信息。对于应用服务器的日志的分析中，发现了大量的GC方面的问题以及内存溢出OOM的问题，甚至还发现了部分OOM in native mode的报错。在数据库方面，发现了row cache lock等待导致系统HANG住、出现ORA-4031、ORA-4030等错误的报错，也发现了大量的存储过程执行超过1分钟甚至无法执行完成的情况。这些都将成为开发商调研时重点要讨论的问题。

由于系统经常出问题，甚至经常半夜接到用户的电话紧急赶往现场应急，因此开发商的配合也比较好，我们前往调研的时候也十分配合。通过和开发商的沟通，有了十分重大的发现。

首先是通过这个项目中的一些应用架构特点我们明白了系统中为什么共享池的问题比较严重。原来时这个系统的业务模块的处理逻辑基本上是创建一张普通的表作为临时表，然后把需要处理的数据写入这张临时表，处理后可能会形成一张新的临时表，用于作为分页查询的表，同时删除之前处理时使用的临时表。20分钟后，系统的后台作业会自动删除这张作为结果的临时表，实现系统清理。这种方式会导致系统中大量的DDL存在，对共享池的影响是十分巨大的。不过这也是很多财务系统常用的处理模式，金蝶、用友等财务系统也经常使用这样的方法来处理数据。这些问题可以很好的解释系统为什么会经常出现ORA-4031，并且经常出现row cache lock等待了。

第二个十分重要的信息是这套系统的很多报表都是灵活定义的报表，报表中的每个单元表格的数据都可以自定义数据源，因此开发商无法预先对SQL进行优化，索引的设计也无法覆盖客户自定义的场景，因此全表扫描不可避免。这也为我们今后的优化方向提了个醒，索引优化有可能在后期使用过程中效果不佳。

另外一个十分重要的信息是，在沟通过程中，有位研发工程师向项目组提出了一个问题，如何提高VPD的性能。VPD，居然这个系统中使用了VPD,怪不得我们看到AWR报告中的很多SQL都十分简练，甚至很多SQL连WHERE条件都没有，原来这个项目大量使用了VPD。这也提醒优化团队在做SQL分析的时候，必须严格检查执行计划，而不能简单的根据SQL文本去做分析。因为在使用了VPD的情况下，同一条SQL，由不同的VPD规则驱动，实际上的SQL都会不同。

在业务方面，开发团队也为优化项目组提供了大量的有价值的信息，比如费用汇总模块，每年年初都挺快，到了下半年就越来越慢了，12月的汇总一个分局要几个小时，而要处理21个分局的数据，如果并发跑系统的性能问题就更严重了，串行跑要好几天时间。汇票模块也存在类似的性能问题，月初比较快，月底就很慢。还有一些汇总查询、穿透查询，正常的情况都要3分钟以上才能出结果，如果系统当时有点问题，基本上就白屏出不来结果了。这些调研结果都对于优化团队后续的优化分析至关重要，我们可以重点从这些存在问题的模块入手，对数据、业务逻辑、甚至代码进行深入的分析，从而找到优化的方法，最好是能够找到一套有效解决整体问题的方法，而不是一个一个模块的去独立解决问题。

完成开发商调研后，我们反而觉得比业务部门调研后轻松一些，开发商反馈出来的很多问题实际上都还是有解的。很可能是开发商没有很好的了解到Oracle数据库的特性，在使用Oracle数据库方面存在一些技术性的缺陷，才导致了这么严重的性能问题，如果能够找到他们可接受的优化替代方案，那么这个项目在应用优化方面的工作还是可推进的。如果应用优化能够有效进行，那么这个项目的整体优化效果也就有保障了。不过话说回来了，开发商能这么好的配合我们的工作吗？这是个问题，而且可能是决定我们优化成败的关键问题。