极品狂医 第92章解决

        性能调优是个永恒的话题。

    从我多年的工作经验来看，没有问题的性能几乎是不存在的！不过，有问题并不一定需要调优：可能是没必要，比如用了很好的机器也就遮盖过去了；客户认可也就不需要调了（曾经碰到一个程序运行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个表都做了绑定。

    说起来这个操作还是起了一定的作用。

    至少是延缓了问题的发生。

    原先问题在2点到2点半左右就会出现，绑定后问题在3点多出现的。

    插一句话，sybase香港那个人的水平还是挺高的，经验也很丰富，他是做pse，从产品方面给出了很多建议，也给我们一些脚本，帮助了问题的定位。

    我跟sybase，还有客户的人，都有10年以上的sybase经验，还是没那么容易忽悠的，呵呵！包括，后来的sybase美国的专家，也是很有水平的。

    虽然原来想派的一个没到，好像叫peter，听说那个人去年用户大会的时候过来了，可惜那天我有事走了。

    言归正传，说起问题的解决办法，不能不提到一个人：robverschoor，熟悉sybase的人很多都知道他吧。

    我也是在找不到办法的情况下，到网上查找解决问题的方法。

    然后就找到了这位老兄的一篇文章，他提到了如果碰到cpu有不明原因的繁忙时，可以使用一个757的traceflag，同时清除一下内存。

    第二天，在sybase香港建议的方法无效后，我就大胆使用了这个方法。

    执行完毕后，效果是立竿见影，cpu马上落下来了，而且比之前正常的时候还有低！后来sybase做了解释，这个traceflag改变了内存的替换策略，从而降低了cpu的spinlock。

    而且我们发现，仅仅使用这个traceflag，object的spinlock还会慢慢上升，需要定期清空才能降下来。

    后来发现，statementcache不能设置太大，原来的1g改成了100m，就不需要定期清空内存了！这个案例给我的两点是，一是cpu忙不一定要加更多的cpu；二是内存并不是越大越好！写了这么多，希望有人能从中得到些什么。

    昨天真是没啥兴趣再写，还是一个什么版主，说我扯，没什么有价值的东西。

    难道提到ase15+p6的spinlock竞争没价值？我就是先写点儿，看看有没人需要这些东西，如果什么都不懂，那我还写出来干嘛，给谁看，那不是瞎耽误功夫吗！在这儿有什么好炫耀的，如果是那样，还不如有空歇会儿！