sybase系统的一个调优案例

性能调优是个永恒的话题。从我多年的工作经验来看，没有问题的性能几乎是不存在的！不过，有问题并不一定需要调优：可能是没必要，比如用了很好的机器也就 遮盖过去了；客户认可也就不需要调了（曾经碰到一个程序运行40分钟，只是一个人使用，她也就忍受了），还有很多方面的原因，在这就不一一解释了。

通常需要解决的性能问题是没有办法了，比如CPU100%了，业务无法正常操作了，一般都是到这个时候才想起需要对性能进行优化了。

今年有幸参加了某银行电子银行系统的优化，前后耗费几个月的时间，最好总算有所成，基本解决了性能问题。

这个系统的性能出现的问题可以是说非常严重，也非常奇怪，在下午，还没有到最高峰的时候，CPU会从20%直接冲到100%，也就几秒钟的时间。但业务量并没有明显的提高，而实际上，CPU100%的时候处理能力是略微下降的。

按照一般的做法，CPU达到100%忙，我们应该增加CPU，但如果那样操作，会有适得其反的效果，这个待稍后解释。

由于严重影响了电子银行系统的正常运行，所以我和Sybase的人都不能走了，天天在现场分析。开始的时候并不是很顺利，通过停止业务的方法，似乎有效 果，但似乎有没有效果。当时CPU一到100%，就停业务，要不把个人停了，要不把企业停了，有时候好像CPU就好了，但实际上都没有效果。确切来说是找 不到解决的方法。经过几天的分析，认为有些表非常繁忙，Sybase香港建议把忙的表做des绑定。第二天我们执行了这个操作，有一定的效果，但没有解决 根本问题。我们监控着，看到数据库的spinlock竞争一直在增加，终于到了90%的时候，CPU又完全100%了！！！

我在前一天找到了一种方法，文档上说，如果碰到CPU异常高，又没有确切原因的话，可以使用这个方法（好像挺玄，嘿嘿）。当时，我觉得很像我们碰到的现象，就把这个东西给Sybase香港人说，他看了，认为不是相关的（所以说，有时候专家的话也不能信）。

在没有办法的时候，我就做了这个操作（是挺大胆的，毕竟是生产系统，如果有负面问题，那就麻烦了！）。结果非常非常的好，CPU马上下来了，且比之前的高峰还有低一些。当时的感觉真的很好，大家终于可以回家了，哈哈！

后来sybase解释说，这个操作改变了内存的替换策略，从而减少了spinlock的竞争，CPU也就不忙了。ASE 15在p6上的spinlock竞争确实非常厉害，这个问题在原先ase 12.5+p5上就没有。

 

 

 

 

 

**************************************************

                                                      ****************************************

解决这个问题还真不是靠内存分区。因为通过sysmon显示，是object的spinlock的竞争很高，最高的时候超过90%。不是cache的，虽然这个问题解决之后也碰到了cache的spinlock高。

ASE15增加了很多查询策略，因此其找到一个好的查询计划的时间大大增加。如果针对的SQL语句本身执行时间很长，还不是问题。但如果是很短的SQL语 句，这个时间占的比重就很高了。我碰到的一个案例，从12.5升级到15，一个程序（由很多执行很短的sql语句组成）运行的时间提高了2~3倍，可以认 为多出来的时间就是编译的时间，大约是每个sql语句在10ms这个量级。

因为这个原因，ase引入了Statement cache，也就是对于重复执行的sql语句，不需要再编译，找到以前已经编译好的计划就可以。这个措施对于此类sql语句还是非常有效的。上面这个案列 打开以后，其执行时间就跟12.5上差不多，稍微增加了一些。当然，这个措施也有它的问题，如果由于变量不同，导致sql语句应该使用不同的查询计划时， 就会带来一定的问题。

再来说电子银行这个案例，由于之前的经验，所以我们也打开了这个参数，并且设置该内存为1G。出现这个问题后，我们也试着关闭了Statement cache，但CPU有明显的升高，比原先要高一倍左右。这个结果用户不能接受，所以又调整回去了。

sysmon一直显示objects spinlock竞争非常激烈，而在文档中的解决办法就是des绑定。这也是为什么我们做des绑定的原因。我们担心没有绑定出问题的表，因此，做了尽可 能多的绑定。操作最多的前100个表都做了绑定。说起来这个操作还是起了一定的作用。至少是延缓了问题的发生。原先问题在2点到2点半左右就会出现，绑定 后问题在3点多出现的。

插一句话，sybase香港那个人的水平还是挺高的，经验也很丰富，他是做pse，从产品方面给出了很多建议，也给我们一些脚本，帮助了问题的定位。我跟 sybase，还有客户的人，都有10年以上的sybase经验，还是没那么容易忽悠的，呵呵！包括，后来的sybase美国的专家，也是很有水平的。虽 然原来想派的一个没到，好像叫peter，听说那个人去年用户大会的时候过来了，可惜那天我有事走了。

言归正传，说起问题的解决办法，不能不提到一个人：Rob Verschoor，熟悉sybase的人很多都知道他吧。我也是在找不到办法的情况下，到网上查找解决问题的方法。然后就找到了这位老兄的一篇文章，他 提到了如果碰到CPU有不明原因的繁忙时，可以使用一个757的traceflag，同时清除一下内存。
第二天，在sybase香港建议的方法无效后，我就大胆使用了这个方法。执行完毕后，效果是立竿见影，CPU马上落下来了，而且比之前正常的时候还有低！

后来sybase做了解释，这个traceflag改变了内存的替换策略，从而降低了cpu的spinlock。而且我们发现，仅仅使用这个 traceflag，object的spinlock还会慢慢上升，需要定期清空才能降下来。后来发现，Statement cache不能设置太大，原来的1G改成了100m，就不需要定期清空内存了！

这个案例给我的两点是，一是CPU忙不一定要加更多的CPU；二是内存并不是越大越好！

写了这么多，希望有人能从中得到些什么。昨天真是没啥兴趣再写，还是一个什么版主，说我扯，没什么有价值的东西。难道提到ase15+p6的 spinlock竞争没价值？我就是先写点儿，看看有没人需要这些东西，如果什么都不懂，那我还写出来干嘛，给谁看，那不是瞎耽误功夫吗！在这儿有什么好 炫耀的，如果是那样，还不如有空歇会儿！