性能调优是个永恒的话题。从我多年的工作经验来看，没有问题的性能几乎是不存在的！不过，有问题并不一定需要调优：可能是没必要，比如用了很好的机器也就遮盖过去了；客户认可也就不需要调了（曾经碰到一个程序运行40分钟，只是一个人使用，她也就忍受了），还有很多方面的原因，在这就不一一解释了。通常需要解决的性能问题是没有办法了，比如cpu100了，业务无法正常操作了，一般都是到这个时候才想起需要对性能进行优化了。今年有幸参加了某银行电子银行系统的优化，前后耗费几个月的时间，最好总算有所成，基本解决了性能问题。这个系统的性能出现的问题可以是说非常严重，也非常奇怪，在下午，还没有到最高峰的时候，cpu会从20直接冲到100，也就几秒钟的时间。但业务量并没有明显的提高，而实际上，cpu100的时候处理能力是略微下降的。按照一般的做法，cpu达到100忙，我们应该增加cpu，但如果那样操作，会有适得其反的效果，这个待稍后解释。由于严重影响了电子银行系统的正常运行，所以我和的人都不能走了，天天在现场分析。开始的时候并不是很顺利，通过停止业务的方法，似乎有效果，但似乎有没有效果。当时cpu一到100，就停业务，要不把个人停了，要不把企业停了，有时候好像cpu就好了，但实际上都没有效果。确切来说是找不到解决的方法。经过几天的分析，认为有些表非常繁忙，sybase香港建议把忙的表做des绑定。第二天我们执行了这个操作，有一定的效果，但没有解决根本问题。我们监控着，看到数据库的spinlock竞争一直在增加，终于到了90的时候，cpu又完全100了！！！我在前一天找到了一种方法，文档上说，如果碰到cpu异常高，又没有确切原因的话，可以使用这个方法（好像挺玄，嘿嘿）。当时，我觉得很像我们碰到的现象，就把这个东西给sybase香港人说，他看了，认为不是相关的（所以说，有时候专家的话也不能信）。在没有办法的时候，我就做了这个操作（是挺大胆的，毕竟是生产系统，如果有负面问题，那就麻烦了！）。结果非常非常的好，cpu马上下来了，且比之前的高峰还有低一些。当时的感觉真的很好，大家终于可以回家了，哈哈！后来sybase解释说，这个操作改变了内存的替换策略，从而减少了spinlock的竞争，cpu也就不忙了。ase15在p6上的spinlock竞争确实非常厉害，这个问题在原先ase12.5+p5上就没有。
解决这个问题还真不是靠内存分区。因为通过sysmon显示，是object的spinlock的竞争很高，最高的时候超过90。不是cache的，虽然这个问题解决之后也碰到了cache的spinlock高。ase15增加了很多查询策略，因此其找到一个好的查询计划的时间大大增加。如果针对的sql语句本身执行时间很长，还不是问题。但如果是很短的sql语句，这个时间占的比重就很高了。我碰到的一个案例，从12.5升级到15，一个程序（由很多执行很短的sql语句组成）运行的时间提高了2~3倍，可以认为多出来的时间就是编译的时间，大约是每个sql语句在10ms这个量级。因为这个原因，ase引入了statementcache，也就是对于重复执行的sql语句，不需要再编译，找到以前已经编译好的计划就可以。这个措施对于此类sql语句还是非常有效的。上面这个案列打开以后，其执行时间就跟12.5上差不多，稍微增加了一些。当然，这个措施也有它的问题，如果由于变量不同，导致sql语句应该使用不同的查询计划时，就会带来一定的问题。再来说电子银行这个案例，由于之前的经验，所以我们也打开了这个参数，并且设置该内存为1g。出现这个问题后，我们也试着关闭了statementcache，但cpu有明显的升高，比原先要高一倍左右。这个结果用户不能接受，所以又调整回去了。sysmon一直显示objectsspinlock竞争非常激烈，而在文档中的解决办法就是des绑定。这也是为什么我们做des绑定的原因。我们担心没有绑定出问题的表，因此，做了尽可能多的绑定。操作最多的前100个表都做了绑定。说起
第92章解决