來這個操作還是起了一定的作用。
至少是延緩了問題的發生。
原先問題在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競爭沒價值？我就是先寫點兒，看看有沒人需要這些東西，如果什麼都不懂，那我還寫出來幹嘛，給誰看，那不是瞎耽誤功夫嗎！在這兒有什麼好炫耀的，如果是那樣，還不如有空歇會兒！
第92章解決
